> Feedback: If these docs are stale, missing, or confusing, post sanitized feedback to `https://tempo.xyz/developers/api/feedback` with `source: "mcp"`, a short `message`, and any relevant `toolName`, `relatedResource`, or `client`.
> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://tempo.xyz/developers/api/mcp` to find what you need.
>
> **Have feedback?** Use `submit_feedback` on the same MCP server.

# Validator failover

This runbook covers a warm failover where a follower is promoted into a validator. A follower running in certified mode stores the same consensus finalization data used to bootstrap the validator.

:::danger[Prevent double-signing]
Only one node may run with a validator signing key at a time. Before promoting the follower, fence the old validator. Do not start the replacement while the old validator can still sign.
:::

## Prepare a follower

:::steps
### Run the follower

Use a dedicated data directory for the follower. Trustless RPC-to-RPC following is the default, and the upstream must be a validator or RPC node that exposes the `consensus` RPCs. If following a validator, the upstream validator must also expose WebSockets with `--ws`.

```bash
tempo node --datadir <datadir> \
  --chain <CHAIN> \
  --follow ws://example.url:8546 \
  --http --http.port 8545 \
  --http.api eth,net,web3,txpool,trace,consensus
```

Do not pass `--consensus.signing-key` while the standby is running as a follower. The standby is syncing certified consensus state, not participating in consensus.

### Verify the follower is current

Check that execution height is advancing and the certified consensus feed is available:

```bash
cast block-number --rpc-url http://localhost:8545
cast rpc consensus_getLatest --rpc-url http://localhost:8545
```

If `consensus_getLatest` is unavailable, the follower is not syncing consensus state. Confirm that the upstream endpoint is certified and exposes the `consensus` namespace.

### Keep validator networking ready

The promoted node must be reachable at the ingress and egress addresses registered onchain. A setup that allows a floating IP or load balancer address that can move from the old validator to the standby will require no onchain updates.

If failover uses a different address, update the validator's onchain IP configuration after fencing the old validator. Follow the [update IP addresses](/docs/guide/node/validator-lifecycle#update-ip-addresses) procedure.
:::

## Promote the follower

::::steps
### Fence the old validator

Stop the old validator or isolate it from the network before starting the replacement. If you use a floating IP, move it to the standby before validator startup.

```bash
sudo systemctl stop tempo
```

### Stop the follower process

Stop the standby follower cleanly so the same data directory can be reopened in validator mode.

```bash
sudo systemctl stop tempo-follower
```

If the follower is not managed by systemd, send `SIGINT` or `SIGTERM` and wait for the process to exit.

### Restart the standby in validator mode

Restart the same data directory without `--follow`, and add the validator signing key.

Use the same consensus signing key as the validator you are failing over from. This procedure moves an existing validator identity to the standby; it does not rotate the identity. To use a different signing key,
the validator's onchain configuration must be rotated. Follow the [rotate the validator identity](/docs/guide/node/validator-lifecycle#rotate-validator-identity) procedure.

:::code-group
```bash [Mainnet]
tempo node --datadir <datadir> \
  --chain mainnet \
  --consensus.signing-key <PRIVATE_KEY_PATH> \
  --consensus.listen-address 0.0.0.0:<REGISTERED_INGRESS_PORT> \
  --http --http.port 8545 \
  --http.api eth,net,web3,txpool,trace,consensus \
  --telemetry-url <TELEMETRY_URL>
```

```bash [Testnet]
tempo node --datadir <datadir> \
  --chain testnet \
  --consensus.signing-key <PRIVATE_KEY_PATH> \
  --consensus.listen-address 0.0.0.0:<REGISTERED_INGRESS_PORT> \
  --http --http.port 8545 \
  --http.api eth,net,web3,txpool,trace,consensus \
  --telemetry-url <TELEMETRY_URL>
```
:::

Do not delete or resync the data directory during failover. The follower's datadir contains the necessary consensus and execution state that allows the node to restart as a validator without a fresh bootstrap.

### Verify validator participation

Check that the node's consensus RPC is live and progressing, then verify the validator status from a public RPC endpoint:

```bash
cast rpc consensus_getLatest --rpc-url http://localhost:8545
```

:::code-group
```bash [Mainnet]
tempo consensus validator <pubkey> --rpc-url https://rpc.tempo.xyz
```

```bash [Testnet]
tempo consensus validator <pubkey> --rpc-url https://rpc.testnet.tempo.xyz
```
:::

The validator should remain `in_committee: true` if it was already active. If you changed IP addresses during failover, wait for the IP update to finalize and for peer discovery to pick up the new address.
::::

## After failover

Treat the promoted node as the active validator until you intentionally move the role again.

Use the [validator status metrics](/docs/guide/node/validator-status#checking-state-via-metrics) to confirm the promoted node is connected to peers and participating in consensus.