On-call shifts used to eat my evenings. The worst part wasn't the 2 AM page — it was writing up the incident afterward, updating the runbook, and explaining what happened to leadership in a way that didn't sound like panic.
Over the last year I built a small library of AI prompts specifically for DevOps and SRE work. These aren't "write me a status update" filler. Each one solves a concrete operational problem: turning a messy incident timeline into a postmortem, generating a runbook from a Slack thread, writing an on-call handoff that the next person can actually follow.
Here are 10 prompts I use regularly, with the structure behind each one and a real example output so you can see what good looks like.
The structure I use for every prompt
Every prompt below follows four parts:
- Role — who the AI is pretending to be
- Context — the situation and constraints
- Constraints — the rules it cannot break
- Output — the exact format
Skip any part and the output drifts into generic noise. I learned this the hard way.
1. Incident timeline → structured timeline
You are an SRE writing an incident timeline for a postmortem.
Here is a raw timeline from Slack, dashboards, and pager messages, pasted out of order: [PASTE].
Produce a clean chronological timeline. Each entry: timestamp (UTC), event, source (which tool/person), and severity (info/warning/critical). Merge duplicate events. Flag any gap longer than 5 minutes as "[GAP — investigate]". Do not invent events that aren't in the source.
Why it works: SREs paste timelines out of order because that's how you reconstruct them. This prompt forces the AI to deduplicate, normalize timestamps, and explicitly flag gaps — the gaps are usually where the real story is.
2. Blameless postmortem draft
You are an SRE writing a blameless postmortem.
Incident: [SHORT DESCRIPTION]. Timeline: [PASTE]. Root cause (if known): [DESCRIBE].
Write a postmortem with these sections: Summary (3 sentences), Impact (duration, affected users, revenue if known), Timeline, Root Cause, Contributing Factors, What Went Well, What Went Wrong, Action Items.
Rules: every Action Item must have an owner, a due date, and a priority (P0/P1/P2). Never attribute fault to a person — always to a system, process, or missing safeguard. Ban the phrase "human error" — replace it with the specific missing safeguard that would have prevented it. If root cause is unknown, write "Under investigation" rather than guessing.
Why it works: The "ban human error" constraint is the single most important line. It forces the AI to surface the actual safeguard gap (no alert, no runbook step, no rate limit) instead of blaming the on-call engineer.
3. Runbook from a Slack thread
You are an SRE writing a runbook from a loose Slack thread where engineers debugged an issue.
Thread: [PASTE].
Produce a numbered runbook. Each step must be completable in under 5 minutes. Start each step with an action verb (Check, Restart, Verify, Roll back, Scale). Add a "What NOT to do" section preserving the wrong turns from the thread — those are the real lessons. Add a "Prerequisites" section (access, tools, permissions needed).
Why it works: The wrong turns are more valuable than the right steps. Most AI-generated runbooks delete them. This prompt forces them to survive as a "What NOT to do" section, which is where the next on-call engineer actually learns.
4. On-call handoff document
You are an SRE writing an on-call handoff for the engineer taking over the rotation.
Here are my open issues, in-progress mitigations, and watch items: [PASTE].
Write a handoff with three sections: (1) Active Incidents — status, current mitigation, next check-in time; (2) Watch Items — things that aren't incidents yet but could escalate, with the threshold that would make them one; (3) Heads Up — anything weird from my shift the next person should know. Keep it under 200 words. The first line must be either "Nothing active — quiet shift" or "X active incidents" so the next person knows the severity in one second.
Why it works: The forced first line ("Nothing active" vs "X active incidents") means the incoming on-call engineer knows the stakes before reading anything else. Most handoffs bury the lead.
5. Capacity planning memo
You are an SRE writing a capacity planning memo for leadership.
Service: [NAME]. Current: [QPS/CPU/MEM/DISK]. Growth rate: [% per month]. Headroom threshold: [%]. Budget: [$ or "not specified"].
Project when we hit the headroom threshold (show the math). Recommend 3 options ranked by cost: (1) cheapest short-term, (2) balanced, (3) long-term architectural change. For each: cost estimate, time to implement, risk, and what breaks if we do nothing. No jargon in the executive summary — assume the reader has never heard of this service.
Why it works: The "show the math" constraint kills the AI's tendency to hand-wave. The three ranked options force a real decision instead of "we should monitor the situation."
6. Alert deduplication review
You are an SRE reviewing alert fatigue. Here is a list of all alerts fired in the last 7 days with frequency: [PASTE].
Group alerts that likely have the same root cause. For each group: list the alerts, estimate how many pages they caused, and recommend ONE of: keep as-is, make multi-alert (group by 15 min), make info-only, or delete entirely. Prioritize reducing pages without losing signal. Flag any alert that fired more than 10 times as a candidate for a runbook or auto-remediation.
Why it works: Alert fatigue is the #1 quality-of-life issue for on-call engineers. This prompt treats alerts as a clustering problem and forces a concrete recommendation per group, not a vague "consider tuning."
7. Change failure summary for the changelog
You are an SRE summarizing a failed deployment for the public changelog and internal retro.
Deployment: [DESCRIBE]. What happened: [PASTE]. Rollback: [YES/NO, HOW].
Write two versions: (1) External — 2 sentences, customer-facing, no internal service names, states the impact and the fix. (2) Internal — the same story with the actual service names, the rollback mechanism, and one process change that would catch this next time. Both versions must be honest about the impact — do not minimize.
Why it works: Writing the external version forces honesty without exposing internals; the internal version forces a process change. The "do not minimize" constraint prevents the corporate reflex to downplay.
8. Health check → alerting rule
You are an SRE turning a manual health check into an automated alerting rule.
Manual check: [DESCRIBE what you do — e.g. "I curl /health and check the db_latency field is under 100ms"].
Generate a Prometheus-style alerting rule (or [OTHER SYSTEM]). Specify: metric name, threshold, for-duration, severity, and the runbook link to attach. Explain the threshold choice in one sentence. Suggest one related alert that would catch the failure mode this one misses.
Why it works: The "suggest one related alert that catches the failure mode this misses" line is gold — it forces the AI to think about what a single alert can't see.
9. Disaster recovery walkthrough script
You are an SRE writing a DR (disaster recovery) test walkthrough for the team to run quarterly.
Service: [NAME]. RTO: [X min]. RPO: [Y min]. Backup mechanism: [DESCRIBE].
Write a step-by-step DR test script. Each step: action, expected result, and what to do if the result differs (roll back? escalate?). Include a "Time check" after every step — if we're past the RTO, stop and document where we are. End with a pass/fail criteria section that's binary, not subjective.
Why it works: DR tests fail silently when the criteria are vague ("it basically worked"). Binary pass/fail and time-check-per-step make the test honest. The "stop if past RTO" rule prevents the common failure of running past the recovery objective and pretending it passed.
10. Cost anomaly investigation starter
You are an SRE investigating a cloud cost spike.
Bill summary: [PASTE — service, amount, period]. Normal baseline: [$].
List the 5 most likely causes of a spike of this size, ranked by probability for [AWS/GCP/Azure]. For each: how to confirm it (the exact metric or report to check), and how to fix it. Do not list generic advice — every item must be verifiable in under 10 minutes.
Why it works: Cost spikes are urgent and the AI's default is generic "check for unused resources." The "verifiable in under 10 minutes" constraint forces specific, checkable causes.
How I test these prompts
Before I trust a prompt in production, I run it 3 times on the same input. If the output structure stays consistent but the wording varies naturally, the prompt is stable. If the structure changes, the constraints are too loose — I tighten the Output section.
I also read every output aloud. If it sounds like it could have been written for any company, it's too generic and I add company-specific context.
These prompts are part of a larger set I use across engineering, operations, and product work. If you want the full operations-focused collection (50+ prompts covering incidents, capacity, on-call, deployments, and team workflows), I keep them here: AI Startup Operations Prompt System. For a lighter starting point, the $9 launch-day prompt pack covers the essentials.
What DevOps or SRE prompts have saved your shift? I'm always looking to add to the library.
Top comments (0)