Amazon CloudWatch gives you aggregate metrics for AWS Lambda, such as how many invocations ran, how many returned errors, how long function code took, and how many requests were throttled. Choose the function version and statistic that match the question, then use invocation logs or traces when an aggregate metric cannot explain an individual request.

Lambda publishes standard function metrics in the AWS/Lambda namespace at one-minute intervals. You do not need to add permissions to the function role for these metrics, and Lambda does not charge extra for them. Lambda invocation metrics are aggregates, not per-invocation records. For these metrics, the timestamp reflects when the invocation started, while CloudWatch may not show the data until the invocation finishes. Allow for that reporting delay when looking at the latest data. See AWS's Lambda metrics overview and metric viewing guide.

Choose metrics and statistics that answer the question

Open CloudWatch Metrics and select the AWS/Lambda namespace. For a broader metric reference, see our guide to AWS Lambda metrics.

Core invocation, latency, and concurrency metrics

Metric What it measures Useful statistic Important limit
Invocations Calls that reached and ran your function code, including calls that returned a function error Sum for the count in a period Throttled requests and other rejected invocations are not counted.
Errors Invocations that returned a function or runtime error, including timeouts Sum; compare with Invocations for the function error rate It does not count every unsuccessful business result. A handler that returns a normal response containing an error status is a successful Lambda invocation.
Throttles Invocation requests rejected because Lambda could not provide concurrency Sum Throttled requests are counted in neither Invocations nor Errors.
Duration Milliseconds spent processing an event after initialization Average for the mean; p50 for the median; p95 or p99 for the slow tail Excludes cold-start initialization and is not end-to-end client latency.
ConcurrentExecutions Function instances currently processing events Maximum over the period to see peak concurrency A high peak by itself does not show that requests were throttled; check Throttles too.

Average is the mean and can be pulled upward by unusually long invocations; p50 is the median. Compare these with p95 or p99 to see whether a slowdown affects the middle of the distribution or is concentrated in the slower tail. AWS documents the supported Lambda metrics and statistics.

Add event-source metrics when they apply

Some metrics appear only for particular invocation modes or event sources:

  • IteratorAge applies to DynamoDB, Kinesis, and Amazon DocumentDB streams. It measures the age of the last record in an event when the event source mapping sends the event to the function.
  • OffsetLag applies to self-managed Apache Kafka and Amazon MSK. It measures the offset difference between records written to the topic and those processed by the consumer group.
  • AsyncEventAge measures how long an asynchronous event waits before Lambda invokes the function.

Use Maximum to find the highest age or lag in a period. If it rises, inspect the event source mapping, processing rate, function errors, and retry behavior. These metrics do not apply to every trigger, so first confirm which source is invoking the function.

Calculate the function error rate

In a CloudWatch graph, add Errors and Invocations for the same function dimensions and period, using Sum for both. Add this metric math expression, replacing the IDs with the IDs shown in your graph:

IF(invocations > 0, 100 * errors / invocations)

This gives the percentage of invocations that returned function errors. A period with no invocations has no error-rate value. The rate excludes throttles by definition, so review Throttles separately. CloudWatch supports this kind of metric math expression.

Choose the right function scope in CloudWatch

Select dimensions before comparing metrics

In the AWS/Lambda namespace, the dimensions determine which invocations are combined:

  • FunctionName aggregates metrics across all versions and aliases of a function.
  • Resource selects a particular version or alias.
  • ExecutedVersion separates the version that actually handled an invocation, which is useful when a weighted alias sends traffic to more than one version.
  • EventSourceMappingUUID isolates a particular event source mapping.

These metrics are also Region-scoped. If a deployment affects only one version, an aggregate function graph can hide the change; compare the executed versions over the same time range. AWS's CloudWatch navigation instructions describe each dimension. The page also notes that long-running invocations can take several minutes to appear because metrics are emitted after processing finishes.

Read metric patterns, then investigate the cause

Separate function duration from cold starts and request latency

Duration measures function-code processing; it excludes the initialization phase. It also does not include the full time a caller may wait for API Gateway, a queue, or another downstream service. Use the metric to see whether function processing is slower, then check logs or traces to locate time spent in initialization, the handler, or dependencies.

InitDuration is not a standard AWS/Lambda CloudWatch metric. For ordinary execution environments, look for Init Duration in the invocation's REPORT log. For SnapStart, initialization details appear in INIT_REPORT, and restore time has its own fields. See AWS's Lambda log field reference and SnapStart monitoring guide.

Compare errors, throttles, and concurrency

When Errors rise, compare the error rate with the same-period invocation count and inspect the matching function logs. Lambda records the error metric at invocation start, so account for the function's runtime when lining up timestamps. A DeadLetterErrors increase means Lambda failed to deliver an asynchronous invocation to its configured dead-letter queue; it is not a general count of function failures. See AWS's definition of asynchronous invocation metrics.

Use invocation logs for per-request details

CloudWatch Logs contains a REPORT record for an invocation. It includes Duration, Billed Duration, allocated Memory Size, and Max Memory Used; standard Lambda metrics do not provide a memory-use time series. These are log fields, separate from the standard metrics. CloudWatch Logs has its own ingestion and storage pricing, separate from the included standard metrics; check current CloudWatch pricing.

Interpret Max Memory Used as an observed value, not always the isolated peak for that request. When invocations share an execution environment, Lambda can report the maximum across those invocations, which may be higher than the current invocation's usage. AWS describes this behavior in its Python runtime logging reference.

Do not use Duration alone to estimate Lambda compute charges. Billed Duration applies billing rounding and, since August 1, 2025, includes initialization time across Lambda configurations. A cold-start invocation can therefore have a longer billed duration than the standard Duration metric. Charges also depend on request count, allocated memory, architecture, and the function's configuration; use the report fields and current Lambda pricing when estimating cost. AWS explains the initialization change in its INIT billing announcement.

This Logs Insights query summarizes the duration recorded on Lambda REPORT entries and the highest reported memory field in each five-minute interval:

filter @type = "REPORT"
| stats avg(@duration) as avgDurationMs,
        pct(@duration, 95) as p95DurationMs,
        max(@maxMemoryUsed / 1024 / 1024) as maxMemoryMiB
  by bin(5m)

The query uses standard Lambda log fields and the avg, pct, max, and bin() syntax documented in AWS's CloudWatch Logs guide and Logs Insights stats reference. To investigate a specific failure, filter to its time range and request ID, then inspect the function's own messages and exception details.

Investigate throttling before changing concurrency

If Throttles rises, compare its timing with peak ConcurrentExecutions, the function's reserved concurrency, and the Region's concurrency quota. Then check how the invoking service handles rejected requests, retries, or queued work. A rising concurrent execution count without throttles can be normal growth; throttles confirm requests were rejected. Use these signals to identify which limit or event-source behavior needs attention before adjusting capacity.

Use traces to follow a request across services

Metrics summarize many invocations; a distributed trace can show the path of a sampled request through Lambda and downstream services. Tracing is configured separately from standard Lambda metrics. AWS describes Lambda tracing with X-Ray and the trace data you can inspect.

Know when to use Lambda Insights

CloudWatch Lambda Insights is an optional extension that adds runtime telemetry, including CPU and memory measurements, in the separate LambdaInsights namespace. Enable it when standard metrics and invocation logs do not provide the resource detail you need. Insights sends performance data to CloudWatch, so its metrics and logs can add charges; check current CloudWatch pricing for your Region and usage. See AWS's Lambda Insights metric reference and our guide to Lambda Insights metrics, setup, and costs.