30 Claude Prompts for SRE

You are a site reliability engineering manager building an on-call schedule that spreads load fairly across a team. <context> My team has been running an ad hoc on-call schedule and two engineers have quietly carried most of the pages for the last quarter. </context> <inputs> - Team members: [ENGINEER NAMES] - Rotation length: [ONE WEEK OR TWO WEEK] - Time zones represented: [TIME ZONES] - Known unavailability: [VACATION OR LEAVE DATES] - Historical page count per person: [PAGE COUNTS] </inputs> <task> Propose a rotation schedule for the next quarter that balances page load, respects time zones, and works around known unavailability. </task> <constraints> No one should be on-call two rotations in a row unless the team is smaller than three people. Call out any engineer who is being assigned noticeably more shifts and explain why. </constraints> <format> Return a week by week table with columns Week, Primary, Secondary, and Notes. </format>

You are the outgoing on-call engineer writing a handoff note for the next person picking up the rotation. <context> My on-call shift for [SERVICE NAME] ends today and I want the next engineer to start with full context instead of digging through Slack history. </context> <inputs> - Incidents this shift: [INCIDENT SUMMARIES] - Alerts that fired but were not real incidents: [FALSE ALARM LIST] - Open follow-up items: [OPEN ITEMS] - Systems currently in a degraded but stable state: [DEGRADED SYSTEMS] - Anything scheduled during the next shift: [UPCOMING CHANGES] </inputs> <task> Write a handoff note that briefs the next on-call engineer on everything they need to know to start the shift confidently. </task> <constraints> Order items by urgency, most important first. Keep each item to two sentences or less. Do not omit degraded systems even if they seem minor. </constraints> <format> Return a message with sections Incidents, False Alarms, Open Follow-ups, Watch Items, and Upcoming Changes. </format>

You are an engineering manager proposing a fair on-call compensation policy to your leadership team. <context> Our engineers currently get no extra pay or time off for carrying a pager and morale around on-call has dropped. </context> <inputs> - Team size: [ENGINEER COUNT] - Average pages per rotation: [PAGES PER ROTATION] - Current company policy on overtime: [OVERTIME POLICY] - Budget constraints mentioned by leadership: [BUDGET NOTES] - Comparable policies at similar companies you know of: [BENCHMARK NOTES] </inputs> <task> Draft a compensation policy proposal that covers a stipend for carrying the pager and additional pay or time off for pages received outside working hours. </task> <constraints> Make the proposal realistic for the stated budget rather than aspirational. Anticipate at least one objection from finance and address it directly in the document. </constraints> <format> Return a one page proposal with sections Problem, Proposed Policy, Cost Estimate, and Anticipated Objections. </format>

You are a site reliability engineer setting up the escalation path for a service that just went into production. <context> We launched [SERVICE NAME] last week and there is no documented path for who gets paged if the primary on-call does not respond. </context> <inputs> - Service name: [SERVICE NAME] - Primary on-call team: [PRIMARY TEAM NAME] - Secondary team or manager: [SECONDARY CONTACT] - Response time expectation before escalation: [MINUTES BEFORE ESCALATION] - Dependencies owned by other teams: [DEPENDENCY TEAM NAMES] </inputs> <task> Define a three level escalation path with clear timing for when each level gets paged, and how to loop in owners of dependent systems. </task> <constraints> Escalation timing should be specific in minutes, not vague phrases like soon or shortly. Include what to do if a dependency team is unreachable. </constraints> <format> Return a numbered escalation ladder with Level, Who, Trigger, and Timing columns. </format>

You are a site reliability engineering manager planning on-call coverage around a holiday when most of the team is unavailable. <context> We have a long holiday coming up and only a handful of engineers on [ENGINEER TEAM NAME] are willing to carry the pager. </context> <inputs> - Holiday dates: [HOLIDAY DATE RANGE] - Engineers willing to work: [AVAILABLE ENGINEER NAMES] - Expected traffic change during the holiday: [TRAFFIC CHANGE ESTIMATE] - Planned deploy freeze dates if any: [FREEZE DATES] - Backup plan if no one is available: [FALLBACK CONTACT] </inputs> <task> Propose a coverage plan for the holiday period that minimizes burden on the willing engineers while keeping response times acceptable. </task> <constraints> Assume a deploy freeze unless stated otherwise, and note it if the inputs contradict that assumption. Keep any single engineer's holiday coverage to no more than three days unless there is truly no other option. </constraints> <format> Return a day by day coverage table plus a short paragraph on the fallback plan. </format>

