Check history and charts#
Click through from the Dashboard to a check’s own page for its full history: a response-time chart, an uptime table, and individual recent results.
Time range#
The chart has a range picker: 1h, 24h, 7d, 30d, 6mo, 12mo, all. Your choice carries through everything else on the page — paging through recent results or switching which monitor you’re looking at won’t reset it.
Longer ranges use pre-aggregated hourly or daily data rather than every raw result, which changes what the Max / Min / Avg caption under the chart means: at 1h/24h it’s computed from actual response times; at 7d and beyond, each point is an average across every attempt in that period — including failed ones, since aggregated data has no separate record of which attempts actually got a response back. A response time of 0 always means the target sent nothing back at all (timeout or connection failure), not a genuinely instant response.
all has no fixed start — it stretches back as far as your server’s
configured data retention goes, so how far back it actually reaches depends
on that setting.
Grouping monitors#
If more than one monitor runs this check, three view options group them differently:
- Grid (the default here) — a full matrix, one column per monitor.
- All monitors — every monitor merged into one row, for a quick overall read.
- Private / Shared — split into two groups by monitor class.
The chart itself is always one line blending every monitor together, regardless of which grouping you pick for the tables below it — it already had that shape before grouping existed.
Uptime and recent results#
The Uptime table shows a percentage per monitor (or per group, if grouped) over the selected range. A grouped percentage is weighted by actual attempts, not averaged from each monitor’s own percentage — so one monitor with ten times the sample count of another correctly counts for more.
Recent results lists individual attempts, each with a pass/fail status and a view link to see the full response detail (error message or response body sample) captured at the time. Filter this list down to one monitor, or by class, using the same controls as the tables above.
Testing a check on demand#
The Test link on a check runs it once, right now, from the server, and shows you exactly what came back — useful when you’re not sure a match rule or status-code condition is written the way you think it is. It’s refused for a target that isn’t reachable from the public internet (the server never makes outbound requests to internal addresses, even for a test).