Here's an uncomfortable exercise: two vendors both report 99.95% uptime last month. Vendor A genuinely ran clean. Vendor B had a six-hour partial outage — but their checker only probes once every five minutes from one region, "degraded" doesn't count as down, the maintenance flag got applied retroactively to the worst hour, and the number is quietly computed over the quarter. Same four digits on the report.
The number itself tells you almost nothing. What tells you everything is the methodology — and whether the report discloses it. This is a field guide to both sides of that report: auditing one you've been handed, and publishing one that survives an audit. (For the vocabulary — SLA vs SLO vs SLI — see our primer; this post is about where the numbers bend.)
The five places uptime numbers bend
1. What counted as "down"?
The biggest lever isn't measurement — it's definition. If "down" means the homepage returned non-200, then all of these count as up: an API erroring for half of requests, checkout latency at 30 seconds, one region dark, TLS broken for older clients. A serious definition covers the service's actual function — API correctness, not just page load — and states how degraded time is treated. Fully-down-only definitions are how a vendor has "four nines" while their customers had a terrible month.
The honest disclosure: what endpoints, what counts as failure, and how degraded time is treated. (In WatchFor, "down" is deliberately conservative — a confirmed incident, not a single failed probe — and degraded is a visible, separate state rather than silently bucketed into "up.")
2. How was it measured?
Three sub-questions, each worth minutes or hours of hidden downtime:
- From where? One vantage point can't distinguish "site down" from "route to the site down" — and worse, an outage invisible from that one point doesn't exist. Multi-location checking with confirmation is the standard: an incident requires several regions to agree, which kills both false alarms and single-region blind spots.
- How often? A 5-minute interval means any outage under 5 minutes may not exist in the record, and every outage's edges are fuzzy by up to the interval. At 30–60s intervals the record starts resembling reality. (Checking faster during incidents — as WatchFor does — tightens the recovery edge too.)
- Was the checker up? Gaps in monitoring silently become "up" in naive math. Honest reports treat unmonitored time as unknown, not as uptime — the same reason WatchFor's status heatmaps can dim days from before monitoring existed instead of painting them green.
3. What was excluded — and was it disclosed?
Planned maintenance is the legitimate exclusion, and also the classic loophole. The difference is entirely procedural:
- Honest: maintenance is scheduled in advance, announced, alerts suppressed for the window, and the report says so explicitly — "99.98%, excludes 2h of scheduled maintenance". The exclusion is visible, auditable, and can't be created after the fact.
- Dishonest: the outage happens first, gets labeled "emergency maintenance" second, and vanishes from the number third. If the tooling allows retroactive maintenance labeling, every incident is one awkward meeting away from becoming "planned."
This is why WatchFor's maintenance windows are the only source of planned-work labeling, why they must exist before the work, and why the exclusion is printed on the SLA report rather than absorbed into it. An exclusion you can't see is indistinguishable from a lie.
4. Over what window?
99.9% allows ~43 minutes of downtime per month — or ~8.7 hours per year. A vendor reporting yearly can absorb a brutal week invisibly; monthly windows keep every incident's weight visible. Check also whether the window is calendar-aligned or a rolling period chosen after the incident — "the last 30 days" computed the day before the anniversary of a big outage is a remarkably popular choice.
5. Does the number match the incident history?
The cheapest audit: put the claimed percentage next to the public incident log. 99.99% claimed and three multi-hour incidents listed? Something in items 1–4 is doing heavy lifting. No public incident history at all? That's your answer about the culture. A vendor confident in their methodology shows the number, the incidents, and the exclusions on the same page — because they reconcile.
Writing one that survives this audit
If you publish SLA numbers — on a status page, in enterprise deals — the playbook is just the five items, done in the open:
- Define down and degraded in terms of user-visible function, and measure the API, not just the homepage.
- Measure from multiple regions with confirmation, at an interval that matches the granularity you claim (don't report minutes of downtime from five-minute checks).
- Exclude only pre-scheduled maintenance, and disclose every exclusion on the report itself.
- Report monthly, calendar-aligned, with history visible.
- Publish the incident log next to the number — a status page with per-component uptime history does this structurally.
There's a compounding payoff: honest reports are boring to defend. Procurement asks how the number is computed; you point at the methodology on the page; the conversation ends. The vendors with the shiniest numbers get the longest security reviews — because everyone has met Vendor B before.
WatchFor's SLA reporting is built around these rules by default: multi-location confirmed incidents, degraded as a first-class state, maintenance excluded only via pre-scheduled windows and always disclosed on the report, per-monitor and per-component history you can put in front of a customer. The uptime calculator translates any percentage into real allowed downtime — useful for both reading targets and setting your own.