CloudWatch Metric Guide
OriginLatencyAmazon CloudFront CloudWatch metric
OriginLatency measures the total time, in milliseconds, from when CloudFront receives a request to when it starts sending a response back toward the network — but only for requests served from the origin (a cache miss), not from CloudFront's cache. Also known as first-byte latency or time-to-first-byte.
What it measures
About OriginLatency
OriginLatency measures the total time, in milliseconds, from when CloudFront receives a request to when it starts sending a response back toward the network — but only for requests served from the origin (a cache miss), not from CloudFront's cache. Also known as first-byte latency or time-to-first-byte.
| Namespace | AWS/CloudFront |
| Metric name | OriginLatency |
| Unit | Milliseconds |
| AWS docs | Official Amazon CloudFront metrics reference |
Why this metric matters
OriginLatency is the single most direct metric for diagnosing whether slowness a user experiences is coming from your origin infrastructure rather than from CloudFront, the network path, or the viewer's own connection — because it isolates exactly the time CloudFront spent waiting on the origin for cache-miss requests. If OriginLatency climbs while Requests stays flat, the problem is almost certainly origin-side capacity or a slow downstream dependency (database, API, cold start), not traffic volume.
Two things about this metric trip people up. First, unlike Requests and the error-rate metrics, OriginLatency is NOT a default metric — it's part of CloudFront's "additional metrics" that must be explicitly turned on per distribution (via the console, CloudFormation's AWS::CloudFront::MonitoringSubscription, or the CLI's create-monitoring-subscription command), and AWS charges a small fixed per-metric fee once enabled. Second, OriginLatency only supports the Percentile statistic — retrieved via CloudWatch's ExtendedStatistics parameter (e.g. p50, p90, p99), not the standard Statistics parameter used for Average/Sum/Maximum. As with all CloudFront metrics, queries must target the CloudWatch us-east-1 endpoint with Region=Global set.
Recommended alarm threshold for OriginLatency
Recommended threshold
p90 > 1000 ms sustained for 3 consecutive 5-minute periods (ExtendedStatistics p90)
AWS does not publish a target OriginLatency value — acceptable latency depends entirely on what the origin does (static file server vs. dynamic API vs. serverless backend). The 1-second p90 threshold (Nuberio recommendation) is a reasonable starting point for typical web/API origins; latency-sensitive origins should tighten it, and heavier compute origins (e.g. server-rendered pages behind Lambda) may need to loosen it — the key is alarming on p90 or p99, not Average, since first-byte latency is often driven by tail-latency outliers a mean would hide.
Is your OriginLatency alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including OriginLatency — in 5 minutes.
Common failures that show up in OriginLatency
When OriginLatency reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Origin server overload — the backend can't keep up with the rate of cache-miss requests CloudFront is forwarding
Cold starts on a serverless origin (Lambda, API Gateway) after a scale-up event or long idle period
Slow downstream dependency at the origin — a database query, third-party API call, or internal service the origin waits on
Cache configuration change (shorter TTLs, new cache-busting query strings) that increases the cache-miss rate and pushes more traffic to a slow origin
Network path degradation between the CloudFront edge and the origin, including origin-side security group or NACL changes adding latency
How the Nuberio Audit checks OriginLatency
The free Audit scans every Amazon CloudFront resource in your account and checks whether a OriginLatency 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 OriginLatency alarms. Free, 5-minute read-only scan.
Related Amazon CloudFront metrics
OriginLatency rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon CloudFront coverage.
FAQ
Frequently asked questions about OriginLatency
Common questions about setting up CloudWatch alarms for OriginLatency in Amazon CloudFront.
What is the recommended CloudWatch alarm threshold for OriginLatency?+
p90 > 1000 ms sustained for 3 consecutive 5-minute periods (ExtendedStatistics p90). AWS does not publish a target OriginLatency value — acceptable latency depends entirely on what the origin does (static file server vs. dynamic API vs. serverless backend). The 1-second p90 threshold (Nuberio recommendation) is a reasonable starting point for typical web/API origins; latency-sensitive origins should tighten it, and heavier compute origins (e.g. server-rendered pages behind Lambda) may need to loosen it — the key is alarming on p90 or p99, not Average, since first-byte latency is often driven by tail-latency outliers a mean would hide.
Which CloudWatch namespace does OriginLatency belong to?+
OriginLatency is published in the AWS/CloudFront namespace with a unit of Milliseconds. You can find it in the CloudWatch console under "Metrics" → "AWS/CloudFront". See the Amazon CloudFront CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for OriginLatency?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon CloudFront resources are missing a OriginLatency alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a OriginLatency alarm set up?+
Yes. The free Audit works whether or not you have any OriginLatency 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, and DynamoDB. To find which Amazon CloudFront alarms your account is missing — including OriginLatency — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.