Methodology & accuracy
How we decide something is down — and how often we’re right
Computed live from the last 7 days of raw probe data against the 25 services that publish an official status page. Not curated — good and bad numbers alike.
11times we were first83 min ahead on average, up to 137 min
15%anomalies confirmed by vendor44 of 292 anomalies overlapped an official incident
78%likely false alarms228 lasted < 10 min with no official post
78%major official incidents we also saw21 of 27
How to read these numbers
- 20 anomalies lasted over 10 minutes with no official incident. They may be unreported by the vendor or our mistake — we can’t tell on our own, so we don’t count them as correct.
- “Major official incidents we also saw” is lower mainly because many official incidents affect the web app, mobile apps, voice or video — while we measure the API. A web-only outage often leaves the API working.
- We keep adding real inference tests (not just listing models) to catch “API reachable but answers fail” cases.
Recent incidents we caught first
Cursor IDEAuto Review Degradation · 2026-10-29 23:44 UTC126 min early
KimiKimi Code K3 TTFT 响应延迟升高 · 2026-10-28 09:06 UTC84 min early
FireworksService Degradation for MiniMax M3.1 Flash · 2026-10-28 05:56 UTC10 min early
1
Real calls
Every 2 minutes we call each vendor’s official API with a real key (list models / a minimal request) and record status, latency and time-to-first-token.
2
Multi-region
Probes run from several regions so a single network blip is not reported as an outage.
3
Consecutive failures
A service needs 2+ consecutive failed checks (~4 min) before we call it an anomaly — single timeouts are ignored.
4
Cross-checked
We also read the official status page. Measured data and official posts are shown separately; vendors cannot edit our measurements.