Status, including the part where there is nothing to report.
Eight services with published thresholds and availability objectives, an empty incident log, and no uptime history — because none of this has run in public long enough to have one. The live check panel is the only measurement anywhere on this page: it runs an Ethereum JSON-RPC call from your browser, right now, and reports whatever happens.
No availability record yet
Reading component definitions…
Live check from your browser
These are the third-party feeds this site reads directly. A BLOCKED result means your network or extensions stopped the request — it says nothing about protocol health, and the page is built to work either way.
Eight services, and what each one is held to
One bar per day for the last ninety. They are all empty: no availability has been recorded for any of these services yet. The latency figures are the objectives they are built against, not measurements taken from a running cluster.
Nowhere yet, and that is the honest answer. There is no monitoring pipeline behind this page, so there is no availability series to draw and we have not invented one. The p50/p95/p99 figures are the design targets each service is built against, and the availability column is the objective it will be measured against once measurement exists. When a real monitoring provider is wired in, this paragraph changes and the bars fill from that day forward — not backwards.
Zero incidents, because there is nothing in public to break
Impact first, then the timeline, then the root cause, then what changed. That is the shape every entry here will take. There are no entries.
What counts as degraded, and what counts as down
Published thresholds, so “operational” will be a measurement rather than an opinion the day there is something to measure.
| Component | Degraded when | Outage when | Objective |
|---|---|---|---|
| REST API | p95 above 400ms, or error rate above 0.5% | Error rate above 5% for 60 seconds | 99.9% / 30d |
| WebSocket stream | Event lag above 2s, or reconnect rate above 2% | Connections refused for 60 seconds | 99.9% / 30d |
| Solver network | Auction close p95 above 1.5s, or fewer than 5 solvers quoting | Fewer than 2 solvers quoting | 99.5% / 30d |
| Indexer | Staleness above 90 seconds on any chain | Staleness above 10 minutes on any chain | 99.5% / 30d |
| RPC gateway | Error rate above 1%, or failover engaged | All providers failing on one chain | 99.95% / 30d |
| Settlement · per chain | Inclusion p95 above 3× the chain’s block time | No inclusion for 20 blocks | 99.9% / 30d |
Chain congestion
A settlement that is slow because the chain is busy is the chain working as designed. We report inclusion latency but do not count it against settlement availability.
Intents held by policy
A refusal is the protocol working. Held-intent volume is on the protocol dashboard, not here.
Anything that misreports state
A stale indexer that answers confidently is worse than one that errors. Silent wrongness is treated as an outage even when every service is technically up.
Get told when something breaks
One message per incident: opened, updated, resolved. Postmortems go out when they are published, not before. No product announcements on this list, ever — and on current evidence, no messages at all for a while.
Verify it yourself.
Nothing on this page asks you to take our word for it. The probe runs in your browser, the thresholds are written down, and the incident log is empty in public rather than curated in private.