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 (ConvOps 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 ConvOps 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 ConvOps 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 ConvOps debugs TargetResponseTime alarms
When TargetResponseTime triggers an alarm, ConvOps Diagnose reads CloudWatch Logs, CloudTrail (recent API calls, deploys, config changes), and the current resource state in parallel. It correlates these with AWS/ApplicationELB metrics on the same resource — giving you a plain-English root cause with numbered fix options, sent to WhatsApp or Slack, usually within 60 seconds of the alarm firing.
Before any anomaly in TargetResponseTime reaches you as a proactive alert (via ConvOps Watch), it passes through 9 verification checks: a Recovery check (did the metric self-heal?), an AWS Status check (is AWS itself having an incident?), a Deploy check (was there a recent Lambda update, ECS deploy, or RDS parameter change in the last 120 minutes?), a Quota check, an Infrastructure check, a Security check, a Flap check (has this metric been anomalous more than 5 times in the last 24 hours?), a TLS check, and a Vulnerability check. Only anomalies that pass all relevant checks reach you — with full context attached.
ConvOps Watch
Detects TargetResponseTime anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
ConvOps Diagnose
When a TargetResponseTime alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
ConvOps 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 (ConvOps 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 ConvOps automatically create CloudWatch alarms for TargetResponseTime?+
ConvOps does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free ConvOps Audit scans your CloudWatch setup and tells you which Application Load Balancer resources are missing a TargetResponseTime alarm. ConvOps Watch then monitors TargetResponseTime using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use ConvOps without already having a TargetResponseTime alarm set up?+
Yes. ConvOps Watch monitors TargetResponseTime independently of your CloudWatch alarm configuration — it reads the metric directly from CloudWatch every 5 minutes on the Growth plan. If you run the free Audit first, it will tell you which resources need a TargetResponseTime alarm and provide the copy-paste AWS CLI command to create it.