Postmortem Response-Toil & Automation-Candidate Finder Prompt
Scan an incident timeline for the manual, repetitive, and error-prone steps the responders had to perform by hand — and turn them into concrete automation, runbook, or tooling candidates for the action-item list.
- Target user
- SRE / on-call engineer converting incident response friction into reliability work
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior SRE who reads incident timelines looking for one specific thing: the manual toil the responders had to do because tooling did not exist. You know that the minutes lost to hand-run commands, copy-pasted queries, ad-hoc dashboards, and "someone had to SSH in and check" are where mean-time-to-recovery quietly leaks — and where the highest-leverage action items hide. I will paste the incident timeline and response log below. [INCIDENT TIMELINE / CHAT LOG / RESPONSE NOTES] [EXISTING RUNBOOKS OR AUTOMATION, if any] Do the following: 1. **Toil inventory**: extract every manual step a responder performed — commands run by hand, data gathered manually, decisions that required tribal knowledge, coordination done ad hoc. Quote the timeline evidence for each. 2. **Classify each step** by whether it was: (a) diagnosis toil (finding out what was wrong), (b) mitigation toil (applying the fix by hand), or (c) coordination toil (paging, escalating, communicating). Note the approximate time cost where the timeline shows it. 3. **Automation candidates**: for each toil item, propose the most fitting remedy — a runbook, a one-click automation, a dashboard or query saved for reuse, an alert enrichment, a self-healing mechanism, or a guardrail. Be specific about what it would do and when it would trigger. 4. **Prioritize** candidates by (time saved during an incident) x (likelihood of recurrence) x (safety of automating it). Flag any step that should stay human-in-the-loop and explain why automating it would be risky. 5. **Anti-candidates**: call out steps that look automatable but should not be — one-off actions, judgment calls, or destructive operations that need a human decision. Output format: a table [Manual step | Toil type | Evidence quote | Proposed automation | Trigger | Priority], followed by a short "keep human-in-the-loop" list with reasons. Guardrails: describe what responders did, not whether they did it well — this is a blameless search for missing tooling, not a critique of the people who worked the incident. Do not propose automating destructive or irreversible actions without an explicit human gate. Mark any step whose details you are unsure of as [UNVERIFIED].
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Recovery time is dominated by the manual work no one built tooling for: the engineer who SSHes in to read a log, the query someone reconstructs from memory, the dashboard assembled on the fly while the site is down, the escalation done by hand because there is no runbook. These moments are visible in every incident timeline, but the postmortem usually skips past them to the root cause — and the action items miss the cheapest, highest-frequency wins.
This prompt reads the timeline specifically for toil and classifies it into diagnosis, mitigation, and coordination, because each type maps to a different remedy. Diagnosis toil wants saved queries, dashboards, and alert enrichment; mitigation toil wants runbooks and one-click automations; coordination toil wants better paging and escalation policies. Naming the type turns a vague “we should automate this” into a specific, buildable candidate with a defined trigger.
The prioritization and anti-candidate steps are what make it safe and useful. Weighting by time-saved times recurrence-likelihood keeps the team from automating a one-off, and the explicit keep-human-in-the-loop list guards against the classic failure mode of automating a destructive action that should always require a human decision. Framed as a blameless hunt for missing tooling — not a critique of how fast anyone moved — it converts the friction of the response into a ranked, defensible slice of the reliability backlog.
Related prompts
-
Postmortem Action Item Recurrence-Risk Prioritizer Prompt
Rank a postmortem's action items by how much each reduces the chance and cost of the incident recurring, so an overloaded team ships the few fixes that actually move reliability instead of a long undifferentiated list.
-
Postmortem Action-Item SMART Rewriter Prompt
Rewrite vague postmortem action items ('improve monitoring', 'be more careful') into specific, owned, time-bound tasks that can actually be tracked to completion.
-
Postmortem Findings to Engineering Tickets Prompt
Convert postmortem findings into well-scoped engineering tickets — each with a clear title, candidate owner role, acceptance criteria, defense type, and a realistic due date — so the lessons turn into tracked work instead of a buried action-items list.
-
Postmortem Assumptions and Unknowns Extractor Prompt
Read a postmortem draft and surface every unstated assumption and open unknown that is being treated as settled fact, so the root-cause analysis and action items don't quietly rest on unverified claims.
More Post Mortems with AI prompts & error guides
Browse every Post Mortems with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.