SLA receipts — June 2026
Vendors publish an uptime commitment. We measure uptime independently from real client-side traffic. This page puts the two numbers side by side for the last complete calendar month.
0 Came in under their published SLA
0 Met or beat it
0 No published SLA on file
We don't yet have a published SLA figure on file for any tracked API, so there's nothing to compare for June 2026. Published targets are recorded per vendor with a link to the document that states them.
Methodology, plainly
- Our number is not the vendor's number. We measure from anonymised client-side signals sent by applications using the APIdown SDK. A vendor's own SLA accounting uses their internal instrumentation and their own definition of an outage. The two will not match, and where they differ theirs is the one that governs your credits.
- Downtime is attributed from detected incidents, clipped to the calendar month. Overlapping incidents are merged, so concurrent problems are not double-counted.
- Client-side measurement includes the network path. Failures caused by routing, DNS, or a CDN edge count against the API here, even where a vendor would exclude them.
- Published targets are only recorded with a source. Each percentage links to the vendor document stating it. Where we have no sourced figure, we say so rather than estimate one.
- Scope varies by vendor. A commitment may cover one service, one tier, or one region. Hover a target to see the caveat we recorded.
Nothing here is a legal determination of whether an SLA was breached or credits are owed. Use it as an independent second opinion, then check the vendor's own status history.
See also the reliability leaderboard and per-API incident history.