HTTP Timing Breakdown: DNS, Connect, TLS, Redirect, Wait, Download
Availability: Starter, Team, Business, OSS, and Enterprise plans (not on Free)
Response time alone tells you that a request was slow — not why. The HTTP timing breakdown splits every HTTP/API check’s latency into the five phases that make it up, so you can tell a slow DNS resolver apart from a slow backend at a glance.
What it measures
For every check against a Site or API monitor, the scheduler records how long each phase of the request took:
| Phase | What it is |
|---|---|
| DNS | Time to resolve the target hostname to an IP address |
| Connect | Time to open the TCP connection to that IP |
| TLS | Time to complete the TLS/HTTPS handshake (skipped for plain HTTP) |
| Redirect | Response wait accumulated across intermediate redirects; its DNS/Connect/TLS time remains in those phases |
| Wait | Time from request sent to first response byte, minus DNS/Connect/TLS/Redirect — includes final-request transmission, network latency, and target processing |
| Download | Time to read the rest of the response body after the first byte arrives |
These add up to (approximately) the total response time already shown elsewhere on the dashboard.
This only applies to Site and API monitor types, which make a real HTTP request. DNS-record, SSL-certificate, and other non-HTTP monitor types don’t have a timing breakdown since there’s no HTTP phase to measure.
Where you’ll see it
Monitors list — compact bar
On the Monitors list, a small colored bar appears under Last Check for every eligible monitor, showing the proportions of its most recent check. Hover any segment for the phase name and exact millisecond value.
This reflects the last check only — it is not a history or trend, just a snapshot of what happened most recently.
Expanded row — full breakdown
Click a monitor row to expand it. Below the response-time chart and stats, a Last check breakdown section shows the same phases as a wider bar with a labeled legend (e.g. DNS 32ms, Connect 2ms, TLS 11ms, Wait 7ms).
Hover or focus any legend item to open a popover explaining:
- What the phase is
- Why it matters
- How it affects the result — what a high value in that phase usually means (DNS provider issue, network distance, certificate overhead, backend slowness, or payload/bandwidth)
Reading the breakdown
A large DNS, Connect, or TLS segment usually points to something outside your application — a slow resolver, network distance from the checking region, or certificate/TLS configuration. A large Wait segment means the target was slow to begin responding, but it is not proof of backend slowness by itself: request transmission and network latency are included. A large Download segment means the response body is large or bandwidth-limited on the path.
Every scheduled HTTP check opens its own connection. That keeps the waterfall independent: another monitor hitting the same hostname cannot warm DNS, TCP, or TLS for this monitor’s result. When the target redirects, all followed hops are included and the Redirect segment shows both the intermediate response wait and redirect count.
Plan availability
| Feature | Free | Starter | Team | Business | OSS | Enterprise |
|---|---|---|---|---|---|---|
| HTTP timing breakdown | — | ✅ | ✅ | ✅ | ✅ | ✅ |
On a monitor shared with a team, the breakdown is gated by the monitor owner’s plan, not the viewer’s — so a teammate on a lower plan still sees it on monitors owned by a higher-tier teammate, and vice versa.
Troubleshooting
No bar shows for a monitor
Check that:
- The monitor type is Site or API (not DNS, SSL, or another non-HTTP type)
- It has run at least one check since this feature shipped — older results predate timing capture and won’t have a breakdown
- Your account plan includes this feature (see the table above)
Some phases are missing from the bar
Expected in a few cases:
- DNS missing: the monitor target is an IP address, so there is no hostname to resolve
- TLS missing: the target is plain HTTP, not HTTPS
- All phases missing but a response time is shown: the check failed before headers arrived (e.g. a timeout) — a partial breakdown may still appear if DNS/Connect succeeded before the failure
FAQ
Does this change how uptime or response time is calculated?
No. It’s an additional breakdown of the same measurement already used for response time — nothing about status or alerting changes.
Is history available, or just the last check?
Just the last check, shown on the Monitors list and in the expanded row. It’s a live snapshot, not a trend chart.
Does this add overhead to checks?
Each check opens a new TCP/TLS connection so its timing is independent. That adds the normal connection setup cost to the agent and target, while the timing capture itself is negligible. It does not change uptime or alerting logic.