CloudWatch Metric Guide
ErrorsAWS Lambda CloudWatch metric
Errors counts the number of Lambda invocations that resulted in a function error — including exceptions thrown by the function code and runtime errors (timeout, out-of-memory, handler not found).
What it measures
About Errors
Errors counts the number of Lambda invocations that resulted in a function error — including exceptions thrown by the function code and runtime errors (timeout, out-of-memory, handler not found).
| Namespace | AWS/Lambda |
| Metric name | Errors |
| Unit | Count |
| AWS docs | Official AWS Lambda metrics reference |
Why this metric matters
Lambda Errors is the single most critical metric for serverless workloads. Unlike application errors that might be logged somewhere and noticed eventually, Lambda Errors are AWS-level failures — the function did not complete its intended work, and the caller received an error or retry.
For Lambda functions that process SQS, SNS, or EventBridge events, errors trigger automatic retries (for asynchronous invocations) or dead-letter queues. This means errors can silently compound: one Lambda error might generate two or three subsequent retry invocations, all of which error, all of which generate more retries. An unchecked error rate can drain your dead-letter queue and drop events permanently.
Recommended alarm threshold for Errors
Recommended threshold
> 0 in any 5-minute window for critical functions; > N errors/minute for high-volume functions (set N based on your acceptable error rate)
For critical functions handling user-facing or transactional workloads, zero tolerance is the correct starting point (Nuberio recommendation). For high-volume async processing functions, a percentage-based error rate threshold (errors / invocations > 1%) may be more appropriate to avoid false positives on transient failures. AWS documentation recommends monitoring both Errors and the derived error rate for complete coverage.
Is your Errors alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including Errors — in 5 minutes.
Common failures that show up in Errors
When Errors reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Unhandled exception in function code — an uncaught TypeError, KeyError, or null reference causes the invocation to fail silently
Timeout — function logic takes longer than the configured timeout, causing Lambda to terminate it mid-execution
Out-of-memory — function processes a larger payload than its memory allocation can handle
Dependency failure — the function calls an RDS, DynamoDB, or external API that is unavailable, and the function code doesn't handle the error gracefully
Cold start issue on VPC-attached Lambda — ENI attachment delays cause timeouts on the first invocation after a scale-out
How the Nuberio Audit checks Errors
The free Audit scans every AWS Lambda resource in your account and checks whether a Errors alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured Errors alarms. Free, 5-minute read-only scan.
Related AWS Lambda metrics
Errors rarely fails in isolation. These metrics tend to correlate — monitor them together for complete AWS Lambda coverage.
FAQ
Frequently asked questions about Errors
Common questions about setting up CloudWatch alarms for Errors in AWS Lambda.
What is the recommended CloudWatch alarm threshold for Errors?+
> 0 in any 5-minute window for critical functions; > N errors/minute for high-volume functions (set N based on your acceptable error rate). For critical functions handling user-facing or transactional workloads, zero tolerance is the correct starting point (Nuberio recommendation). For high-volume async processing functions, a percentage-based error rate threshold (errors / invocations > 1%) may be more appropriate to avoid false positives on transient failures. AWS documentation recommends monitoring both Errors and the derived error rate for complete coverage.
Which CloudWatch namespace does Errors belong to?+
Errors is published in the AWS/Lambda namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/Lambda". See the AWS Lambda CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for Errors?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which AWS Lambda resources are missing a Errors alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a Errors alarm set up?+
Yes. The free Audit works whether or not you have any Errors alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus the copy-paste AWS CLI command to create it.
This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, DynamoDB, SQS, API Gateway, S3, CloudFront, ElastiCache, and EKS. To find which AWS Lambda alarms your account is missing — including Errors — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.