You are a site reliability engineer writing the first draft of a blameless postmortem after a production incident. <context> We just resolved an incident on [SERVICE NAME] and I need a draft postmortem before the review meeting tomorrow. </context> <inputs> - Incident start and end time: [START TIME AND END TIME] - Customer impact: [IMPACT DESCRIPTION] - Timeline of events: [RAW TIMELINE NOTES] - Immediate trigger: [TRIGGER DESCRIPTION] - People involved: [RESPONDER NAMES] </inputs> <task> Write a blameless postmortem draft that documents the timeline, impact, root cause analysis, and proposed action items. </task> <constraints> Describe actions and system behavior, never blame a named individual for a mistake. Use neutral language like the deploy introduced rather than someone deployed carelessly. Keep the timeline in chronological order with timestamps. </constraints> <format> Return a document with sections Summary, Timeline, Impact, Root Cause, Contributing Factors, and Action Items. </format>

You are a site reliability engineer reviewing a raw incident timeline to pull out concrete follow-up work. <context> I have a messy chat log from the incident channel for [SERVICE NAME] and need actual action items out of it before the postmortem meeting. </context> <inputs> - Raw incident chat log: [PASTE CHAT LOG] - Systems affected: [AFFECTED SYSTEMS] - Time to detect: [DETECTION TIME] - Time to resolve: [RESOLUTION TIME] - Known gaps mentioned during the incident: [GAP NOTES] </inputs> <task> Extract a list of concrete, assignable action items from the timeline, each one addressing either detection, response, or prevention. </task> <constraints> Each action item must be specific enough to assign to one owner, not vague like improve monitoring. Group items under Detection, Response, and Prevention. Limit to no more than eight total items. </constraints> <format> Return a table with columns Action Item, Category, and Suggested Owner Role. </format>

You are a site reliability engineer preparing an executive summary of a completed postmortem. <context> The full postmortem for [SERVICE NAME] is long and technical, and I need a version an executive can read in two minutes. </context> <inputs> - Full postmortem document: [PASTE FULL POSTMORTEM] - Customer facing impact: [IMPACT DESCRIPTION] - Estimated cost or revenue impact: [COST ESTIMATE] - Status of key action items: [ACTION ITEM STATUS] - Audience: [EXECUTIVE NAMES OR TITLES] </inputs> <task> Write an executive summary that covers what happened, who was affected, what caused it, and what is being done to prevent recurrence. </task> <constraints> No more than one paragraph per section. Avoid engineering jargon such as p99 or connection pool without a plain explanation. Lead with impact, not technical detail. </constraints> <format> Return a summary with headers What Happened, Who Was Affected, Why It Happened, and What We Are Doing About It. </format>

You are a site reliability engineer doing a deeper root cause analysis that looks past the immediate trigger of an incident. <context> Our postmortem for [SERVICE NAME] identified a single trigger, but I suspect there were organizational or process factors that let it become an outage. </context> <inputs> - Immediate trigger: [TRIGGER DESCRIPTION] - How the trigger was caught: [DETECTION METHOD] - Time between trigger and customer impact: [TIME GAP] - Prior warning signs, if any: [PRIOR WARNING NOTES] - Recent changes to team, process, or tooling: [RECENT CHANGES] </inputs> <task> Identify contributing factors beyond the immediate trigger, such as missing test coverage, alerting gaps, unclear ownership, or process shortcuts, that allowed the incident to happen or escalate. </task> <constraints> Distinguish clearly between the trigger and contributing factors, do not conflate them. Support each contributing factor with a specific piece of evidence from the inputs, not speculation. </constraints> <format> Return a list of contributing factors, each with a one sentence explanation and the evidence it is based on. </format>

You are a site reliability engineering lead tracking whether past postmortem action items actually got done. <context> We have a backlog of postmortem action items from the last two quarters and I suspect several were never completed. </context> <inputs> - List of action items with dates: [ACTION ITEM LIST] - Current status of each, if known: [STATUS NOTES] - Team that owns each item: [OWNER TEAM NAMES] - Incidents that recurred since: [RECURRING INCIDENT NAMES] - Reporting deadline: [REPORT DUE DATE] </inputs> <task> Review the action item list and produce a status report that flags overdue items, especially any tied to an incident that has since recurred. </task> <constraints> Sort by risk, with items tied to a recurring incident at the top. Mark anything older than 90 days with no update as stale. Do not guess a status if it is not provided, mark it unknown instead. </constraints> <format> Return a table with columns Action Item, Owner Team, Status, Age in Days, and Risk Flag. </format>

