Respond to a sequencer outage
Follow these steps when your Arbitrum chain stops producing blocks or stops posting batches. Each step links to the page that holds the fix.
Use this page when your stops producing blocks or stops posting batches to the . Work through the steps in order. Each step links to the page that holds the fix. For background on what happens during an outage, see Sequencer outages.
1. Find out which outage you have
Check two things: whether blocks are still being produced, and whether batches are still landing on the parent chain.
| What you see | Outage | Next step |
|---|---|---|
| The block height is the same across two samples. | Sequencer downtime | 2. Restore block production |
Blocks keep coming, but arb/inbox/latest/batch stops rising, or no SequencerBatchDelivered event arrives on schedule. | Batch posting outage | 3. Restore batch posting |
For the metrics and alert thresholds, see the Sequencer and Batch poster sections of the monitoring guide.
Write down the time the outage started. You need it in step 4.
2. Restore block production
- Work through the diagnostic order. Sequencer troubleshooting lists the checks and the fix for each error message.
- If you run the sequencer coordinator, confirm that a sequencer holds the lockout. Read
coordinator.chosenin Redis. If you setchosen-healthcheck-addr, you can query that endpoint instead. It returns200on the chosen sequencer and503on the others. If no sequencer is chosen, see No sequencer is chosen. - If the sequencer logs
cannot sequence, check the parent-chain connection first, then the host clock. See The sequencer refuses to build a block.
3. Restore batch posting
- Check the batch poster balance. If
arb/batchposter/wallet/ethis below your funding threshold, fund the account. - Check for a reverted batch. If the batch poster logs
batch was reverted, not posting any more batches, find the cause of the revert, then restart the batch poster. See Recovery mechanism 2. - If the batch poster key is lost or compromised, rotate it. See Batch poster key rotation.
- If you run a standby batch poster, confirm that it took the lock. The lock works only when you set
node.batch-poster.redis-url. It expires 1 minute after the active batch poster stops. See Redis failover. - If someone force-included a message during the outage, the first batch can fail. A force inclusion does not update the message count the batch poster expects. If the first batch fails, set
dangerous.allow-posting-first-batch-when-sequencer-message-count-mismatchfor the first batch. See Recovery mechanism 2.
For other causes, see Batch poster troubleshooting.
4. Tell your users
Tell your users what is down and how they can still reach the chain:
- Which job stopped. Say whether the chain has stopped producing blocks or has stopped posting batches.
- How to send a transaction anyway. Point users to Forced transactions. They can now send a transaction through the .
- When force inclusion opens. A message sent to the Delayed Inbox can be force-included one force-inclusion window after the parent-chain block it landed in. To get the exact block, call
forceInclusionDeadline(blockNumber)on the Sequencer Inbox with that block number. The result accounts for the Censorship Timeout. Give your users the window in hours, and the deadline block if you have it. See Settings you control. - How to withdraw ETH. Point users to Withdraw ETH while the sequencer is down.
- During a batch-posting outage, recent transactions can change; a force inclusion can drop transactions. Tell users which transactions might need to be resent.
5. After recovery
- Confirm that blocks and batches are flowing. Watch
arb/batchposter/estimated_batch_backlogandarb/feed/backlog/messagesdrain back to normal. - Check for a reorg. If someone force-included a message while blocks were unposted, nodes that follow the feed dropped those blocks. The sequencer re-sequences up to 1,024 dropped messages, and only while it is active. See When a force inclusion reorders the chain.
- Check the Censorship Timeout buffer if you enabled it. A long outage drains the buffer, so the force-inclusion window stays shorter until it refills. The buffer refills about 1 day for every 20 days without long delays. See How the Censorship Timeout shortens the window.
- Review your setup. Decide whether you need a standby sequencer, a standby batch poster, new alerts, or a different force-inclusion window. See Sequencer outages.
How is this guide?
Post-launch deployments
Learn about deploying contracts like Multicall3 to an Arbitrum chain after launch using sendL2Message, without needing a chain upgrade or predeploy.
Sequencer troubleshooting
Diagnose and resolve sequencer feed problems, broadcast backlog errors, feed stalls, and the conditions that stop block production.