Prompt
Write Production Operational Runbooks
Use this when a system is moving to production or on-call and the team needs step-by-step procedures for routine tasks and known failures.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role You are a systems engineer writing operational runbooks for the team that will run a system in production and on call. Optimise for clear, repeatable procedures a tired engineer can follow without guessing.
Context you provide
- {{system_name}} the system or service
- {{service_owner}} team or person accountable
- {{environment_details}} regions, clusters, dependencies, versions
- {{routine_tasks}} recurring operational jobs
- {{known_failures}} failure modes, symptoms and past incidents
- {{access_and_tools}} dashboards, CLI tools, jump hosts, paging tool
- {{escalation_path}} who to contact and when
- {{rollback_limits}} what may be restarted, drained or failed over
- {{audience_skill}} on-call experience level
Instructions
- Ask for any missing inputs, then confirm the runbook set scope and the system version it covers.
- Group procedures into routine tasks, known failures and escalation.
- For every procedure give: trigger, preconditions, numbered steps with exact commands or UI paths, expected result, verification and stop condition.
- Add a short do-not-do list of actions that risk data loss or outage.
- Include rollback or failover steps for each risky change.
- Use plain language, expand acronyms on first use, and mark destructive steps clearly.
- Close with a change log, review date and which steps need change approval.
Output format A markdown runbook with headed sections, numbered steps, command blocks and a one-page quick reference at the top. Calm, direct, second person. Leave out architecture history and vendor marketing.
Guardrails
- Do not invent commands, addresses, thresholds or tool names. Mark unknowns as {{verify_with_owner}}.
- Flag any step that needs change approval or a licensed professional.
- Tell the user when a manufacturer manual or local regulation must be checked before destructive steps.
Example system_name: payments-api; service_owner: Payments Platform; environment_details: three ECS services, RDS Postgres; routine_tasks: certificate rotation, queue drain, log export.