The response-time chart shows how the monitored endpoint's recorded response duration changed during the selected range. Use it to locate slow periods, compare performance before and after a change, and identify whether latency increased around an outage.
Read the axes
- The vertical axis shows response time in milliseconds.
- The horizontal axis shows time across the selected 24-hour, 7-day, 1-month, or 1-year range.
- The green line connects average response times for the displayed time buckets.
The vertical scale adjusts to the data. A line near the top means a higher response time relative to the chart's current scale; always read the millisecond labels before comparing two screenshots.
What each point represents
The chart does not always represent one individual request per point:
- 24 hours: five-minute summary buckets.
- 7 days: hourly summary buckets.
- 1 month: hourly summary buckets.
- 1 year: daily summary buckets.
Each plotted value is the average of response-time samples recorded in that bucket. A one-month chart can therefore contain many hourly averages, while its Uptime Timeline separately combines results into daily calendar blocks.
Hover for exact context
Point to a section of the chart to see:
- The bucket's start and end labels.
- Average response time for that bucket.
- Total, successful, and failed check counts.
- Whether the bucket had failed checks, healthy checks, or no checks.
Use the account's configured time zone when comparing chart labels with deployments or server logs.
Failed-check markers
A red vertical marker indicates that the bucket contains at least one failed check. It does not mean the endpoint was Down for the full width of that bucket or that an incident necessarily opened.
Hover over the bucket, then open Detailed Logs or the relevant incident to review the exact failure. Regional confirmation and consecutive-failure rules can prevent an isolated failed check from changing the monitor's current status.
Gaps and No response data
A gap can appear when a bucket has no recorded response-time sample. Causes include:
- No scheduled check in that period.
- A paused or archived monitor.
- Time before the monitor was created.
- A DNS, connection, or TLS failure that ended without a response duration suitable for the chart.
- Historical data outside the retained range.
No response data yet means the selected range has no plottable response-time samples. It does not mean the endpoint responded in zero milliseconds.
Compare latency correctly
For a useful investigation:
- Start with 24 hours to locate a recent spike precisely.
- Compare 7 days to determine whether the time of day repeats.
- Use 1 month or 1 year for broad trends rather than individual-request proof.
- Compare Average response with P95 response.
- Open Detailed Logs and sort by latency for exact rows within raw-check retention.
- Check whether slow buckets align with failures, deployments, traffic peaks, backups, or upstream services.
Do not compare charts from different ranges solely by the line shape. They use different bucket sizes and can use different vertical scales.
Response time is not browser load time
The chart measures the configured HTTP availability request from Uptime Basics infrastructure. It does not render the page, execute client-side JavaScript, or calculate Core Web Vitals.
A site can return its HTTP response quickly but still feel slow in a browser. Conversely, a larger API response can take longer for the monitoring request while the visible page remains acceptable to users.