SherwoodPulse
Independent · reads chains and Ethereum directly
Not affiliated with any operator
L2 liveness monitor

Chain alive,
or explorer stuck?

A frozen block number on an explorer proves nothing by itself. Every chain here is judged from its own block timestamps and from what its sequencer posted to Ethereum.

Observed networks

Chains

Status is decided from the chain's own block timestamps and from what the sequencer posted to Ethereum, never from an explorer alone. The evidence column says which on-chain signals apply to that stack.

ChainStatusHead ageBlock rateGasLast L1 batchLast assertionTx testOperator saysEndpointsIncidents 24hEvidence
Status history

Last 90 days

One cell per UTC day from the monitor's own evaluations, every 5 seconds: green when every signal was normal all day, yellow if any time was degraded, red if an incident was open. Grey means the monitor was not watching, and is shown as exactly that rather than as green.

healthydegradedincidentnot observed
Badges

Put a live status badge in your docs

Each badge is a static SVG rebuilt every 5 seconds from chain evidence: green producing blocks, yellow degraded, red incident, grey when the monitor itself is stale. One line of Markdown for a README; the chain page has iframe and API snippets.

Reading the table

How to read this

A frozen block number on an explorer proves nothing by itself. Every chain here has one sequencer. It produces blocks, pushes them to RPC nodes and indexers over a feed, and posts data to Ethereum. Any of the three can stall on its own, and they look identical from a screenshot.

Chain halt: the sequencer stops. The next block carries a timestamp that jumps by the length of the outage, permanently. Posts to L1 stop too.

Read-path stall: the sequencer keeps going, but a public RPC or the explorer falls behind. Users see a stuck head; timestamps stay continuous and L1 evidence keeps arriving.

Batch delay: blocks keep coming but nothing reaches Ethereum. State is soft until it lands.

Operator says: the chain operator's own status page, read from its API. When it says operational while the chain data shows an incident, the row says so. When it says operational and the chain data agrees but the public RPC was down for 14 minutes, that's the gap this site exists for.

Tx test: where a chain has a funded test address, a self-transfer goes out every few minutes and is followed to inclusion and to Ethereum. The one signal here that uses the chain the way a user does.

Gas: the base fee against the chain's configured floor, and why it sits there. The gas panel shows the pricing constraints doing the work.

Proof, per stack

Evidence by stack

Arbitrum Nitro (Arbitrum One, Robinhood Chain, any Orbit chain): SequencerBatchDelivered events on the SequencerInbox prove batching; events on the Rollup contract prove assertions; the UpgradeExecutor is watched for config changes.

OP Stack (Base, any Superchain member): transactions from the batcher to the BatchInbox address prove batching (there is no event, so the monitor reads full L1 blocks); DisputeGameCreated on the DisputeGameFactory proves output roots; the SystemConfig is watched for changes.

Different stacks, different proofs. The table never pretends they're measured the same way.

API

Use the data

Every chain page has badge, iframe, and API snippets. All chains in one call:


  

Sherwood Pulse is independent and reads the chains and Ethereum directly. Updates and incident notices: @sherwoodpulse on X.