Arbitrum docsSequencer outages
Learn what happens to your Arbitrum chain when the sequencer or batch poster stops, and which settings control how long your users wait.
A sequencer outage is any period when your stops ordering or posting transactions to the . Your users can still send a transaction through the on the parent chain unless you pause the Inbox or enable its allowlist. They wait longer for inclusion, though, and some confirmed transactions can be reordered or dropped. This page explains the two kinds of outage, what your users see during each one, and which settings you control.
See Respond to a sequencer outage for an ordered checklist.
Two kinds of outage
An outage stops one of two jobs. The orders transactions into blocks. The posts those blocks to the on the parent chain. Each job can fail without the other.
| Outage | What stops | What keeps working | Main risk |
|---|---|---|---|
| Sequencer downtime | Block production | The Delayed Inbox accepts messages. Nodes serve the existing chain state. | Users wait up to the window for inclusion. |
| Batch posting outage | Posting blocks to the parent chain | The sequencer produces blocks, and users get . | Blocks that never reach the parent chain can be reorganized. |
A batch posting outage does not stop the sequencer. As Sequencer troubleshooting puts it for an unfunded batch poster: "Posting stops; sequencing does not."
Sequencer downtime
What causes it
Block production stops for one of four reasons:
- No sequencer holds the lockout. When you run several sequencers with a coordinator, exactly one must hold the lockout in Redis. If none does, the chain stops.
- The sequencer refuses to build a block. The most common cause is a down or lagging parent-chain connection, or a local clock that has drifted.
- The sequencer rejects every transaction. For example, the expected surplus fell below its hard threshold.
- Execution fails. For example, block creation panics on every attempt.
A crashed host or cloud outage can also stop a sequencer unless a standby sequencer takes over. For each error message and its fix, see Block production halt conditions.
What your users see
- The chain stops producing blocks. The block height stays the same.
- Remote procedure call (RPC) nodes cannot forward new transactions. The error a user gets depends on where the transaction stops:
| Where the transaction stops | What the node returns |
|---|---|
| A node forwards it, but no forwarding target answers | failed to publish transaction to any of the forwarding targets |
| A node has no forwarding target, or its forwarder is turned off | sequencer temporarily not available |
| The sequencer is running but cannot build blocks | An error after the transaction waits queue-timeout (12 seconds by default) |
How your users get a transaction in
Your users send their transaction through the Delayed Inbox on the parent chain instead of to the sequencer. What happens next depends on how long the outage lasts:
| How long the outage lasts | What happens to the message |
|---|---|
| Less than the force-inclusion window | It waits in the Delayed Inbox. When the sequencer returns, it adds the message in the order it arrived. Nobody can force-include it. |
| Longer than the force-inclusion window | Anyone can call forceInclusion on the Sequencer Inbox. The message enters the chain without the sequencer. |
The sequencer cannot skip or reorder Delayed Inbox messages. For the user steps, see Forced transactions. Users can also withdraw ETH while the sequencer is down.
Batch posting outage
During a batch posting outage, your chain looks healthy. The sequencer keeps producing blocks, and users keep getting soft confirmations through the . Those blocks exist only on your nodes, though. Nothing about them is on the parent chain yet.
Common causes are an unfunded batch poster account, a batch that reverted on the parent chain, and a lost or compromised batch poster key. When a batch reverts, the batch poster stops posting on purpose until you investigate and restart it. For the causes and fixes, see Batch poster troubleshooting and Batch poster recovery.
The longer a batch posting outage lasts, the more it puts at risk:
- A force inclusion reorganizes the chain. If the outage outlasts the force-inclusion window, anyone can force-include a Delayed Inbox message. Every node that follows the feed then drops the blocks it never saw on the parent chain. This is a .
- Some dropped transactions are lost for good. Only an active sequencer re-sequences dropped messages. It re-sequences up to 1,024 messages by default and skips any it fails to add. Some re-sequenced transactions revert because the chain state changed. See When a force inclusion reorders the chain.
- Old messages reach the past edge of
maxTimeVariation. The batch poster stops posting when a batch's oldest message comes withinreorg-resistance-margin(10 minutes by default) of the oldest time the Sequencer Inbox allows. See Relationship with the batch poster. - The first batch after a force inclusion can fail. A force inclusion changes the message count the batch poster expects. Batch poster recovery explains the flag that lets the first batch through.
Settings you control
You choose how long your users wait and how much time you have to fix an outage. These settings shape both.
| Setting | What it changes | Default | How to change it |
|---|---|---|---|
delayBlocks in maxTimeVariation | The force-inclusion window: how many parent-chain blocks a Delayed Inbox message waits before anyone can force-include it. | 4 days of parent-chain blocks, when the Chain SDK recognizes your parent chain | Call setMaxTimeVariation on the Sequencer Inbox. See Changing maxTimeVariation. |
Censorship Timeout (bufferConfig) | Shortens the window after long delays, so repeated or long outages cost users less wait time. | Inert. The Chain SDK sets threshold and max to 2³² blocks, so the buffer never shortens the window. | Set bufferConfig at deployment, or call setBufferConfig later. setBufferConfig works only if the Sequencer Inbox was deployed with a nonzero threshold. Otherwise it reverts with NotDelayBufferable. See Ownership and access. |
| Sequencer coordinator | Lets a standby sequencer take over when the active one fails. | Off | See How to set up a high-availability sequencer. |
| Batch poster Redis lock | Lets a standby batch poster take over. The lock expires after LockoutDuration (1 minute by default). | Off until you set node.batch-poster.redis-url | See Redis failover. |
Choose a force-inclusion window
The window trades your recovery time against your users' wait:
- A longer window gives you more time to fix an outage before anyone can force-include a message. Your users wait longer to get a transaction in, and the chain's censorship resistance weakens.
- A shorter window lets your users get transactions in sooner. A shorter batch posting outage is then enough for a force inclusion to reorganize the chain.
The Censorship Timeout narrows the gap between the two. The first force-included message in an outage still waits the full delayBlocks. Later messages in a long outage, and messages in repeated outages, wait less. Set the buffer and its threshold above your chain's batch posting interval, or the feature does not work as intended. See How the Censorship Timeout shortens the window.
When the parent chain's sequencer is down
If your chain is an , its parent chain has its own sequencer. When that sequencer stops, three things happen to your chain:
- Your batch poster cannot post, because the parent chain accepts no new transactions except through its own Delayed Inbox.
- Your force-inclusion window stops counting. The window counts parent-chain block numbers, which advance only while the parent chain produces blocks.
- Your sequencer can stop too. It stops building blocks once the newest parent-chain block is more than 1 hour older than its local clock (
execution.sequencer.max-acceptable-timestamp-delta).
See the callout under After the window ends.
Example timeline
This example assumes the Chain SDK defaults on a parent chain with 12-second blocks: a 4-day force-inclusion window and the Censorship Timeout at its inert default.
| Time | Event |
|---|---|
| Hour 0 | The sequencer stops. The chain stops producing blocks. |
| Hour 1 | A user sends a transaction to the Delayed Inbox. It waits. |
| Hour 6 | The sequencer returns. It adds the user's message in order. Nobody needed to force-include it. |
| Hour 1 + 4 days | If the sequencer had stayed down, anyone could now call forceInclusion and include the user's message. |
Related pages
How is this guide?