Response time measures how long an Uptime Basics availability request took to complete. Monitor Details displays both an average and a p95 value for the selected range. Read them together: the average describes typical performance, while p95 makes recurring slow checks easier to notice.
Average response time
Average response time is calculated from checks that recorded a response duration:
sum of recorded response times / number of response-time samples
The result is displayed in milliseconds. For example, response times of 100ms, 150ms, and 350ms produce a 200ms average.
A few unusually slow checks can raise the average. A consistently low average can also hide a smaller group of poor results, which is why p95 is shown separately.
P95 response time
P95 means the 95th percentile. In practical terms, approximately 95% of the summarized response measurements were at or below this value, while the slowest approximately 5% were above it.
For example:
- Average response: 180ms
- P95 response: 620ms
Most requests were reasonably quick, but a meaningful slow tail occurred. If both values are high, the endpoint was slow more consistently.
P95 is not the single slowest request. Open Detailed Logs and sort by latency when you need the exact slowest individual checks.
How the selected range affects the values
For short history, Uptime Basics can calculate metrics from recorded check timings. For longer history, it uses stored rollups so the page does not have to read every individual check.
With rollup data:
- Average response remains weighted by the number of recorded response samples.
- P95 is calculated from the stored time-bucket averages.
- The result represents the slow tail of summarized periods, not an exact percentile across every old raw request.
This distinction matters most when comparing a short range with one month or one year. Long-range values are intended for trends and reliability review. Use Detailed Logs within the 30-day raw-check retention window for per-request analysis.
What response time includes
The measurement covers the monitoring request from the Uptime Basics worker. It can include DNS lookup, connection establishment, TLS negotiation, redirects, server processing, and transfer time needed to complete the configured GET or HEAD request.
It does not measure:
- Browser rendering or visual completeness.
- JavaScript execution after the HTTP response.
- User interaction, checkout, login, or other multi-step transactions.
- Performance from every visitor location.
- Core Web Vitals such as Largest Contentful Paint.
The value can differ from a browser speed test because the request method, monitoring region, network path, cache, and page-rendering work are different.
Failed checks and missing samples
A failed check can still have a response time when the request reached a measurable failure, such as an HTTP error. A DNS or connection failure may have no useful response-time sample.
The response chart can therefore contain fewer measurements than the total-check count. A dash means no applicable response duration was available; it does not mean a zero-millisecond response.
Availability and response speed are separate:
- A response within the timeout can be Up even when it is slow.
- A timeout is an availability failure.
- Slow-response alerts use their own threshold and confirmation count and do not automatically mark the website Down.
How to investigate a high p95
- Compare the 24-hour and 7-day ranges.
- Hover over the response-time chart to locate slow time buckets.
- Look for red failed-check markers near the same period.
- Open Detailed Logs and sort by latency.
- Compare status codes, diagnoses, and timestamps for the slow rows.
- Review whether a deployment, backup, traffic peak, or upstream service matches the timing.
- Configure a slow-response alert if the delay is operationally important.
Avoid choosing a slow-response threshold from one isolated spike. Use a representative period and set a value that identifies meaningful degradation without creating unnecessary notifications.