Request Timeout & Latency Diagnostic

The Request Timeout and Latency Diagnostic compares a response time you measured against a sensible budget and points you at where to look when it is too slow. A reasonable target is under a hundred milliseconds for a same region API call and under three hundred end to end for something the user waits on, and anything past that deserves attention. The tool walks you through the usual hiding places for latency, such as DNS, the TLS handshake, cold starts, and slow database queries, so you can find which leg of the journey is the problem. It is a reference and planning aid that runs locally in your browser. Response time is a budget rather than an absolute, because how long is acceptable depends on what the user is waiting for. An internal call between services in the same region should complete in tens of milliseconds, an interactive API call that a person is watching should stay in the low hundreds, and an end to end page load has a larger allowance because it is a longer chain of work. Against those budgets, a measurement is only useful if you can say which part of the journey consumed the time. A request typically crosses several legs: a name has to be resolved by DNS, a connection and a secure handshake have to be established, the server may have to start a runtime if it was idle, and the actual work may involve database or third party calls of its own. Each leg has a characteristic pattern, so a latency problem that scales with first request only points at cold starts while one that scales with load points at the database or an upstream dependency. Treating this as a budget against measurable legs is what turns a complaint about slowness into a specific place to look.

📘 Related guide: Read an HTTP status code and pick the fix →