Ethereum method
eth_syncing
Reports whether the node is still catching up with the chain.
How each provider handles it
| Provider | Status | Success | Median |
|---|---|---|---|
| Tenderly | Supported | 100.0% | 13 ms |
| Cloudflare | Supported | 100.0% | 21 ms |
| PublicNode | Supported | 100.0% | 28 ms |
| dRPC | Supported | 100.0% | 37 ms |
| MEV Blocker | Supported | 100.0% | 50 ms |
| NodeReal | Supported | 100.0% | 62 ms |
| Merkle | Rate limited | 4.2% | 121 ms |
| 1RPConerpc | Rate limited | 0.0% | — |
| Blast API | Not measured | 0.0% | — |
Success excludes calls the provider does not implement — an optional method a provider declines to offer is a capability fact, not a failure, and is never scored as one.
Over time
Median latency per minute. Gaps are periods with no measurement, drawn as gaps rather than joined across — a line through missing data invents a measurement that was never taken.
Logarithmic scale — each gridline is ten times the one below it. Click a provider in the legend to hide it. 2 providers are not plotted: they returned no successful response in this window, so they have no latency.
What it does
Returns `false` when the node is synced, and an object with `startingBlock`, `currentBlock` and `highestBlock` when it is not.
A syncing node answers requests normally and quickly while serving state that is hours or days old. Nothing else in the JSON-RPC surface tells you this.
Returns
Object | false.
Try it
Runnable as written, against a keyless public endpoint. Nothing here needs an API key.
Request
curl -s https://ethereum-rpc.publicnode.com \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'As JSON-RPC
{
"jsonrpc": "2.0",
"method": "eth_syncing",
"params": [],
"id": 1
}Response
{
"id": 1,
"jsonrpc": "2.0",
"result": false
}Things that bite
- Behind a load balancer this reflects whichever node answered, so
falseis not a promise about the fleet. - Clients may add fields beyond the documented three. Parsers that reject unknown keys break on some providers.
Why it is measured
It is the only self-reported health signal in the standard API, and it is worth recording precisely because a syncing node looks healthy on every other metric.
Called every 300 seconds per endpoint, with jitter so the fleet does not hit a provider in lockstep.
1h window · generated 2026-10-08 18:12:50 UTC · 9 providers