A production runbook records the steps needed to operate and recover the actual application. It should be specific enough that an authorised maintainer can use it during an incident.
IN THIS ARTICLE
What you need before you begin
Collect the current service architecture, release process and backup scope. Keep secret values in the credential system and reference their location rather than copying them into the document.
01 Document the production runtime and recovery procedure
Record the application version, supported runtimes, process names, document root and persistent storage locations. Include required external services and their owners.
Document startup, restart, deployment and routine scheduled work using the actual supported commands or panel controls.
Describe the most useful logs, health checks and failure signals, including where to find safe request or release identifiers.
Write recovery steps for code, database and uploaded files separately. State prerequisites, compatibility checks and the point where a destructive restore would replace newer data.
Rehearse the procedure in an isolated environment and update it after a material deployment or architecture change.
02 Example: a practical production runbook outline
Fill these fields with verified values from the actual deployment. Keep secret values in the approved credential system and record only their access reference.
| Runbook section | Required detail |
|---|---|
| Runtime | Approved PHP/Python/Node version, extensions, web process and worker identity. |
| Paths | Public document root, active release, persistent uploads and private configuration. |
| Routine operations | The tested start/reload control, scheduled jobs and authorized operator role. |
| Diagnosis | Private log location, safe release ID and the checks that reveal the common failure. |
| Recovery | Matching code/data backup, compatibility prerequisites, restore destination and verification workflow. |
Have another maintainer locate the current release and recover a harmless staging copy using only the runbook and their authorized access. Missing permissions are an actionable rehearsal finding.
Confirm the expected result
Ask an authorised maintainer to follow the runbook without relying on undocumented personal knowledge. Record unclear steps and missing permissions found in the rehearsal.
Troubleshoot unexpected results
A copied generic server checklist may name services or paths the account does not use. Replace those assumptions with verified details from the actual deployment.
A common question
Should the runbook include passwords so it is self-contained?
Reference a protected recovery or credential location and the role allowed to access it. Keeping operational instructions separate from secret values makes sharing and maintenance safer.