CloudWatch Metric Guide
TargetResponseTimeApplication Load Balancer CloudWatch metric
TargetResponseTime measures the time elapsed from when the ALB sent the request to a registered target until the target started sending a response, in seconds. CloudWatch exposes this as p50, p90, p95, and p99 percentiles.
What it measures
About TargetResponseTime
TargetResponseTime measures the time elapsed from when the ALB sent the request to a registered target until the target started sending a response, in seconds. CloudWatch exposes this as p50, p90, p95, and p99 percentiles.
| Namespace | AWS/ApplicationELB |
| Metric name | TargetResponseTime |
| Unit | Seconds |
| AWS docs | Official Application Load Balancer metrics reference |
Why this metric matters
TargetResponseTime is your application's latency as measured from the network boundary. Unlike application-side timing (which starts when the framework receives the request), this metric includes time waiting in the application's request queue, time blocked on I/O, and time for the framework to begin writing the response. It's the latency your users experience minus network transit time.
The P99 statistic is almost always more actionable than the average. An API that averages 80ms but has P99 at 3 seconds means 1 in 100 requests is dramatically slow — likely hitting a cold code path, a database lock, or a retry. Average metrics hide the tail latency that drives support tickets and user complaints.
Recommended alarm threshold for TargetResponseTime
Recommended threshold
p99 TargetResponseTime > your defined SLA threshold (typically 1s for APIs, 3s for pages)
AWS documentation recommends monitoring P99 latency rather than average to catch slow outliers. The specific threshold depends on your application's SLA (Nuberio recommendation: start with 1 second P99 for API endpoints). Set the alarm evaluation period to 5 minutes to filter single-request outliers from sustained degradation.
Is your TargetResponseTime alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including TargetResponseTime — in 5 minutes.
Common failures that show up in TargetResponseTime
When TargetResponseTime reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Database query slowdown — a query that runs in 10ms normally starts taking 2 seconds due to lock contention, missing index, or connection pool exhaustion
Garbage collection pause — JVM or Node.js GC pauses add hundreds of milliseconds to response time periodically
External API latency — a third-party service call included in the request path degrades, pulling all response times with it
Cold-start requests hitting slow initialization code — a route with lazy-loaded modules or heavy initialization adds seconds to first-request latency after deploy
CPU saturation on backend instances — when CPUUtilization on ECS or EC2 is near 100%, every request waits for CPU time and response time increases
How the Nuberio Audit checks TargetResponseTime
The free Audit scans every Application Load Balancer resource in your account and checks whether a TargetResponseTime 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 TargetResponseTime alarms. Free, 5-minute read-only scan.
Related Application Load Balancer metrics
TargetResponseTime rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Application Load Balancer coverage.
FAQ
Frequently asked questions about TargetResponseTime
Common questions about setting up CloudWatch alarms for TargetResponseTime in Application Load Balancer.
What is the recommended CloudWatch alarm threshold for TargetResponseTime?+
p99 TargetResponseTime > your defined SLA threshold (typically 1s for APIs, 3s for pages). AWS documentation recommends monitoring P99 latency rather than average to catch slow outliers. The specific threshold depends on your application's SLA (Nuberio recommendation: start with 1 second P99 for API endpoints). Set the alarm evaluation period to 5 minutes to filter single-request outliers from sustained degradation.
Which CloudWatch namespace does TargetResponseTime belong to?+
TargetResponseTime is published in the AWS/ApplicationELB namespace with a unit of Seconds. You can find it in the CloudWatch console under "Metrics" → "AWS/ApplicationELB". See the Application Load Balancer CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for TargetResponseTime?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Application Load Balancer resources are missing a TargetResponseTime alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a TargetResponseTime alarm set up?+
Yes. The free Audit works whether or not you have any TargetResponseTime 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 Application Load Balancer alarms your account is missing — including TargetResponseTime — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.