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 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 . | Users wait up to the window for inclusion. |
| 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 falls below its hard threshold.
- Execution fails. For example, block creation panics on every attempt.
Unless a standby sequencer takes over, a crashed host or cloud outage can also stop a sequencer. 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 is turned off | sequencer temporarily not available |
| The sequencer is running but cannot build blocks | An error after the transaction waits for 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 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 reverts 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.
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 changes. See When a force inclusion reorders the chain.
- Old messages reach the past 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. 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.
Set the buffer and its threshold above your chain's batch posting interval so the feature works as intended. See How the Censorship Timeout shortens the window.
When the parent chain's sequencer is down
If your chain is a Layer 3 (), 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?