Every host publishes an uptime number. Few publish how it is measured, which makes the numbers impossible to compare: a provider that only counts full outages of its own website will always beat one that counts a degraded upstream in one city. This post is the methodology behind our status page: where the probes are, what counts as an incident, how partial degradation is scored, and why maintenance only stops counting against us if we announced it early.
Measured from outside, every 30 seconds
Uptime measured from inside a network is a self-assessment. Ours is measured by probes we rent from three unrelated providers on three continents (Europe, North America, Asia), none of them in our data centres. Every 30 seconds each probe checks every component: an HTTP request to a canary VPS in each site, a TCP handshake to the API, a DNS query to each resolver, a BGP-visible ping through each upstream, a login to the panel. The status page shows the median of the three probes; the raw results are kept for two years.
What a component is
The page lists 23 components: for each of the six sites, the compute network, the storage layer, and the transit and peering edge; globally, the panel, the API, DNS, and the payment pipeline. A component is the smallest thing that can fail on its own. “Frankfurt network” going degraded while “Frankfurt storage” stays green tells you more than a single “Frankfurt” light would.
Green, degraded, down
- Operational: all probes succeed within the latency budget for the component (200 ms for HTTP, 50 ms for ping from the nearest probe).
- Degraded: at least one probe fails two consecutive checks, or all probes succeed but outside the budget. Elevated packet loss on one upstream, a slow API, a storage node rebuilding under load all land here. Degraded time counts against uptime at half weight.
- Down: all three probes fail two consecutive checks, so one minute of confirmed unreachability. Down time counts at full weight.
Two consecutive failures rather than one is a deliberate choice: a single lost probe packet is not an outage, and a page that flickers is a page nobody trusts. The cost is that an incident is shown 60 seconds after it begins.
How the percentage is computed
For each component, monthly uptime is 1 − (down_minutes + 0.5 × degraded_minutes) / minutes_in_month. The site-wide figure is the average across components weighted by how many customers each one touches, so a degraded storage node in Los Angeles weighs less than a degraded panel. 99.99% for a month means roughly four minutes of confirmed downtime or eight minutes of degradation. We publish the per-component numbers alongside the aggregate precisely so the aggregate cannot hide anything.
What becomes an incident
Any component in the degraded or down state for more than five minutes opens an incident automatically, with the start time taken from the first failed probe, not from when a human noticed. The incident page gets updates from the on-call engineer as they happen and a post-mortem within five business days for anything that was down for more than fifteen minutes. Incidents are never deleted; the history page goes back to the launch of the site.
Maintenance: announced 72 hours ahead, or it counts
Planned maintenance is excluded from the uptime calculation only if it was posted on the status page at least 72 hours before it started, with a window and an expected impact, and only for the minutes inside the announced window. Emergency maintenance (a security patch that cannot wait) is counted as downtime like any other. The rule keeps the incentive honest: we can plan around customers, not around the statistics.
What is not measured
Your own server. The probes test our network, our storage layer and our control plane, not the workload you run. A server that stops answering because its disk is full is not an incident on the status page, although the panel alerts you to it. Similarly, an attack against a single customer that the mitigation absorbs is not an incident unless it affected others; the mitigation post explains why that is the goal.
How this feeds the SLA
The SLA credits in the terms are computed from these same numbers: the per-site monthly figure for the site your server is in, at the weights above, with no separate “SLA measurement” that could disagree with the public page. If the page shows 99.9% for your site last month, the credit applies automatically to your balance; you do not have to ask for it.