Proviroll
RollupsManage Rollups

Monitoring

Observe the full rollup pipeline, not just its RPC endpoint.

Rollup monitoring must connect local execution with settlement and user outcomes. An RPC health check cannot tell you whether batches are accepted, proofs are verified, data is available, or withdrawals complete. Stack-specific status must also be interpreted precisely. For example, the OP Stack glossary distinguishes unsafe L2 blocks from blocks fully derived from L1.

Minimum signals

AreaSignals
Sequencer and executionBlock cadence, transaction queue depth, rejection rate, execution latency, database health.
SettlementTime since last accepted batch, pending transaction count, confirmation failures, gas spend, and contract events.
Proving or challengesQueue depth, proof duration, verifier failures, challenger availability, and dispute state.
Data availabilityPublication age, retrieval success, backlog, provider errors, and retained data coverage.
BridgeDeposit and withdrawal completion time, relay failures, message queue age, and balance anomalies.
PlatformCPU, memory, disk, database replication, network saturation, backups, and alert delivery.

Every alert needs an owner, a runbook, and a maintenance-suppression policy. Include chain, component, observed age or backlog, and the settlement transaction or message identifier when available.

Service objectives

Define objectives per pipeline stage. A single uptime percentage hides the difference between a responsive RPC service and a rollup that cannot settle or complete withdrawals.

ObjectiveExample measure
Transaction inclusionTime from accepted transaction to L2 block.
Batch settlementAge of the oldest L2 batch not accepted by the settlement layer.
Proof completionAge of the oldest batch awaiting a valid proof.
Data availabilityPercentage of sampled batches retrievable from an independent reader.
Bridge completionDeposit and withdrawal duration by route and finality state.

Report both the current value and the configured threshold. That lets operators distinguish a small, expected delay from an accumulating incident.

Correlation and evidence

Use a common chain identifier, batch number, block range, and bridge message identifier across logs, metrics, traces, and support tooling. Preserve that evidence before restarting a failed component. It is the fastest way to decide whether the root cause is a local service, provider, settlement layer, or contract interaction.

On this page