You are a site reliability engineer auditing an alert that has been paging the team too often for issues that turn out not to be real. <context> The alert [ALERT NAME] on [SERVICE NAME] has fired [FIRE COUNT] times this month and only a handful were real incidents. </context> <inputs> - Alert name and query: [ALERT NAME AND QUERY] - Metric it monitors: [METRIC NAME] - Current threshold: [CURRENT THRESHOLD] - Sample of recent firings with outcome: [SAMPLE FIRINGS] - On-call feedback about it: [FEEDBACK NOTES] </inputs> <task> Analyze why this alert fires so often, identify the pattern behind the false positives, and recommend a specific fix such as a threshold change, a duration requirement, or a different metric entirely. </task> <constraints> Do not simply recommend raising the threshold without justifying it against the sample data. If the alert should be deleted rather than tuned, say so directly. </constraints> <format> Return sections Diagnosis, Recommended Fix, and Expected Reduction in Noise. </format>

You are a site reliability engineer setting a new alert threshold based on actual historical metric behavior rather than a guess. <context> Our current threshold for [ALERT NAME] on [SERVICE NAME] was picked arbitrarily and I want to base the new one on real data. </context> <inputs> - Metric name: [METRIC NAME] - Normal range over the last 90 days: [NORMAL RANGE VALUES] - Values observed during actual past incidents: [INCIDENT VALUES] - Seasonality pattern, if any: [SEASONALITY NOTES] - Desired alert lead time before customer impact: [LEAD TIME MINUTES] </inputs> <task> Propose a new threshold and duration window that would have caught the past incidents while staying above the normal range, accounting for the seasonality pattern described. </task> <constraints> Show the reasoning that connects the normal range and incident values to the chosen threshold. Flag if the normal range and incident values overlap too much for a clean threshold to work. </constraints> <format> Return a short analysis followed by a single recommended line: Threshold, Duration, Expected Lead Time. </format>

You are a site reliability engineer cleaning up an alerting system that has grown redundant rules across multiple teams. <context> We found that [SERVICE NAME] has multiple alerts that appear to monitor overlapping conditions, and I want to consolidate them without losing coverage. </context> <inputs> - List of existing alert names and conditions: [ALERT LIST] - Team that owns each alert: [OWNER TEAM NAMES] - Notification channel for each: [NOTIFICATION CHANNELS] - Known gaps in current coverage: [COVERAGE GAP NOTES] - Constraint on total alert count: [MAX ALERT COUNT] </inputs> <task> Identify which alerts overlap, propose a consolidated set that preserves detection coverage, and note any coverage gap that consolidation would introduce. </task> <constraints> Do not merge two alerts that serve genuinely different teams without flagging the ownership question explicitly. Stay within the stated max alert count if one is given. </constraints> <format> Return a table with columns Original Alerts, Consolidated Alert, Owner, and Coverage Note. </format>

You are a site reliability engineer improving alert descriptions so the linked runbook actually helps whoever is paged at 3am. <context> Our alert for [ALERT NAME] links to a runbook that is outdated and does not match what actually happens during this incident anymore. </context> <inputs> - Alert name: [ALERT NAME] - What the alert actually detects: [DETECTION DESCRIPTION] - Current outdated runbook content: [OLD RUNBOOK TEXT] - What responders actually do today: [CURRENT RESPONSE STEPS] - Tools available during response: [TOOL NAMES] </inputs> <task> Rewrite the runbook content linked from this alert so it matches current reality and gives a half asleep responder clear first steps. </task> <constraints> The first three steps must be things the responder can do in under two minutes each. Remove any step that references a tool or dashboard that no longer exists based on the inputs. </constraints> <format> Return the runbook as a numbered list starting with Immediate Checks, then Diagnosis, then Mitigation. </format>

You are a site reliability engineer triaging a backlog of low priority alerts that nobody has looked at in months. <context> We have a queue of [BACKLOG COUNT] alerts marked low priority for [SERVICE NAME] and I need to decide what to keep, fix, or delete. </context> <inputs> - List of alerts with last fire date: [ALERT LIST WITH DATES] - Whether each maps to a real SLI: [SLI MAPPING NOTES] - Team capacity available for cleanup: [ENGINEER HOURS AVAILABLE] - Any alerts tied to compliance requirements: [COMPLIANCE ALERT NAMES] - Deadline for this cleanup: [CLEANUP DEADLINE] </inputs> <task> Sort the backlog into three buckets, delete, tune, or keep as is, with a one line reason for each alert. </task> <constraints> Never recommend deleting an alert tied to a compliance requirement, even if it looks noisy. Respect the stated capacity when deciding how many alerts to recommend tuning this cycle. </constraints> <format> Return three lists under headers Delete, Tune, and Keep As Is, each entry with a one line reason. </format>

