Software Operator Runbook Checklist

An operator runbook should help a trained person make a safe decision during a routine failure or operational task. It should be specific enough to use under pressure while explaining when to stop, escalate, or avoid an action that could make the incident worse.

Start with the trigger and impact

State what starts the runbook, affected capability, customer impact, severity, owner, and prerequisites. Link to current dashboards, status, tickets, dependencies, and communication channels without embedding brittle screenshots.

Describe symptoms and safe checks

List observable symptoms, likely categories, read-only diagnostics, recent changes, and expected healthy values. Separate facts from hypotheses and prohibit commands that expose secrets or customer data.

Make permissions explicit

Identify who may view, pause, replay, scale, change configuration, revoke access, or communicate externally. Use least privilege and a temporary elevation path for actions that should not be available to every operator.

Give recovery steps and stop conditions

Order actions, expected result, rollback, time limit, and stop or escalate condition. Include a safe no-change path when the cause is uncertain. The retry policy checklist helps for queued work and repeat attempts.

Include communication and evidence

State when to update support, customers, leadership, or a provider. Record timeline, action, actor, result, correlation ID, and remaining risk without copying sensitive payloads into a broad incident channel.

Use the provider status checklist for dependency incidents and the incident drill checklist to practice the runbook before a real outage.

Test after changes

Walk through the runbook in a safe environment, test expired credentials, missing data, provider outage, partial recovery, rollback, and multiple operators. Record the last test, reviewer, result, and corrections.

Keep the runbook current

Assign an owner and review trigger for releases, provider changes, incidents, permissions, and architecture changes. Measure time to diagnosis, recovery, escalation, repeat incidents, and steps that operators skipped or misunderstood.