Skip to main content
This page provides step-by-step response procedures for the most critical validator incidents. Bookmark it and review it before you need it.

Severity levels


P0: Node not signing blocks

Detect:
Response:
  1. Check if the service is running: sudo systemctl status autheod
  2. If stopped, restart: sudo systemctl start autheod
  3. Check logs: sudo journalctl -u autheod -n 200 --no-pager
  4. Check sync status: autheod status | jq '.SyncInfo'
  5. If out of sync, restore from snapshot (see Backups and restore)

P0: Validator tombstoned

Detect:
Returns tombstoned: true if tombstoned. Response: Tombstoning is permanent — it results from double-signing and cannot be undone.
  1. Stop the tombstoned node immediately
  2. Do not attempt unjail — it will fail
  3. Commission a new server
  4. Generate a new consensus key: autheod init new-validator --chain-id autheo_2127-1
  5. Register a new validator with MsgCreateValidator and a new consensus key
  6. Bind your Sovereign license to the new validator address

P1: Validator jailed (liveness)

Detect:
Response:
1

Diagnose the cause

Check why blocks were missed — look for crashes, restarts, or network interruptions in the logs:
2

Fix the root cause

Resolve the underlying issue before unjailing: disk full, OOM, misconfiguration, etc.
3

Ensure node is synced

4

Verify license is not REVOKED

5

Submit unjail

6

Re-delegate if needed

If the license shows BOUND after unjailing:

P1: Node not syncing (catching_up: true)

Detect:
Response:
  1. Check peer count: curl -s localhost:26657/net_info | jq '.result.n_peers'
  2. If peers < 3, add persistent peers in config/config.toml
  3. If syncing is extremely slow (hours behind), restore from snapshot:

P1: Hardware failure — migrate to new host

See Runbook B: Full hardware failure. The critical rule: confirm the old host is completely powered off before starting the new host with the same consensus key.

Post-incident review

After every P0 or P1 incident:
  1. Document the timeline (when detected, when resolved)
  2. Identify the root cause
  3. Update monitoring thresholds if the incident was not caught early enough
  4. Review the monitoring checklist
  5. Update runbooks if the incident revealed a gap