You are a site reliability engineer documenting a runbook for an incident type that recurs often enough to deserve a written procedure. <context> We keep seeing the same failure pattern on [SERVICE NAME], and every time a different engineer has to relearn the fix from scratch. </context> <inputs> - Incident type: [INCIDENT TYPE DESCRIPTION] - Symptoms an on-call engineer would see: [SYMPTOM LIST] - Diagnostic commands or dashboards used: [DIAGNOSTIC TOOLS] - Known fix steps: [FIX STEPS FROM MEMORY] - Rollback option if the fix fails: [ROLLBACK PROCEDURE] </inputs> <task> Write a runbook that lets any on-call engineer, not just the person who wrote it, diagnose and resolve this incident type. </task> <constraints> Assume the reader has general engineering skill but zero memory of this specific incident. Include exact commands where given, not paraphrases. Note when to give up on the fix and escalate instead. </constraints> <format> Return sections Symptoms, Diagnosis Steps, Fix Steps, Rollback, and When to Escalate. </format>

You are a site reliability engineer defining incident severity levels so the whole company uses the same language during an outage. <context> Right now everyone calls every incident critical, which makes it impossible to tell a real emergency from a minor blip. </context> <inputs> - Types of incidents we see: [INCIDENT TYPE EXAMPLES] - Customer segments affected in past incidents: [CUSTOMER SEGMENTS] - Current informal severity language used: [CURRENT INFORMAL TERMS] - Who should be notified at each level: [NOTIFICATION TARGETS] - Company size and structure: [COMPANY SIZE NOTES] </inputs> <task> Define four severity levels with objective criteria for classifying an incident, and who gets notified at each level. </task> <constraints> Criteria must be objective enough that two different engineers would classify the same incident the same way. Avoid subjective words like major or significant without a measurable definition attached. </constraints> <format> Return a table with columns Severity, Criteria, Response Time, and Who Is Notified. </format>

You are a site reliability engineer drafting the communication template used when an incident affects customers directly. <context> During our last outage on [SERVICE NAME], customer support had no template and messages went out inconsistent and late. </context> <inputs> - Service name: [SERVICE NAME] - Typical customer impact types: [IMPACT TYPE EXAMPLES] - Status page tool used: [STATUS PAGE TOOL NAME] - Legal or PR review requirements: [REVIEW REQUIREMENTS] - Update cadence expected during an active incident: [UPDATE FREQUENCY] </inputs> <task> Draft three message templates: an initial acknowledgement, a progress update, and a resolution notice, each with placeholders to fill in during a real incident. </task> <constraints> No speculation about root cause in the initial acknowledgement. Keep every template under 80 words. Match the tone to a company being transparent, not defensive. </constraints> <format> Return three labeled templates: Initial Acknowledgement, Progress Update, and Resolution Notice. </format>

You are a site reliability engineer building a decision tree that tells an on-call engineer exactly when to escalate a page instead of guessing. <context> Engineers on [TEAM NAME] often sit on an incident too long before escalating, or escalate too early for things they could have handled alone. </context> <inputs> - Team name: [TEAM NAME] - Common incident types: [INCIDENT TYPE LIST] - Time limit before mandatory escalation: [ESCALATION TIME LIMIT] - Secondary on-call and manager contacts: [SECONDARY CONTACTS] - Situations that should skip straight to manager: [SKIP TO MANAGER CASES] </inputs> <task> Build a decision tree with yes or no branches that an engineer can follow under pressure to decide whether and when to escalate. </task> <constraints> Every branch must end in a specific action, never a vague suggestion like use judgment. Keep the tree to five decision points or fewer so it fits on one screen. </constraints> <format> Return the decision tree as numbered steps with clear yes or no branches and the resulting action at each leaf. </format>

You are a site reliability engineer capturing tribal knowledge from a senior engineer before they move to a different team. <context> [SENIOR ENGINEER NAME] is the only person who knows how to handle failures in [SYSTEM NAME] and none of it is written down. </context> <inputs> - System name: [SYSTEM NAME] - Raw notes or transcript from the senior engineer: [PASTE RAW NOTES] - Common failure modes mentioned: [FAILURE MODE LIST] - Tools or access required: [REQUIRED ACCESS] - Deadline before the transition: [TRANSITION DATE] </inputs> <task> Turn the raw notes into a structured runbook that preserves the specific knowledge, not just generic best practices. </task> <constraints> Keep any exact command, config value, or magic number from the raw notes verbatim rather than paraphrasing it. Flag anything in the notes that is ambiguous and needs the senior engineer to clarify before they leave. </constraints> <format> Return a runbook document plus a short section titled Needs Clarification listing any ambiguous points. </format>

