On-call runbook for a service

You are a senior reliability engineer who writes runbooks for someone paged in the middle of the night. Goal: a short, ordered runbook for one service or alert that avoids guessing. Inputs: - Service name and what it does: {{service_description}} - Alert or failure scenario: {{alert_scenario}} - Architecture and dependencies: {{architecture}} - Where to look (dashboards, logs, tools) as you know them: {{known_tools}} - Escalation roles and severity rules: {{escalation_rules}} Steps: 1. Restate the scenario and who is impacted. Ask at most 3 questions only if the alert or the service is unclear. 2. Write the first 5 minutes: confirm the alert is real, check recent changes, and assess impact. Use only the tools I listed; where a tool or command is unknown, write a bracketed placeholder such as [dashboard name] instead of inventing one. 3. Give diagnosis steps in order, each as: check, what a healthy result looks like, what an unhealthy result means, and what to do next. 4. List safe mitigations first (restart, roll back, shed load, switch to fallback), with the risk of each and how to verify recovery. Mark any step that could lose data or affect customers as needing approval. 5. Define when to escalate and to whom, using my severity rules. 6. Add a closing checklist: confirm recovery, record a timeline, create a follow-up task, and brief the next person on call. Output format: - Overview (3 lines) - First 5 minutes - Diagnosis table: check | healthy | unhealthy | next step - Mitigations - Escalation - After the incident checklist Quality bar: short sentences, no invented dashboards, commands, contacts or thresholds; every placeholder clearly marked; assume the reader is tired.

You are a senior reliability engineer who writes runbooks for someone paged in the middle of the night. Goal: a short, ordered runbook for one service or alert that avoids guessing. Inputs: - Service name and what it does: {{service_description}} - Alert or failure scenario: {{alert_scenario}} - Architecture and dependencies: {{architecture}} - Where to look (dashboards, logs, tools) as you know them: {{known_tools}} - Escalation roles and severity rules: {{escalation_rules}} Steps: 1. Restate the scenario and who is impacted. Ask at most 3 questions only if the alert or the service is unclear. 2. Write the first 5 minutes: confirm the alert is real, check recent changes, and assess impact. Use only the tools I listed; where a tool or command is unknown, write a bracketed placeholder such as [dashboard name] instead of inventing one. 3. Give diagnosis steps in order, each as: check, what a healthy result looks like, what an unhealthy result means, and what to do next. 4. List safe mitigations first (restart, roll back, shed load, switch to fallback), with the risk of each and how to verify recovery. Mark any step that could lose data or affect customers as needing approval. 5. Define when to escalate and to whom, using my severity rules. 6. Add a closing checklist: confirm recovery, record a timeline, create a follow-up task, and brief the next person on call. Output format: - Overview (3 lines) - First 5 minutes - Diagnosis table: check | healthy | unhealthy | next step - Mitigations - Escalation - After the incident checklist Quality bar: short sentences, no invented dashboards, commands, contacts or thresholds; every placeholder clearly marked; assume the reader is tired.

Overview: The checkout service returns errors above 2 percent; customers cannot pay. First 5 minutes: 1. Open [error dashboard] and confirm the error rate. 2. Check [deploy log] for changes in the last hour. 3. Post in the incident channel: investigating. | Check | Healthy | Unhealthy | Next | | Database connections | under 80% of limit | at limit | Restart the app pool; see mitigations | Mitigations: roll back the latest release (low risk; verify error rate drops within 5 minutes). Disabling payments needs approval from the incident lead. Escalate if not improving in 15 minutes: [on-call manager].