Status & uptime
From a check to a status
Section titled “From a check to a status”Every region runs its own checks on its own schedule and stores every result (success, HTTP code, latency, error). A status is first computed per region, from that region’s most recent checks only:
| Status | Rule (per region) |
|---|---|
| up | Last check succeeded, latency under 2 000 ms |
| degraded | Last check succeeded but took ≥ 2 000 ms, or it failed but the retry window isn’t full yet, or it answered a 3xx outside the accepted codes (a redirect mismatch, not an outage — unless the monitor sets 3xx = down) |
| down | retries + 1 consecutive failures from that region |
| paused / stale | Paused by you / no result received for 3 × the interval (agent or network problem, never treated as an outage) |
retries is set per monitor (default 1, so two consecutive failures are
needed). The first failure is a soft warning; a false positive caused by one
lost packet never pages you.
Multi-region monitors: the majority rule
Section titled “Multi-region monitors: the majority rule”When a monitor runs from several regions, each region judges the target on its own, then the monitor’s status is decided by a majority vote:
- DOWN — more than half of the configured regions have confirmed the failure (their retry window is exhausted). 2 of 3, 3 of 5, 2 of 2.
- PARTIAL OUTAGE (degraded) — at least one region confirms the failure but not a majority. The service is unreachable from somewhere — a regional network issue, a CDN edge, a geo-block — and you should know, but the majority of the world still gets through.
- UP — no region confirms a failure. Recovery is declared only once every region is healthy again.
What you get on your alert channels for a 3-region monitor:
- First region confirmed down → 1 alert — Partial outage (orange), listing the failing region.
- Second region confirmed → 1 alert — Down (red), listing both regions.
- Regions come back one by one → nothing yet…
- Last region healthy → 1 alert — Recovered, with the total downtime.
If the outage shrinks back below the majority before fully recovering, you get one Partial outage de-escalation, then Recovered when everything is green. A single-region monitor simply follows its one region (soft warning on the first failure, down after the retry window).
Where the status shows
Section titled “Where the status shows”The same aggregated status is shown in three places, always from the same numbers:
- The status pill in the top bar, on every dashboard page. Green “All systems operational · n up”; amber when at least one monitor is degraded; red and pulsing when at least one is down. Clicking it opens a condensed “Current status” card: activity line, proportion bar, the monitors that need attention with a link to each, the ongoing outage or the last incident, checks over 24 h, and a shortcut to declare an incident. It refreshes live from the same realtime stream as the dashboard. On mobile it becomes a dot (plus a count when something is wrong) in the header, opening the same card as a bottom sheet.
- The “Current status” card on the dashboard home.
- The “Alerts” badge in the sidebar — the number of unacknowledged alerts (see Alerts history).
Paused monitors and maintenance windows never colour the pill; they only appear inside the card.
How uptime % is calculated
Section titled “How uptime % is calculated”uptime % = successful checks ÷ scored checks (over the selected range)- All regions count: a 3-region monitor at 1-minute interval produces ~4 320 scored checks per day. A region that is down while the others are up therefore lowers uptime proportionally (one region out of three down for an hour ≈ 98.6 % for that hour), which is exactly what your users in that region experienced.
- Excluded from the score: checks during a maintenance window, results in the rate-limited state (HTTP 429 or an LLM provider quota — the service answered, you’re being throttled), and periods where the monitor was paused.
- Slow ≠ down: a check over 2 s is shown as degraded but counts as a success in uptime %.
- Downtime (minutes) = failed checks ÷ number of reporting regions × check interval — concurrent failures from several regions are the same wall-clock outage, not N outages.
- Ranges: dashboard cards use 24 h; status pages, reports and the API accept 24 h / 7 d / 30 d / 90 d / 365 d, always bounded by your plan’s retention (90 / 180 / 365 / 730 days).
Latency figures (average, p50/p95/p99) use only successful checks or checks that got an HTTP answer — a timeout’s 5-second give-up time never pollutes your response-time chart.
What the colours mean
Section titled “What the colours mean”The same four steps everywhere an uptime figure is shown — the badge on a monitor, the Uptime /24 h tile, every cell of the Availability grid and the public status page:
| Uptime | Tier | Colour | Roughly, over 30 days |
|---|---|---|---|
| ≥ 99.5 % | Excellent | Green | up to 3 h 39 lost |
| 98 – 99.5 % | Good | Light green | up to 14 h 30 lost |
| 95 – 98 % | Degraded | Amber | up to 36 h lost |
| < 95 % | Critical | Red | more than 36 h lost |
One caveat on the hourly grid: a cell can only take the values your check interval allows. At 5 minutes (12 checks in the hour) a single failure is 91.7 %, so the cell goes straight to Critical — it never passes through Good or Degraded. At 1 minute a single failure is 98.3 % and at 30 seconds 99.2 %, both Good. The tier is honest about what happened in that hour; the interval decides how finely it can say it.
On the Availability grid the green zone is drawn as a gradient rather than two flat blocks — deepest at 98 %, the full brand green at 100 % — so its legend shows the gradient without figures. Hover any cell for the exact percentage of that hour.