Status
Whether each measured endpoint is serving right now, and how it has held up against an availability objective this site publishes and applies identically to everyone. That objective is ours — not an SLA, and not a promise any provider made.
1 provider is refusing most of what we ask
30 days ago30 of 30 days measured · 190,540 requests refused rather than answered, excluded from the figuretoday
Error budget at 99.9%: 538× over — 12,304 failures against the 23 failures this many requests earn
too few recent requests to say how fast it is burning
30 days ago30 of 30 days measured · 49,173 requests refused rather than answered, excluded from the figuretoday
Error budget at 99.9%: 2.9× over — 3,168 failures against the 1,076 failures this many requests earn
burning 0.0× over the last 497 requests
30 days ago30 of 30 days measured · 22,445 requests refused rather than answered, excluded from the figuretoday
Error budget at 99.9%: 35% spent — 793 failures against the 2,274 failures this many requests earn
burning 0.0× over the last 1,029 requests
30 days ago30 of 30 days measuredtoday
Error budget at 99.9%: 36% spent — 402 failures against the 1,121 failures this many requests earn
burning 0.0× over the last 515 requests
30 days ago30 of 30 days measured · 33,661 requests refused rather than answered, excluded from the figuretoday
Error budget at 99.9%: 81% spent — 903 failures against the 1,115 failures this many requests earn
burning 0.0× over the last 512 requests
An SLA is a contract: a promise a provider made, with a remedy attached when it is broken. Almost none of the endpoints measured here carry one, so the bar below is ours. A provider that misses it has not broken a promise — it has failed to clear a threshold we set.
A single threshold says little: at 99.9% almost every free endpoint fails, and at 99% almost everything passes. Each provider is reported at the highest rung it actually cleared, and reported as not enough data — never as failing — where fewer than 500 requests were eligible. Not knowing and failing are different findings.
The pill beside each endpoint and the uptime percentage beside it are judged at different bars, deliberately. The recent window holds a few dozen requests, which can tell “mostly working” from “mostly broken” and cannot tell 99.9% from 100% — so the pill uses 90% and the percentage uses the objective. A green pill beside a 99.5% figure is those two statements agreeing, not disagreeing.
eth_chainId2026-10-07 15:43 · 6m measuredeth_blockNumber2026-10-07 13:38 · 11m measuredeth_blockNumber2026-10-07 11:06 · 7m measuredDurations are floors: only minutes with evidence inside them are counted, so an incident is never reported as longer than what was measured. The full record
This is an objective we publish and apply identically to every provider. It is not a service level agreement: nothing here is a promise any provider made, and a provider that misses it has not broken one. What a provider does commit to, where it commits to anything, is quoted on its own page with the source and the date it was read. Availability is taken over requests the provider could reasonably have answered — rate limits, methods it does not implement and methods it sells rather than gives all leave the denominator, and the counts that left are published beside the percentage so it can be judged. A day nothing was measured is drawn as a day nothing was measured, never as a day everything worked, and it is excluded from the uptime figure rather than counted as perfect. Every measurement comes from a single vantage point, so a component shown as operational was reachable from there.
The full record, including the persistent defects deliberately kept out of the incident list, is on the incidents page; what each provider says it permits is on its own page, and how every figure here is produced is on the methodology page.