Why are AWS ELB metrics limited to a 60 sec interval?

Elastic Load Balancing reports metrics to CloudWatch in 60-second intervals by design when requests are flowing through the load balancer. This is a fixed reporting interval for ELB metrics across all load balancer types (Application, Network, Gateway, and Classic Load Balancers).

While CloudWatch allows you to configure alarms with evaluation periods as short as 10 seconds, this doesn't change the underlying granularity at which ELB publishes its metrics. The 60-second interval is the native resolution at which Elastic Load Balancing measures and sends metric data to CloudWatch. When you view metric graphs or configure alarms with shorter periods, CloudWatch can only work with the data points that ELB provides, which are published every 60 seconds.

This means that even if you set an alarm to evaluate every 10 seconds, it will still be working with metric data that is collected and reported at 60-second intervals. The data points you see in the metric graph will always be aggregated per minute because that's the frequency at which ELB sends the measurements to CloudWatch.

This 60-second reporting interval is consistent across all ELB metric types and is the standard granularity for load balancer monitoring in AWS.
Sources
CloudWatch metrics for your Classic Load Balancer - Elastic Load Balancing
CloudWatch metrics for your Network Load Balancer - Elastic Load Balancing
CloudWatch metrics for your Gateway Load Balancer - Elastic Load Balancing
CloudWatch metrics for your Application Load Balancer - Elastic Load Balancing

ELB metrics (ALB, NLB, CLB) are published to CloudWatch at a fixed 60-second resolution. This is a service-side limitation — the load balancer itself aggregates and emits data points once per minute. You cannot get finer granularity regardless of what period you select in the alarm or graph configuration.

Here's what's happening:

1. ELB collects metrics internally and pushes them to CloudWatch every 60 seconds. This is the "reporting interval" mentioned in the docs.
2. When you set an alarm period to 10 seconds, CloudWatch evaluates at that frequency, but the underlying data points still only arrive every 60 seconds. Between those data points, there's simply no data — so the alarm can't react faster than the metric is published.
3. On the graph, you see minute-level aggregation because that's the actual data resolution. Selecting a shorter period just shows gaps or interpolated values.

To reduce alarm latency within these constraints:

• Use a 60-second period (matching the metric resolution) with a low evaluation threshold — e.g., 1 out of 1 datapoints breaching triggers the alarm on the very first minute the threshold is crossed.
• For latency-sensitive detection, consider using TargetResponseTime with p99 or p95 statistics rather than Average, which can mask spikes within the 60-second window.
• If you need sub-minute detection, you can publish custom metrics from your application layer (e.g., from the target instances themselves) at 1-second high-resolution intervals using PutMetricData with StorageResolution=1. This bypasses the ELB reporting limitation entirely but requires instrumentation on your side.
• Another option: use ALB access logs (delivered to S3) with a near-real-time processing pipeline (Lambda triggered by S3 events) to detect anomalies faster than CloudWatch alarms allow.

The 10-second alarm period option in the CloudWatch console is a generic setting available for high-resolution custom metrics — it doesn't change the resolution of AWS service metrics like ELB, which are fixed at 60 seconds (general knowledge — verify against current docs if this is for a customer-facing answer).

Thanks for the response.

Unfortunate to have such limitation, should've been an option at least, could even be paid. The workarounds are not applicable/ideal.