AWS Lambda metrics help you see how often functions run, how long they process events, when they fail, and whether concurrency or an event source is falling behind. Start with the standard metrics in CloudWatch, then use invocation logs for details such as billed duration, memory use, and initialization time.

Lambda publishes its standard function metrics to the AWS/Lambda namespace in CloudWatch at one-minute intervals. Those metrics are aggregates, not a record of every invocation. A long-running invocation can take several minutes to appear in the metric graph, so allow for that delay when investigating a recent change. See AWS's Lambda metrics overview.

Key Lambda metrics

Choose metrics based on the question you need to answer. For count metrics, use Sum; for peak concurrency, use Max. For latency, compare percentiles as well as averages so a small number of slow invocations do not disappear in the mean.

Metric What it tells you Useful view
Invocations How many times Lambda invoked your function code, including executions that returned a function error. Throttled or otherwise rejected requests that never reach the code are not counted. Sum over a period
Errors How many invocations returned a function or runtime error, including timeouts and configuration errors. Sum; compare with Invocations for an error rate
Throttles How many invocation requests Lambda throttled because execution capacity was unavailable. Sum; compare with concurrency and the trigger's retry behavior
Duration How long function code takes to process an event. This metric excludes cold-start time. Average and percentiles such as p95 or p99
ConcurrentExecutions How many executions are in flight at once. Max over the period
IteratorAge or OffsetLag How far behind a supported stream or Kafka source is, reported as an age or offset difference depending on the metric. Max and the event source mapping's processing and error metrics

The exact metric set depends on how Lambda is invoked. AWS documents the available invocation, performance, concurrency, asynchronous-invocation, and event-source metrics, including their meanings and recommended statistics.

Errors describes Lambda's execution outcome, not every unsuccessful business result. For example, an API handler can catch a problem and return a valid HTTP response with a 4xx or 5xx status; from Lambda's perspective, the function completed normally. Track those outcomes with an application metric or API response metrics. See AWS's definition of function errors and Lambda proxy response format.

Duration, percentiles, and cold starts

Duration measures the function's processing time after initialization. It is useful for finding slow handler code and comparing normal latency with a service objective. A high average can indicate a broad slowdown; a high p95 or p99 can reveal a slower tail that the average hides.

Cold-start initialization is recorded separately. In the traditional REPORT log line, inspect Init Duration when a new environment initializes. For SnapStart, inspect the restore fields. A slow request can also come from the handler or a downstream service, so compare initialization with the end-to-end request and dependency timings before choosing a fix. For a focused set of mitigation options, see our guide to reducing Lambda cold starts.

Concurrency and capacity

Concurrency is the number of requests a function handles at the same time. A useful estimate for steady traffic is concurrency ≈ invocations per second × average duration in seconds. Treat it as a planning estimate; bursts, long-running requests, batching, and event-source polling can change actual demand.

ConcurrentExecutions helps show peak usage. AWS lists a default account concurrency quota of 1,000 for a Region, but new accounts can start with a lower quota that AWS raises automatically as usage grows. Check the quota for your account through Service Quotas. Separately, AWS documents that each function in a Region can scale by up to 1,000 additional execution environments every 10 seconds. The quota and scaling rate are different limits; consider how the event source delivers traffic. See AWS's guides to Lambda concurrency and function scaling behavior.

Reserved concurrency reserves capacity for one function and sets its maximum concurrency; it does not pre-initialize environments or remove cold starts. Provisioned concurrency pre-initializes a configured number of environments on a published version or alias, and has an additional charge. If traffic exceeds that allocation, invocations can use standard concurrency and experience initialization latency. When you use provisioned concurrency, inspect ProvisionedConcurrencyUtilization and ProvisionedConcurrencySpilloverInvocations alongside your latency data. AWS explains the distinction in its concurrency guide.

Cost and memory details

Lambda's main function charges depend on requests and execution duration, which is affected by allocated memory and architecture. CloudWatch's standard Duration metric does not include cold-start time. The per-invocation REPORT log instead includes Billed Duration, Memory Size, and Max Memory Used; newer structured log formats expose equivalent fields. The meaning of a maximum can vary by runtime: for example, AWS notes that the Python runtime can report memory used across invocations sharing an environment.

Since August 1, 2025, AWS bills initialization work across Lambda function configurations, including on-demand functions using managed runtimes and ZIP packages, as described in its INIT billing announcement. A cold-start invocation's billed duration can therefore be longer than its CloudWatch Duration metric. Review the log fields and current Lambda pricing when estimating cost. AWS's Lambda log guide explains the REPORT fields and how to query them in CloudWatch Logs Insights; its Python logging reference describes that runtime's memory field.