You are a site reliability engineer writing the monthly reliability report distributed to engineering leadership. <context> I need to summarize how [SERVICE NAME] performed this month against its SLOs for the standing leadership review. </context> <inputs> - Service name: [SERVICE NAME] - SLO targets and actual results: [SLO RESULTS DATA] - Number and severity of incidents: [INCIDENT COUNT BY SEVERITY] - Notable changes to infrastructure this month: [INFRA CHANGES] - Trend compared to last month: [TREND DIRECTION] </inputs> <task> Write a monthly reliability report that covers SLO performance, incident summary, notable changes, and trend direction. </task> <constraints> Lead with whether SLOs were met or missed, do not bury that in the middle of the report. Keep the whole report to one page. Use plain numbers, not vague terms like mostly stable. </constraints> <format> Return a report with sections SLO Performance, Incident Summary, Notable Changes, and Trend. </format>

You are a site reliability engineering lead preparing talking points for a quarterly reliability review with executive leadership. <context> I have a 15 minute slot in the quarterly business review to talk about reliability across our services and want to make it count. </context> <inputs> - Services covered: [SERVICE NAMES] - Quarterly SLO attainment summary: [ATTAINMENT SUMMARY] - Biggest incident of the quarter: [BIGGEST INCIDENT SUMMARY] - Investment requested, if any: [INVESTMENT ASK] - Time allotted: [MINUTES ALLOTTED] </inputs> <task> Prepare talking points and slide outline for the review that covers the quarter's reliability performance and makes the case for the investment ask if one exists. </task> <constraints> Fit within the time allotted, roughly 100 words of speaking content per minute. Put the investment ask on its own slide, do not bury it inside the incident recap. </constraints> <format> Return a slide by slide outline with a one sentence speaker note under each slide title. </format>

You are a site reliability engineer building the business case for an infrastructure investment that has no visible feature to show for it. <context> I want budget approval for [INVESTMENT DESCRIPTION] but the finance team only approves requests tied to clear business outcomes. </context> <inputs> - Investment description: [INVESTMENT DESCRIPTION] - Estimated cost: [COST ESTIMATE] - Incidents this would have prevented historically: [PAST INCIDENT EXAMPLES] - Estimated revenue or support cost impact of those incidents: [IMPACT ESTIMATE] - Alternative if this is not approved: [FALLBACK OPTION] </inputs> <task> Write a business case that connects the investment to concrete past incidents and their cost, translated into terms a finance stakeholder understands. </task> <constraints> Use only the cost figures given, do not invent numbers. State the fallback plainly if the investment is rejected, do not soften it into vague risk language. </constraints> <format> Return a one page business case with sections Ask, Cost, Evidence, and If Not Approved. </format>

You are a site reliability engineer proposing a project to reduce manual, repetitive operational work on your team. <context> My team spends a large share of its time on manual [TOIL TASK DESCRIPTION] instead of engineering work, and I want to make the case to automate it. </context> <inputs> - Toil task description: [TOIL TASK DESCRIPTION] - Hours spent per week on this task: [HOURS PER WEEK] - Number of people who do it: [PEOPLE COUNT] - Proposed automation approach: [AUTOMATION APPROACH] - Estimated effort to build it: [BUILD EFFORT ESTIMATE] </inputs> <task> Write a toil reduction proposal that quantifies the current cost in engineer hours and lays out the automation approach with an effort estimate. </task> <constraints> Show the payback period in weeks based on hours saved versus build effort. Do not propose an automation approach beyond the one given in the inputs. </constraints> <format> Return a proposal with sections Current Cost, Proposed Fix, Effort Estimate, and Payback Period. </format>

You are a site reliability engineer analyzing incident data across a full quarter to spot patterns leadership should know about. <context> I have a spreadsheet of every incident from the last quarter for [SERVICE NAME] and need to find the story in the data before the retro. </context> <inputs> - Raw incident list with dates and causes: [PASTE INCIDENT LIST] - Total incident count: [TOTAL INCIDENT COUNT] - Services most frequently involved: [MOST AFFECTED SERVICES] - Time of day or day of week patterns noticed: [TIMING NOTES] - Comparison to previous quarter: [PREVIOUS QUARTER COUNT] </inputs> <task> Analyze the incident list for recurring causes, timing patterns, and the services most often involved, and compare the total against the previous quarter. </task> <constraints> Only report a pattern if it appears in at least three separate incidents, do not overstate a trend from one or two data points. State clearly whether the quarter trended better or worse than the previous one. </constraints> <format> Return sections Top Recurring Causes, Timing Patterns, Most Affected Services, and Quarter Over Quarter Comparison. </format>