How often is an upstream signal right?
An upstream signal says: several companies that share a provider declared incidents within the same hour, and that is very unlikely to be coincidence. Here we run the exact live rule over the last — days and check each signal against the providers' own records and the companies' own words.
Loading the latest results…
Signals per week—— in — days
Named or confirmed—no cases yet
Lead vs provider—needs confirmed signals
Provider incidents caught—no cases yet
The rule, exactly
Rule cs-v1, fixed before this evaluation.
| Step | Definition |
|---|---|
| Input | Official incidents of minor impact or worse from machine-readable status pages, read every 10 minutes; mirrored pages count once. |
| Groups | Companies sharing a cloud region, hosting provider, CDN or DNS provider (most common value across their monitored services). Groups need at least two companies. |
| Window | At least two different companies of a group declare within — minutes. |
| Chance model | Each company's own incident rate over 84 days, scaled by the hour-of-week rhythm of all declarations; probability that at least that many companies declare by chance (Poisson-binomial). |
| Threshold | Signal when that probability is below 0.001 (1 in 1,000). |
| Attribution | An incident whose title blames a different provider is not counted for this one. Overlapping signals whose company sets nest are merged and keep every shared provider, most surprising first. |
| Evidence | Confirmed: the provider's own record reports an incident that started within two hours. Named: an affected company names the provider or region. Otherwise statistical. |
Every signal in the window
Retrospective run of the live rule. The odds are the chance of seeing this many simultaneous declarations by coincidence.
| Date | Likely upstream | Layer | Companies | Evidence | Odds |
|---|---|---|---|---|---|
| No signals in the window. | |||||
See each signal with the companies' incident titles and links on the Upstream Signals page.
Sensitivity to the threshold
The threshold was fixed at 1 in 1,000 in advance. Looser thresholds produce many more signals that are much less often backed by evidence, which is why we did not choose them.
| Threshold | Signals | Per week | Named or confirmed | Confirmed by provider |
|---|---|---|---|---|
| No rows yet. | ||||
Against the providers' own records
Significant incidents published by AWS (Health Dashboard), Google Cloud, Cloudflare, Akamai and Vercel. “Declaring” counts companies on that provider that declared an incident around the same time; with fewer than two, no signal is possible by design.
| Started | Provider | Provider's title | Declaring | Signal |
|---|---|---|---|---|
| No rows yet. | ||||
All — provider incidents: no cases yet caught. Incidents where at least two followed companies declared: no cases yet.
Limitations
| Limitation | What it means |
|---|---|
| Rates are estimated in-sample | Company incident rates come from the same 84 days the test runs on, which slightly favours the rule. The live detector uses the trailing 84 days. |
| Coverage | Only companies with machine-readable status pages and a mapped infrastructure take part, mostly developer and SaaS companies. |
| Provider records are incomplete | AWS and Google publish only significant events, so 'statistical' signals may be real provider problems that were never posted. |
| Declarations lag | Companies declare minutes to hours after problems start; a signal cannot be earlier than the second company's declaration. |