The standard function metrics do not provide an actual-memory-use time series. To inspect memory use, analyze the log fields or enable CloudWatch Lambda Insights for additional runtime metrics. Increasing memory also provides more CPU, so compare execution time and total charges under representative traffic instead of lowering allocation based on memory alone. For runtime coverage, setup, and log queries, see our guide to Lambda Insights metrics and configuration.

Where to inspect metrics and logs

Using Amazon CloudWatch

In the CloudWatch console, open the AWS/Lambda namespace and select the metric and dimensions that match the question you are investigating. A function-name view aggregates versions and aliases; a resource or executed-version view can separate them. Event-source mapping dimensions can help isolate a particular mapping. This matters during a rollout because aggregate function metrics can hide a problem limited to one version. Follow AWS's guide to viewing Lambda metrics.

Use metric graphs and dashboards for trends, then check the corresponding log stream for individual invocation details. Use the request ID and time range to connect the two. Metrics can show that errors or duration rose; logs help explain which invocation failed and what Lambda reported.

Setting useful alarms

Set alarm thresholds from your service's normal traffic and latency objectives rather than applying one percentage or duration to every function. An alarm on Errors can catch failed invocations, and an alarm on Throttles can expose capacity pressure. For a rate, compare the sums of Errors and Invocations over the same period; decide deliberately how the alarm should behave when there are no invocations or data is missing.

For latency-sensitive work, use the duration statistic that matches your objective and evaluate it over a period appropriate for the traffic volume. For asynchronous functions, AsyncEventAge can show a growing backlog. For SQS event-source mappings, monitor the queue's ApproximateAgeOfOldestMessage metric and use the source queue's redrive policy. Other event sources have different retry settings and failure destinations. The DeadLetterErrors metric specifically counts failed attempts to deliver an asynchronous invocation to its configured dead-letter queue; it is not a count of all function failures or of messages entering a queue. See AWS documentation for SQS CloudWatch metrics, asynchronous dead-letter queues and destinations, and SQS event-source error handling.

Using tracing with metrics

Metrics show trends across invocations; distributed traces help follow one request through Lambda and its downstream services. AWS X-Ray can still display Lambda traces, but its SDKs and daemon entered maintenance mode on February 25, 2026. AWS recommends migrating application instrumentation to OpenTelemetry. For new instrumentation, follow the current X-Ray support timeline and AWS's OpenTelemetry migration guidance instead of starting with the older X-Ray SDK instructions.

A practical monitoring workflow

Start with the question

  1. Choose the scope. Select the function, version, alias, or event-source mapping you want to understand.
  2. Check the right signal. Use Errors for failed function executions, Throttles for rejected requests, Duration for processing time, and concurrency or event-source metrics for capacity and backlog.
  3. Use logs for per-invocation facts. Compare REPORT fields such as billed duration, initialization time, and memory use with the metric trend.
  4. Set an alarm from a service objective. Use workload history and acceptable latency or error levels; avoid treating a generic threshold as a universal limit.
  5. Recheck after a change. Compare equivalent time windows and function versions, accounting for traffic mix and retry behavior.

Match the signal to the problem

  • High duration, normal initialization: inspect handler code and downstream calls; consider memory changes only if measurements show CPU-bound work.
  • High initialization or restore time: inspect imports, extensions, runtime setup, and connection initialization. Consider SnapStart only when the runtime and function qualify; AWS currently lists managed Java 11 and later, Python 3.12 and later, and .NET 8 and later. Check its current runtime and feature requirements.
  • Throttles or rising concurrency: check the regional quota, reserved concurrency, provisioned concurrency, and the event source's behavior before changing capacity.
  • Growing event age or lag: inspect the source, batch behavior, invocation errors, and retry configuration. A Lambda DLQ setting does not apply identically to every trigger.

Summary

Core signals

Use Invocations, Errors, Throttles, Duration, and ConcurrentExecutions as a starting point. Add event-source or provisioned-concurrency metrics when those features are part of your workload. These are CloudWatch time series; billed duration, initialization, and memory-use details come from invocation logs or enhanced monitoring.

Next steps

Choose dimensions and statistics that match the issue, correlate metric changes with invocation logs, and set alarms from the behavior your service needs. Check trigger-specific retries and current quotas before treating an error, throttle, or backlog metric as a capacity problem.