Blog · 2026-10-13
A probe and a thousand people: how the verdict is decided
Why community reports travel alongside the probe reading rather than replacing it, and the exact rules used to combine them.
Two kinds of evidence arrive here. A machine checks whether a service answers; people report what it is like to actually use it. They disagree constantly, and both can be wrong alone — so we keep them separate and print which one decided the verdict.
| Our probe | What people report | Verdict |
|---|---|---|
| unreachable | anything | Confirmed outage (probe) |
| answering, very slow | anything | Degraded service (probe) |
| answering normally | a spike against its own baseline | Problems reported (users) |
| answering normally | quiet | Operational |
Why a report alone can never declare an outage
Anyone can click a button. If enough clicks could produce a red "down" banner, the site would be trivially manipulated and useless in exactly the moment it matters. A confirmed outage therefore requires our probe to have failed; reports can raise a service to Problems reported, never to Confirmed outage.
And why a successful probe never silences a spike
The reverse error is just as bad. If a working HTTP response automatically meant "nothing to see here", the site would be blind to the app-level failures people actually experience. So a spike in reports still changes the verdict even while the service answers — it just says what it is, rather than overstating it.
Counted against the service's own normal
M-PESA receives more reports on a quiet Tuesday than a small utility portal sees in a month. A raw count would call that a permanent incident, so each service is compared to its own baseline over the past seven days, with a floor so a brand-new service cannot look alarming after a handful of reports. One report per person per service per fifteen minutes is counted; the rest are acknowledged but not counted. IP addresses are stored only as a salted hash used for that deduplication.
How to report well
Use the report buttons on a service page, and use the optional note for what a probe cannot express: "the OTP never arrives", "payment fails after the confirmation screen". A specific report is the one that helps someone else decide whether to keep trying.
Other posts: