HTTP Latency — Timing the Phases of a Request
This measures an HTTP request and reports the time spent in each phase: resolving the name, establishing the connection, negotiating TLS, waiting for the first byte, and transferring the body. A single total duration tells you something is slow; the breakdown tells you which component to look at.
Why run it
Because the phases point at completely different owners. Time in DNS resolution is a resolver problem. Time in connect is network distance or a saturated link. Time in TLS negotiation suggests handshake overhead or an expensive certificate chain. Time waiting for the first byte is the application or its database. Time in transfer is payload size or bandwidth. Without the breakdown, every one of those looks identical — a request that took two seconds — and teams routinely optimise the wrong layer as a result.
Why automate it
Phase timings drift independently, and the drift is the signal. A slow increase in time-to-first-byte over weeks is a database gradually outgrowing its indexes; a step change in TLS time is a certificate chain that got longer at renewal. Neither is visible in a total that has moved by a couple of hundred milliseconds, and neither is catchable by occasional manual measurement. Continuous sampling with the phases kept separate is what makes gradual degradation attributable.
What it gives you
Attribution instead of a single number. Knowing which phase owns the time is the difference between fixing the slowness and rewriting something that was never the problem.