Skip to content

Ethereum method

eth_syncing

Reports whether the node is still catching up with the chain.

cheapCheap for a provider to serve — no state is read, or one key is.Primary specification (opens in a new tab)

How each provider handles it

9 providers

Provider support for eth_syncing on Ethereum
ProviderStatusSuccessMedian
1RPConerpcRate limited1.7%1516 ms
MerkleRate limited5.3%94 ms
NodeRealSupported100.0%86 ms
MEV BlockerSupported100.0%39 ms
dRPCSupported99.0%31 ms
PublicNodeSupported100.0%23 ms
CloudflareDegraded98.5%15 ms
TenderlySupported100.0%15 ms
Blast APINot measured0.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 hour. 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. 1 provider is not plotted: they returned no successful response in this window, so they have no latency.

When it degraded

A degradation is a bucket where a provider fell away from ITS OWN median for this method over the window, not from the cohort's. A provider that is consistently slower than its peers is not degraded — it is slower, which the ranking already says. Buckets with fewer than 20 samples are skipped, because a claim about a provider cannot rest on a handful of calls, and adjacent bad buckets are merged so one outage reads as one incident.

Cloudflare

  • success fell to 87.5% from a typical 100.0%

    availability · 2026-10-07 22:00Z → 2026-10-08 00:00Z

dRPC

  • success fell to 91.1% from a typical 100.0%

    availability · 2026-10-08 15:00Z

Merkle

  • success fell to 0.0% from a typical 8.3%

    availability · 2026-10-07 19:00Z

  • success fell to 0.0% from a typical 8.3%

    availability · 2026-10-08 00:00Z

  • success fell to 0.0% from a typical 8.3%

    availability · 2026-10-08 03:00Z

  • success fell to 0.0% from a typical 8.3%

    availability · 2026-10-08 07:00Z

  • success fell to 0.0% from a typical 8.3%

    availability · 2026-10-08 14:00Z → 2026-10-08 15:00Z

1RPC

  • success fell to 0.0% from a typical 17.5%

    availability · 2026-10-07 19:00Z → 2026-10-07 23:00Z

  • success fell to 0.0% from a typical 17.5%

    availability · 2026-10-08 01:00Z → 2026-10-08 17:00Z

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 false is 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.

24h window · generated 2026-10-08 18:27:35 UTC · 9 providers