99.99% Uptime Does Not Mean 99.99% Data Delivery
HTTP RPC checks can pass while separate WebSocket streams go silent, disconnect, or miss live updates.
Main idea
Uptime tells you whether the service was available. Data delivery tells you whether real-time chain updates arrived.
Availability SLAs are useful because they define contractual service expectations. But availability does not prove data delivery. Real-time DeFi systems also need to know whether the updates they depend on arrived when they were needed.
Not just reachability
HTTP checks may still pass.
Not just latency
The request may still be fast.
Availability SLAs and real-time delivery measure different things
Most RPC availability SLAs are designed around service reachability, confirmed downtime and exclusions. Those guarantees matter, but they mostly describe whether a provider was officially "up".
Real-time systems need an additional signal: whether live chain updates actually arrived.
An RPC endpoint can satisfy an availability definition while still producing delivery gaps that matter to real-time DeFi systems.
Public SLA pages make this distinction visible. They typically define availability around service connectivity, API unavailability, HTTP errors and confirmed downtime. Chainstack defines downtime around service connectivity and confirmed customer-reported issues. GetBlock publishes a monthly availability formula and ties downtime to HTTP 503 Service Unavailable. Alchemy defines monthly uptime around API unavailability with SLA exclusions. QuickNode advertises 99.99% uptime backed by an SLA.
These are availability commitments. They are useful, but they do not prove that a stream delivered every expected update to a real-time application.
WebSocket subscriptions have their own failure modes
WebSocket subscriptions let applications receive real-time events instead of repeatedly polling an RPC endpoint. But subscriptions are not durable delivery guarantees.
The Geth pub/sub documentation states that notifications are sent for current events, not past events. Subscriptions are tied to the connection that created them, and if the connection closes, the subscriptions created over that connection are removed.
The operational takeaway is simple: subscriptions need to be monitored as live streams, not assumed to be durable delivery channels.
Real-time data quality can vary by location and route. A provider may look healthy overall while one path cannot receive the live data an application depends on.
Observed incident
On July 3, 2026, QuantLoop observed an Ankr Ethereum WebSocket issue affecting three regions: ORD, NRT, and EWR. For approximately 64 minutes, those paths could not receive live Ethereum data and missed 322 blocks in real time.
Five other QuantLoop probes stayed healthy during the same window. From the outside, Ankr was not down everywhere but some paths still lost real-time data. That is the gap basic uptime checks miss.
Read the Ankr WebSocket incident noteHead-stream silence
QuantLoop defines a head-stream silence event as an active WebSocket newHeads subscription going 60 seconds without a message. At that point, QuantLoop treats the stream as silent and reconnects the observer.
active_subscription
AND no newHeads received for 60 seconds
Because QuantLoop intentionally reconnects at the 60-second threshold, this metric does not measure how long the stream would have remained silent. It measures how often a stream became silent long enough to require recovery.
Head-stream silences
Ethereum mainnet sample, June 1-19, 2026 UTC. Measured from us-east. Providers anonymized.
| Provider | Count | Missed updates |
|---|---|---|
| Provider A | 1 | 8 |
| Provider B | 8 | 35 |
| Provider C | 4 | 27 |
| Provider D | 2 | 13 |
| Provider E | 5 | 29 |
A silence event does not automatically prove that the provider was down. It means the real-time stream stopped producing newHeads messages for longer than the allowed threshold.
Block delivery completeness
Block delivery completeness measures the share of expected block numbers received from a real-time head stream during the measurement window.
Block delivery completeness by provider
Ethereum mainnet sample, June 1-19, 2026 UTC. Measured from us-east. Providers anonymized.
| Provider | Expected updates | Received updates | Missed updates | Completeness |
|---|---|---|---|---|
| Provider A | 129,095 | 129,003 | 92 | 99.93% |
| Provider B | 129,095 | 129,028 | 67 | 99.95% |
| Provider C | 129,095 | 129,059 | 36 | 99.97% |
| Provider D | 129,095 | 129,070 | 25 | 99.98% |
| Provider E | 129,095 | 128,994 | 101 | 99.92% |
The percentage difference looks small because every provider in this sample delivered more than 99.9% of expected block updates. The missed-update count adds useful context: high availability does not mean every live update arrived, and small percentage gaps can still represent dozens of missed real-time events.
Not every stream issue looks like silence
Some stream failures happen immediately: the connection ends, errors, or drops before reaching the silence threshold.
Stream continuity events
Ethereum mainnet sample, June 1-19, 2026 UTC. Measured from us-east. Providers anonymized.
| Provider | Terminations | Error closes | Total disconnected time |
|---|---|---|---|
| Provider A | 9 | 100 | 11m 38s |
| Provider B | 0 | 75 | 5m 59s |
| Provider C | 0 | 12 | 1m 20s |
| Provider D | 0 | 3 | 12s |
| Provider E | 25 | 75 | 13m 24s |
Providers A and E accounted for the most disconnected time in this sample. Failure counts show how often streams broke; disconnected time shows how long the application was without an active WebSocket stream while it recovered.
What changes when live data is incomplete
For a real-time DeFi system, incomplete data changes the local picture of the chain. The endpoint may be reachable, the dashboard may look healthy, yet the application may be acting on a stale view.
Availability tells teams whether the service was reachable. Delivery completeness tells them whether their application received the data it needed to keep its view of the chain up to date.
FAQ
Does RPC uptime mean every live update was delivered?
Does RPC uptime mean every live update was delivered?
No. RPC uptime means an endpoint was reachable or available according to a provider's uptime definition. It does not prove that a WebSocket subscription delivered every live chain update during the same period.
What is block delivery completeness?
What is block delivery completeness?
Block delivery completeness measures how many expected block updates were received from a provider's live head stream during a measurement window. QuantLoop calculates it as received block updates divided by expected block updates.
How is block delivery completeness different from RPC uptime?
How is block delivery completeness different from RPC uptime?
RPC uptime measures whether the endpoint was available. Block delivery completeness measures whether the expected live block updates actually arrived. A provider can have high uptime and still miss real-time block updates.
How is block delivery completeness different from RPC latency?
How is block delivery completeness different from RPC latency?
RPC latency measures how fast a request or response completed. Block delivery completeness measures whether expected live updates arrived at all. A fast RPC response does not prove that a WebSocket stream was complete.
Why do WebSocket disconnections matter for DeFi systems?
Why do WebSocket disconnections matter for DeFi systems?
WebSocket disconnections interrupt real-time data delivery. After a disconnection, a DeFi system needs to reconnect, resubscribe, replay missed data, detect gaps, or fail over to another provider.
What is a WebSocket silence event?
What is a WebSocket silence event?
A WebSocket silence event happens when a stream stays connected but produces no expected messages for a configured period, such as 60 seconds. It does not automatically prove that the provider was down.
What should real-time DeFi systems monitor beyond RPC availability?
What should real-time DeFi systems monitor beyond RPC availability?
Real-time DeFi systems should monitor stream continuity, missed data updates, WebSocket disconnections, silence events, recovery time, and fallback provider behavior. Availability alone does not show whether live chain data stayed current.