The Uptime Timeline gives a visual history of successful checks, failed checks, and periods with no data. It groups results into time blocks so you can find a problem before opening individual logs.
Timeline colors
| Color | Meaning |
|---|---|
| Green | The block contains one or more successful checks and no failed checks |
| Red | The block contains failed checks and no successful checks |
| Yellow | The block contains both successful and failed checks |
| Grey | No checks are available for that block |
Yellow is a mixed or degraded period. It does not necessarily mean a confirmed outage opened. One failed check can produce a yellow block even when confirmation checks prevented the monitor from changing to Down.
Grey is not downtime. It can represent time before the monitor existed, a paused or archived period, missing historical data, or a time bucket in which no scheduled check was recorded.
What one block represents
The visual grouping changes with the selected range:
- 24 hours: one block per hour, up to 24 blocks.
- 7 days: one row per day with up to 24 hourly blocks.
- 1 month: one calendar-style block per day.
- 1 year: one summary card per month, up to 12 months.
The underlying summary is more detailed for some ranges. For example, the 24-hour API uses five-minute rollups, but the timeline combines those points into hourly blocks to keep the display readable.
Use the hover details
Point to a timeline block to see:
- The hour, date, or month represented.
- The block's Up, Down, Degraded, or Unknown state.
- Total checks in the block.
- Successful and failed check counts.
The one-year cards also show monthly availability, failed checks, and total checks directly.
On touch devices, the compact layout may not provide the same persistent pointer behavior as a desktop mouse. Detailed Logs and incident pages remain the source for exact timestamps and failure evidence.
Why a red block is not the same as downtime duration
The timeline describes check outcomes inside a bucket. It does not claim that the website was unavailable for every second of a red or yellow block.
For example, one failed check in an hour containing no successful checks makes that hour red, even if the website recovered between scheduled observations. Similarly, a yellow hour can include a brief failure and many successful checks.
Use confirmed incident start and recovery times when reviewing outage duration. Use Detailed Logs to see the individual observations around the event.
Why timeline and current status can differ
Current status applies outage-confirmation rules. The timeline includes individual successful and failed results.
As a result:
- The monitor can currently be Up while an earlier block is red or yellow.
- A block can contain a failure without a confirmed incident.
- A new failing monitor can remain Unknown while failed checks are being confirmed.
- A recovered monitor can be Up while its selected range still contains outage history.
This is expected. The views answer different questions: current status asks what the service believes now; the timeline asks what check results occurred during the selected period.
Empty or incomplete timelines
No timeline data yet means the selected range does not contain summary points. For a new monitor, wait for its first scheduled check. For an older monitor, confirm the range overlaps its active history.
Recent raw checks are retained for 30 days. Aggregated rollups are retained for up to 400 days, allowing the one-year timeline to remain available without keeping every individual request.
Paused and archived monitors do not create new blocks, but their existing history continues to age under the same retention rules.