Each row compares two times. Our checks first failed from two or more distant regions at T; the vendor's status page posted the incident at T plus the lag shown. A negative lag means the vendor posted first. Neither time says what users saw, and a lag is not a finding about why. The whole record is in the CSV, one row per incident.
By service, last 90 days
- Measurement window
- 2026-08-09 18:18 UTC to 2026-11-07 18:18 UTC
- Methodology
- version v2-2026-08-22
- Coverage
- Tracking incidents with both records since Aug 31, 2026 (68 days of coverage)
- Figures
- Live, recomputed on each visit
| Service | Incidents with both records | Median lag | Range | Vendor posted first |
|---|---|---|---|---|
| Linode (Akamai) | 2 | 22 min later | 29 min earlier to 72 min later | 1 |
| Codecov | 1 | 6 h 48 min later | 6 h 48 min later to 6 h 48 min later | 0 |
| Figma | 1 | 634 h 36 min later | 634 h 36 min later to 634 h 36 min later | 0 |
| Shopify | 1 | 4 h 36 min earlier | 4 h 36 min earlier to 4 h 36 min earlier | 1 |
Most recent incidents
Method
- Our time is from a probe event that met the rule for a public outage: checks failing from distant regions, never retracted. T is the moment a second region began failing, so a single region is never the start, and the later of the two times only ever shortens the lag shown.
- The vendor's time is the publication time on its own status page: the incident's creation time on a Statuspage page, its publication time on an incident.io page. A status page that publishes no such time is left out, and the time we first read an incident never stands in for it.
- An event and an incident are paired when the vendor's declared span overlaps ours within 30 minutes and the post falls within 6 hours of our event. Each event takes its earliest such post, and each incident pairs with one event at most. Incidents of impact none and maintenance are not counted.
- Where a service shares a status page with others, only the incidents that name its own components are its own. Our checks are listed on each service's page and in the methodology.
- Recomputed from the stored records on each visit. A pairing that is wrong is corrected in place and logged at corrections.