AWS Lambda monitoring
Combine agentless CloudWatch metrics with OpenTelemetry Lambda layers: Obseria shows invocations, cold starts, duration, errors and throttles per function, plus traces across API Gateway, SQS and DynamoDB.
Why monitor AWS Lambda with Obseria
Agentless in minutes
A read-only IAM role lets Obseria collect Lambda metrics from CloudWatch for all functions and regions, without touching code.
Cold starts made visible
Init duration and the faas.coldstart span attribute show which functions start cold, how often and at what cost.
Traces across serverless flows
OpenTelemetry Lambda layers connect API Gateway, Lambda, SQS, SNS and DynamoDB calls into one distributed trace.
Serverless components Obseria monitors
- Lambda functions and versions. Metrics per function, alias and version, including provisioned concurrency.
- Event sources. SQS, Kinesis, DynamoDB Streams and Kafka triggers with iterator age and batch errors.
- API Gateway and function URLs. Request latency, 4xx and 5xx errors linked to the backing functions.
- Step Functions. State machine executions with failed and timed-out steps.
- Runtimes via OpenTelemetry layers. Node.js, Python, Java and other runtimes instrumented through OpenTelemetry Lambda layers.
- Function logs. CloudWatch Logs including REPORT lines with duration, billed duration and memory used.
The AWS Lambda signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Usage and demand
Shows how often your functions run and how many run at once, which drives both performance and cost.
Errors and rejections
Tells you how often functions fail or are turned away because limits are reached, meaning work was not done.
Speed and startup delays
Reveals how long functions take and how much extra time is lost when they start up from scratch.
Processing backlog
Shows whether functions keep up with incoming data streams or fall behind, delaying downstream business processes.
Show all 8 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
Invocations | Count | How often a function ran; the baseline for error and throttle rates. |
Errors | Count | Invocations that ended in a function error, such as an exception or timeout. |
Throttles | Count | Requests rejected because concurrency limits were reached. |
Duration | Milliseconds | Execution time per invocation; watch p95 and p99 against the timeout. |
ConcurrentExecutions | Count | Instances running at the same time, compared with account and reserved limits. |
IteratorAge | Milliseconds | Age of the last record from a stream source; growth means the function falls behind. |
ProvisionedConcurrencySpilloverInvocations | Count | Invocations that exceeded provisioned concurrency and started on demand. |
init_duration | Milliseconds | Lambda Insights metric for initialization time, the direct cost of a cold start. |
Set up AWS Lambda monitoring in minutes
- Step 1
Connect your AWS account
Create a read-only IAM role for Obseria and select the regions; Lambda metrics from CloudWatch arrive without agents.
- Step 2
Add the OpenTelemetry layer
Attach the OpenTelemetry Lambda layer for your runtime and set AWS_LAMBDA_EXEC_WRAPPER to enable auto-instrumentation.
- Step 3
Export to Obseria
Set OTEL_SERVICE_NAME, the Obseria OTLP endpoint and your token, ideally through the OpenTelemetry Collector layer.
# Node.js function: OpenTelemetry layer + Collector layer (ARNs from the
# opentelemetry-lambda releases for your region and architecture)
aws lambda update-function-configuration \
--function-name checkout-handler \
--layers "${OTEL_NODEJS_LAYER_ARN}" "${OTEL_COLLECTOR_LAYER_ARN}" \
--environment "Variables={\
AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler,\
OTEL_SERVICE_NAME=checkout-handler,\
OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/collector.yaml,\
OBSERIA_OTLP_ENDPOINT=${OBSERIA_OTLP_ENDPOINT},\
OBSERIA_TOKEN=${OBSERIA_TOKEN}}"
# collector.yaml (bundled with the function) exports via otlphttp:
# endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
# headers: { Authorization: "Bearer ${env:OBSERIA_TOKEN}" }Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- Lambda overview: invocations, errors, throttles
- Cold start rate and init duration per function
- Alert on duration approaching timeout
- Alert on IteratorAge growth for stream sources
- Concurrency against account limits
AWS Lambda monitoring: what matters
Why AWS Lambda monitoring needs its own approach
AWS Lambda removes servers from your operational view, but not performance problems. Functions start cold, hit concurrency limits, time out or fall behind stream sources, and a single user request often crosses API Gateway, several functions, SQS queues and DynamoDB. AWS Lambda monitoring therefore combines two data sources: platform metrics from CloudWatch for every function, and distributed traces from inside the function code.
Classic host agents do not fit a model where execution environments live for minutes and are frozen between invocations. Serverless monitoring works best with agentless metric collection plus lightweight instrumentation delivered as Lambda layers. The OpenTelemetry project publishes such layers for common runtimes, and AWS distributes them as the AWS Distro for OpenTelemetry.
Lambda metrics that matter
CloudWatch publishes a standard set of metrics in the AWS/Lambda namespace. These are the ones to watch first:
- Invocations, Errors and Throttles: together they give error and throttle rates per function. Throttles mean requests were rejected, not merely slow.
- Duration: look at p95 and p99, not the average, and compare them with the configured timeout. Duration also drives cost.
- ConcurrentExecutions: shows how close you are to the account limit or to reserved concurrency for a function.
- IteratorAge: for Kinesis, DynamoDB Streams and Kafka sources, a rising value means the function cannot keep up.
- Cold starts: the REPORT log line includes
Init Durationfor cold invocations, Lambda Insights exposes it asinit_duration, and OpenTelemetry marks cold invocations with the span attributefaas.coldstart.
Common Lambda problems and how to detect them
Lambda cold starts
A cold start happens when Lambda creates a new execution environment: it downloads the code, starts the runtime and runs initialization code outside the handler. Large deployment packages, heavy frameworks and VPC configuration make it worse. Track the share of invocations with faas.coldstart=true and their init duration per function, and compare before and after enabling provisioned concurrency or SnapStart.
Timeouts
Functions that approach their timeout usually wait on a slow dependency. Traces show which downstream call consumed the time, so you can fix the call instead of raising the timeout.
Throttling and concurrency exhaustion
A traffic spike or a noisy function can consume the shared account concurrency and throttle unrelated functions. Alert on Throttles and on ConcurrentExecutions relative to your limits.
Poison messages and retries
For asynchronous and stream invocations, a failing record is retried, which raises IteratorAge and can block a shard. Error spans with the event source attributes show which batch fails and why.
Best practices for serverless monitoring
- Collect CloudWatch metrics for all functions agentlessly, and add OpenTelemetry layers to the functions on critical paths.
- Use the OpenTelemetry Collector layer so telemetry is flushed efficiently at the end of each invocation instead of blocking the handler.
- Set
service.nameper function and tag aliases and versions so you can compare deployments. - Alert on rates and percentiles, for example error rate and p99 duration, rather than on raw counts.
- Keep initialization code lean and measure the effect of every dependency on init duration.
How Obseria helps with AWS Lambda monitoring
Obseria connects to your AWS accounts through a read-only IAM role and collects metrics for Lambda and 300+ AWS, Azure and GCP services without agents. Traces from OpenTelemetry Lambda layers arrive over OTLP and are joined with CloudWatch metrics and logs. TopoGraph maps event sources, functions and downstream services automatically, so you see which API depends on which function and table. When errors or throttles rise, Obseria Intelligence correlates the change with deployments, concurrency limits or a failing dependency and presents the root cause with its chain of evidence. Dashboards, alerts and SLOs for serverless workloads are included.
Related integrations
Related capabilities
Serverless Monitoring
Trace every invocation across functions, queues and APIs. Obseria shows cold starts, errors, duration and cost for serverless workloads in the context of your whole system.
Learn moreDistributed Tracing
Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.
Learn moreCloud Monitoring
Monitor 300+ cloud services agentless and see how they affect your applications. One platform for multi-cloud metrics, logs, traces and topology.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
What is OpenTelemetry?
What is OpenTelemetry? Learn how OTel's APIs, SDKs, Collector, OTLP and semantic conventions produce vendor-neutral traces, metrics, logs and profiles.
AWS Lambda monitoring FAQ
No. CloudWatch metrics are collected agentlessly. For traces, you attach the OpenTelemetry Lambda layer and set AWS_LAMBDA_EXEC_WRAPPER; auto-instrumentation runs without code changes for supported runtimes.
Through the init duration reported by Lambda and the OpenTelemetry span attribute faas.coldstart. Obseria shows the cold start rate and init duration per function and version.
It adds some initialization time and a small per-invocation cost. Using the Collector layer keeps export off the critical path; measure the impact on your own functions with init duration and Duration.
The OpenTelemetry Lambda layers support Node.js, Python and Java, and other runtimes can use the OpenTelemetry SDK directly. CloudWatch metrics cover every runtime.
A read-only IAM role that allows reading CloudWatch metrics and resource metadata. Obseria does not need write access to your account.
Start monitoring AWS Lambda today
Connect AWS Lambda in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.