Benchmarks
Provider incidents
An availability percentage has no shape. A provider that failed for twenty minutes and one that failed a request an hour all day can end the window with the same figure — this is the difference between them: when it started, how long it lasted, and which call it affected.
What happened
SubscribeRuns where a provider departed from its own normal behaviour. A provider that always fails a given call is not having an incident when it fails it today — those are below, counted once each rather than repeated down this list.
Nothing departed from normal in this window.
A quiet feed is a real finding: every provider behaved the way it usually behaves. The persistent conditions below are unaffected by that — they are what normal is.
Persistent conditions
the same across the whole windowCalls a provider fails, or refuses, at about the same rate every day. Not events — the availability figure already carries them — but the thing most worth knowing before choosing a provider, because none of it will improve tomorrow.
No persistent conditions in this window.
Every measured call, on every measured provider, succeeded often enough not to qualify.
What got slower, and what got faster
against each provider’s own pastThe last 24 hours against the 7 days before, per call. Compared against itself rather than against the field: the ranking already says who is slower than whom, and a provider that has always been the slowest is not regressing — it is slow.
Nothing moved materially.
Every measured call is within a quarter of its own recent normal. Percentiles wander a few per cent between any two windows; a feed that reported those would be noise with a threshold.
What counts, and what does not
Our own failures are not theirs
An agent that could not reach the network, or our own software failing, is our outage. Both are removed before anything is judged — the same exclusion the score makes.
Rate limiting is not failure
A provider enforcing its published limits is behaving correctly, so it has its own colour here. A sustained refusal is still reported, as throttling rather than as an outage.
Incidents are per method, not per provider
Rolling one failing call up to the provider manufactures outages: a single method erroring a fifth of the time drags a whole-provider success rate below any sensible threshold permanently.
A single bad minute is not an incident
One failed request is a blip. A run has to last long enough that somebody could have noticed — at least 3 minutes.
Durations are floors, never estimates
Only minutes with measurement behind them are counted, and a gap longer than the tolerance ends an incident rather than being spanned. An incident is never reported as longer than what was observed inside it.
A chronic defect is not an event
Judged against the series’ own rate across the whole window — the same principle the ranking applies to latency, where a provider consistently slower than its peers is slower rather than degraded.
Derived from per-minute measurement aggregates rather than stored, so this feed cannot describe something the observations do not. Our own failures — an agent that could not reach the network, our own software failing — are excluded: they are our outage, not the provider's. Rate limiting is reported as throttling rather than as failure, because a provider enforcing its published limits is behaving correctly. A single bad minute is not an incident, and an incident is measured per method: rolling one failing call up to the provider would report an outage for a provider that was serving everything else perfectly. An incident is never reported as longer than the minutes actually measured within it, so durations are floors rather than estimates. A series that fails at about the same rate all week is marked chronic and left out by default — it is broken rather than having an outage, which the availability figure already says, and treating it as news would bury the runs that are.