30 Claude Prompts for DevOps

You are a cloud infrastructure architect who reviews environments for cost efficiency and reliability risk. <context> I want an outside review of our cloud setup because costs have grown and I am not sure our architecture matches our actual traffic. </context> <inputs> - Cloud provider: [AWS, GCP, AZURE] - Current monthly spend: [AMOUNT] - Key services in use: [LIST, E.G. EC2, RDS, S3, LAMBDA] - Traffic pattern: [STEADY, SPIKY, SEASONAL] - Known concerns: [OVERPROVISIONED, SINGLE REGION, NO AUTOSCALING] </inputs> <task> Review the setup described and identify cost inefficiencies and reliability risks. For each finding, explain the likely dollar or downtime impact. </task> <constraints> Only comment on what is described, do not assume services that were not mentioned. Separate quick wins from changes that need planning and testing first. </constraints> <format> Two sections: Cost findings and Reliability findings. Each finding as a bullet with impact and suggested fix. </format>

You are a Kubernetes platform engineer who audits cluster configs before they go to production. <context> We are about to promote a cluster configuration to production and I want it reviewed for common misconfigurations first. </context> <inputs> - Cluster config or manifest excerpts: [PASTE YAML] - Node count and sizing: [DESCRIBE] - Resource requests and limits set: [YES, NO, PARTIALLY] - Autoscaling configured: [YES, NO] - Namespace isolation strategy: [DESCRIBE OR NONE] </inputs> <task> Review the configuration for missing resource limits, pod security issues, single points of failure like unreplicated deployments, and networking or namespace isolation gaps. </task> <constraints> Be specific to the manifests provided rather than generic Kubernetes advice. Flag anything that would cause a noisy neighbor problem between workloads. </constraints> <format> Checklist format, each item marked Pass, Fail, or Needs review, with a one line reason for each Fail. </format>

You are an infrastructure as code specialist who has migrated manually managed environments to Terraform and similar tools. <context> Our infrastructure is currently managed by hand through the cloud console and I need a plan to move it to code without causing an outage. </context> <inputs> - Current environment: [DESCRIBE MAIN RESOURCES] - Target IaC tool: [TERRAFORM, PULUMI, CLOUDFORMATION] - Team's IaC experience: [NONE, SOME, EXPERIENCED] - Timeline: [X WEEKS] - Highest risk resource: [E.G. PRODUCTION DATABASE, LOAD BALANCER] </inputs> <task> Propose a phased migration plan that starts with low risk resources, imports existing infrastructure into code safely, and ends with the highest risk resource once the process is proven. </task> <constraints> Do not suggest recreating resources from scratch, they must be imported so nothing goes down. Match the pace of the plan to the team's stated experience level. </constraints> <format> Phased plan with numbered phases, what gets migrated in each, and a verification step to run after each phase before moving on. </format>

You are a cloud security engineer who specializes in network segmentation and access control review. <context> I want a review of our network rules before an audit, specifically looking for overly permissive access. </context> <inputs> - Security group or firewall rules: [PASTE RULES OR DESCRIBE] - Environments involved: [PROD, STAGING, DEV] - Public facing services: [LIST] - VPN or bastion access: [DESCRIBE SETUP] - Compliance requirement if any: [SOC2, HIPAA, NONE] </inputs> <task> Identify overly broad rules such as open to all IPs on sensitive ports, unnecessary cross environment access, and missing segmentation between public facing and internal services. </task> <constraints> Explain the actual attack path each finding enables, not just that it violates a general rule. Prioritize findings that affect production over dev or staging. </constraints> <format> Table: Rule or gap, Attack path it enables, Priority (critical, high, medium), Recommended fix. </format>

You are a site reliability engineer who designs disaster recovery plans for production systems. <context> We do not have a documented disaster recovery plan and I need one that matches our actual infrastructure and recovery targets. </context> <inputs> - Critical systems: [LIST SYSTEMS] - Current backup strategy: [DESCRIBE OR NONE] - Target recovery time objective: [X HOURS] - Target recovery point objective: [X HOURS OF ACCEPTABLE DATA LOSS] - Infrastructure provider: [AWS, GCP, AZURE, ON PREM] </inputs> <task> Design a disaster recovery plan that meets the stated recovery time and recovery point objectives, covering backup verification, failover steps, and communication during an incident. </task> <constraints> Be honest if the current backup strategy cannot meet the stated objectives, do not write a plan around a gap that has not been closed. Keep steps executable by an on call engineer under pressure. </constraints> <format> Sections: Gap analysis against stated objectives, Backup and verification plan, Failover steps, Communication plan during a disaster. </format>

You are a DevOps engineer who writes runbooks that a teammate can follow without asking questions. <context> I need a deployment runbook for a service so that any engineer on call can deploy it safely, not just the person who built it. </context> <inputs> - Service name: [SERVICE NAME] - Deployment tool or command: [DESCRIBE] - Pre deploy checks needed: [LIST, E.G. TESTS PASSING, STAGING VERIFIED] - Post deploy verification: [DESCRIBE, E.G. HEALTH ENDPOINT, LOGS] - Who to notify: [TEAM OR CHANNEL] </inputs> <task> Write a runbook with numbered steps from pre deploy checks through the deployment itself to post deploy verification, written so someone unfamiliar with the service can follow it exactly. </task> <constraints> Every step must be an action, not a description. Include what to do if a post deploy check fails, do not just stop at the happy path. </constraints> <format> Numbered steps grouped under headers: Before you deploy, During deployment, After deployment, If something fails. </format>

You are an SRE who builds on call runbooks used during real incidents. <context> We are formalizing on call and I need a runbook for our most common incident type so new on call engineers are not starting from zero at 3am. </context> <inputs> - Common incident type: [E.G. HIGH LATENCY, SERVICE DOWN, DATABASE CONNECTION ERRORS] - Monitoring or alerting tool: [DATADOG, GRAFANA, PAGERDUTY, ETC] - Key dashboards or logs to check: [LIST] - Escalation path: [WHO TO PAGE NEXT] - Typical root causes seen before: [LIST IF KNOWN] </inputs> <task> Write a runbook that walks an on call engineer from the alert firing through triage, likely checks based on past root causes, and escalation if they cannot resolve it within a set time. </task> <constraints> Assume the on call engineer is half asleep and stressed, keep instructions short and scannable. Include a clear time limit for when to escalate rather than keep troubleshooting alone. </constraints> <format> Sections: Alert description, Immediate triage steps, Likely causes to check first, Escalation trigger and contact, Resolution confirmation. </format>

You are a DevOps engineer who documents manual processes clearly before turning them into automation. <context> We have a manual process that only one person really knows how to do and I need it documented properly before we can automate or hand it off. </context> <inputs> - Process name: [E.G. CERTIFICATE RENEWAL, DATABASE FAILOVER] - Rough steps as you currently understand them: [LIST STEPS] - Tools or systems touched: [LIST] - Frequency this is done: [HOW OFTEN] - Known gotchas: [LIST IF ANY] </inputs> <task> Turn the rough steps into a clear, complete runbook, filling gaps in the sequence and flagging any step that seems risky or unclear so it can be verified before automating. </task> <constraints> Do not invent steps that were not implied by the input, mark anything uncertain as needing verification from the person who currently does this by hand. </constraints> <format> Numbered runbook steps, with a separate list at the end titled Needs verification for anything unclear or assumed. </format>

You are a database reliability engineer who plans schema migrations for production databases without downtime. <context> I have a schema migration coming up on a production database and I want a runbook that avoids locking the table or losing data. </context> <inputs> - Database type: [POSTGRES, MYSQL, ETC] - Migration description: [DESCRIBE THE SCHEMA CHANGE] - Table size or traffic level: [ROW COUNT OR REQUESTS PER SECOND] - Migration tool: [FLYWAY, ALEMBIC, RAILS MIGRATIONS, MANUAL SQL] - Downtime tolerance: [NONE, X MINUTES] </inputs> <task> Write a runbook for executing the migration safely given the stated downtime tolerance, including how to verify the migration before running it against production and how to detect if it is causing lock contention. </task> <constraints> If the downtime tolerance is none, the plan must use an online or backward compatible approach, not a blocking migration. Call out anything in the described change that risks locking a large table. </constraints> <format> Sections: Pre migration verification, Execution steps, Signs of lock contention to watch during the run, Rollback approach if it fails partway. </format>

You are a platform engineer who writes handoff documentation when a service moves to a new owning team. <context> We are handing a service off to another team and I need documentation that gets them productive fast without needing to ask us everything. </context> <inputs> - Service name and purpose: [DESCRIBE] - Key dependencies: [UPSTREAM AND DOWNSTREAM SERVICES] - Deployment process: [DESCRIBE OR LINK] - Monitoring and alerting setup: [DESCRIBE] - Common issues the current team has hit: [LIST] </inputs> <task> Write a handoff runbook covering what the service does, how it is deployed, how it is monitored, and the common issues the new team should expect, with enough detail that they can operate it independently. </task> <constraints> Write for a team that has never touched this service before, do not assume shared context. Prioritize the common issues section, that is what will save them the most time. </constraints> <format> Sections: Service overview, Dependencies map, Deployment process, Monitoring and alerts, Common issues and how to resolve them. </format>

You are an incident commander who writes clear, blameless postmortems after production incidents. <context> We just resolved a production incident and I need a postmortem written up before the details fade from memory. </context> <inputs> - Incident summary: [WHAT HAPPENED] - Timeline of events with timestamps: [PASTE TIMELINE] - Impact: [USERS AFFECTED, DURATION, REVENUE IF KNOWN] - Root cause if known: [DESCRIBE OR UNKNOWN] - Actions already taken during the incident: [LIST] </inputs> <task> Write a postmortem covering the timeline, impact, root cause analysis, and follow up action items with owners, written in a blameless tone that focuses on systems and process rather than individuals. </task> <constraints> Do not name or blame any individual, focus on what allowed the failure to happen and what will prevent it recurring. If the root cause is unknown, say so plainly rather than guessing. </constraints> <format> Sections: Summary, Timeline, Impact, Root cause, What went well, What went wrong, Action items with owner and due date placeholders. </format>

You are a reliability engineer trained in root cause analysis techniques. <context> I have a surface level explanation for an incident but I suspect it is not the actual root cause, and I want to dig deeper before we close it out. </context> <inputs> - Incident description: [DESCRIBE WHAT HAPPENED] - Initial explanation given: [WHAT SOMEONE ALREADY SAID CAUSED IT] - Systems involved: [LIST] - Any logs or error messages: [PASTE IF AVAILABLE] </inputs> <task> Run a five whys analysis starting from the initial explanation, pushing past the first answer each time to find the actual systemic root cause, not just the immediate trigger. </task> <constraints> Do not stop at a human error explanation, keep asking why until you reach a process or system gap that can actually be fixed. If the available information is not enough to go deeper, say what additional information is needed. </constraints> <format> Numbered why chain from one through five, ending with a stated systemic root cause and one recommended fix. </format>

You are a technical communications lead who writes incident updates for customers during and after outages. <context> We had an outage that affected customers and I need a communication that is honest without oversharing internal details. </context> <inputs> - What broke: [DESCRIBE IN PLAIN TERMS] - Who was affected: [ALL CUSTOMERS, SPECIFIC REGION, SPECIFIC FEATURE] - Duration: [X MINUTES OR HOURS] - Current status: [RESOLVED, MONITORING, PARTIALLY RESOLVED] - Fix or prevention step being taken: [DESCRIBE] </inputs> <task> Write a customer facing incident update that explains what happened in plain language, who was affected, current status, and what is being done to prevent it happening again. </task> <constraints> Do not use internal jargon or name internal systems by their technical names. Do not overpromise a timeline you are not sure of. Keep it honest but not alarmist. </constraints> <format> A short update of 3 to 5 sentences suitable for a status page, followed by a slightly longer version suitable for a follow up email. </format>

You are an SRE lead who standardizes how a team classifies incident severity. <context> Our team classifies incident severity inconsistently and I want a clear guide so everyone applies the same criteria. </context> <inputs> - Types of incidents we typically see: [LIST EXAMPLES] - Current severity levels if any: [DESCRIBE OR NONE] - Business context: [E.G. B2B SAAS, CONSUMER APP, INTERNAL TOOLS] - What triggers a page versus a ticket today: [DESCRIBE] </inputs> <task> Define severity levels with clear, objective criteria for each, using the example incidents given to show what would classify at each level. Include what response is expected at each severity, such as paging versus next business day. </task> <constraints> Criteria must be objective enough that two different engineers would classify the same incident the same way. Avoid vague language like significant impact without defining what that means numerically or functionally. </constraints> <format> Table with columns: Severity level, Criteria, Example from the ones given, Expected response. </format>

You are an observability engineer who reviews incidents to find gaps in detection and alerting. <context> An incident took longer to detect than it should have and I want to understand exactly where the delay came from. </context> <inputs> - Time the issue actually started: [TIMESTAMP] - Time it was detected: [TIMESTAMP] - Time it was resolved: [TIMESTAMP] - Alerts that fired, if any: [LIST OR NONE] - Monitoring tools in place: [LIST] </inputs> <task> Analyze the gap between when the issue started and when it was detected, identify what monitoring or alerting should have caught it sooner, and propose specific alert thresholds or checks to close that gap. </task> <constraints> Be specific about what metric or log pattern would have caught this earlier, do not suggest generic add more monitoring advice. If existing alerts should have fired but did not, say so directly. </constraints> <format> Sections: Detection gap analysis with time breakdown, Specific alert or check to add, Suggested threshold, Expected earlier detection time. </format>

You are a release manager who builds checklists that catch issues before they reach production. <context> I want a pre release checklist for our team so we stop shipping things that break in predictable, avoidable ways. </context> <inputs> - Type of release: [FEATURE, HOTFIX, MAJOR VERSION] - Systems typically affected: [LIST] - Past release issues we have hit: [LIST EXAMPLES] - Approval process: [WHO SIGNS OFF] - Release frequency: [HOW OFTEN] </inputs> <task> Build a pre release checklist tailored to the type of release and the past issues listed, covering code, testing, communication, and rollback readiness. </task> <constraints> Every item must map to a real risk, not generic best practice filler. Weight the checklist toward the specific past issues given rather than a one size fits all list. </constraints> <format> Checklist grouped under headers: Code and testing, Communication, Rollback readiness, Final sign off. </format>

You are a platform engineering lead who writes change proposals for infrastructure changes that need approval. <context> I have a change I need to get approved through our change management process and I want it written clearly enough that reviewers can assess the risk quickly. </context> <inputs> - Change description: [DESCRIBE THE CHANGE] - Why this change is needed: [REASON] - Systems affected: [LIST] - Rollback plan summary: [DESCRIBE] - Proposed change window: [DATE AND TIME] </inputs> <task> Write a change proposal covering what is changing, why, the risk level, the rollback plan, and the proposed window, in a format a change advisory board can approve quickly. </task> <constraints> Be honest about risk level, do not downplay it to get faster approval. If the rollback plan has gaps, state them rather than hiding them. </constraints> <format> Sections: Change summary, Justification, Risk assessment, Rollback plan, Proposed window, Approval needed from. </format>

You are a release engineer who designs gradual feature flag rollouts to reduce blast radius. <context> We are shipping a feature behind a flag and I want a rollout plan that limits risk instead of flipping it on for everyone at once. </context> <inputs> - Feature description: [DESCRIBE] - Feature flag tool: [LAUNCHDARKLY, SPLIT, HOME GROWN, ETC] - User base size: [NUMBER OR SCALE] - Metrics to watch during rollout: [LIST, E.G. ERROR RATE, LATENCY, CONVERSION] - Rollback trigger: [WHAT WOULD MAKE YOU TURN IT OFF] </inputs> <task> Design a staged rollout plan with percentage increments, what to watch at each stage, and how long to wait before increasing exposure. </task> <constraints> Do not suggest a single jump to 100 percent, this must be gradual with defined checkpoints. Tie the rollback trigger to a specific measurable threshold, not a vague feeling that something is wrong. </constraints> <format> Table with columns: Stage, Percentage of users, Duration before next stage, Metrics to check, Rollback trigger at this stage. </format>

You are a technical writer embedded in a DevOps team who translates release changes for different audiences. <context> I need release notes for an upcoming release that work for both the engineering team and non technical stakeholders. </context> <inputs> - List of changes in this release: [PASTE COMMIT MESSAGES OR CHANGE LIST] - Release version: [VERSION NUMBER] - Any breaking changes: [YES OR NO, DESCRIBE] - Audience for stakeholder version: [E.G. PRODUCT TEAM, CUSTOMERS, LEADERSHIP] </inputs> <task> Produce two versions of the release notes from the same change list: a technical version for engineers with specifics, and a plain language version for the stakeholder audience given. </task> <constraints> The technical version should reference actual components or endpoints changed. The stakeholder version must avoid engineering jargon entirely and focus on what changed for them, not how. </constraints> <format> Two clearly labeled sections: Technical release notes and Stakeholder summary, each as a bulleted list. </format>

You are a DevOps lead who sets deployment freeze policies around high risk periods. <context> We have a high risk period coming up and I want to define a deployment freeze policy that protects stability without blocking necessary work entirely. </context> <inputs> - High risk period: [E.G. HOLIDAY SEASON, MAJOR EVENT, BLACK FRIDAY] - Freeze dates: [START AND END DATE] - Systems this applies to: [ALL, SPECIFIC SERVICES] - Exceptions needed: [E.G. SECURITY PATCHES, CRITICAL BUG FIXES] - Approval process for exceptions: [WHO APPROVES] </inputs> <task> Draft a deployment freeze policy that states what is frozen, what exceptions are allowed, and the approval process for an exception request during the freeze. </task> <constraints> Be clear that security patches and critical fixes still need a path to ship, a freeze that blocks everything including security fixes is itself a risk. Keep the policy short enough that people will actually read it. </constraints> <format> Sections: Freeze scope and dates, What is allowed without exception, Exception request process, Who approves exceptions. </format>

You are an SRE who designs alerting systems that page people only when it matters. <context> Our team is suffering from alert fatigue, too many pages are firing for things that do not need a human at 2am. </context> <inputs> - Current alerts that fire most often: [LIST] - Monitoring tool: [DATADOG, PROMETHEUS, GRAFANA, ETC] - Which alerts have led to real action versus been ignored: [DESCRIBE] - On call team size: [NUMBER] </inputs> <task> Review the listed alerts and recommend which should be downgraded to a non paging notification, which should be tuned with a better threshold, and which are correctly urgent as is. </task> <constraints> Base recommendations on whether the alert has led to real action historically, not just on its subject matter. Do not recommend removing an alert entirely without suggesting what replaces its coverage. </constraints> <format> Table with columns: Alert, Recommendation (downgrade, retune, keep as is), Reasoning, Suggested new threshold if applicable. </format>

You are a reliability engineer who defines SLOs that reflect actual user experience. <context> We do not have formal SLOs for a key service and I want to define ones that actually reflect what our users care about. </context> <inputs> - Service name and purpose: [DESCRIBE] - Current typical latency and error rate: [DESCRIBE OR PASTE METRICS] - What users actually care about: [E.G. RESPONSE TIME, UPTIME, DATA FRESHNESS] - Business criticality: [CUSTOMER FACING, INTERNAL, REVENUE CRITICAL] </inputs> <task> Propose service level objectives with specific numeric targets for availability and latency, based on the current metrics and what matters to users, along with a suggested error budget policy. </task> <constraints> Targets must be realistic given the current metrics provided, do not propose an SLO the service is already failing to meet without acknowledging the gap. Explain what happens when the error budget is exhausted. </constraints> <format> Sections: Proposed SLOs with numeric targets, Reasoning tied to user needs, Error budget policy, Gap versus current performance if any. </format>

You are an infrastructure capacity planner who forecasts resource needs from traffic growth. <context> We are expecting traffic growth and I need a capacity plan so we are not caught scrambling to scale infrastructure reactively. </context> <inputs> - Current infrastructure and scale: [DESCRIBE, E.G. NUMBER OF INSTANCES, DATABASE SIZE] - Expected growth: [X PERCENT OVER Y MONTHS, OR DESCRIBE EVENT] - Current utilization at peak: [PERCENT CPU, MEMORY, OR RELEVANT METRIC] - Autoscaling in place: [YES, NO, PARTIAL] - Budget constraint if any: [DESCRIBE OR NONE] </inputs> <task> Estimate when current infrastructure will hit capacity limits given the expected growth, and recommend what to scale first and by how much, with a timeline for when action is needed. </task> <constraints> Show the reasoning behind the timeline estimate, do not just give a number without the math behind it. Flag the single component most likely to become a bottleneck first. </constraints> <format> Sections: Capacity timeline with reasoning shown, Bottleneck most likely to hit first, Recommended scaling action, When to act by. </format>

You are a program manager for engineering reliability who ensures postmortem action items actually get done. <context> Our postmortem action items get written but rarely completed, and I want a process that fixes that. </context> <inputs> - How action items are currently tracked: [DESCRIBE OR NONE] - Number of postmortems per month: [NUMBER] - Typical reason items stall: [E.G. NO OWNER, LOW PRIORITY, FORGOTTEN] - Tooling available: [JIRA, LINEAR, GOOGLE SHEETS, ETC] </inputs> <task> Design a lightweight process for tracking postmortem action items from creation through completion, including how items get prioritized against regular feature work and how overdue items get escalated. </task> <constraints> The process must be lightweight enough that people will actually follow it, do not propose a heavy process requiring a dedicated coordinator. Address the specific stall reason given directly. </constraints> <format> Sections: Process steps from creation to completion, How items get prioritized, Escalation path for overdue items, Suggested review cadence. </format>

You are an observability engineer who designs dashboards that surface the right signal, not just available metrics. <context> We are launching a new service and I need to define what the monitoring dashboard should show before we build it, not after something goes wrong. </context> <inputs> - Service name and purpose: [DESCRIBE] - Key user facing behavior: [WHAT THE SERVICE DOES FOR USERS] - Dependencies: [UPSTREAM AND DOWNSTREAM SYSTEMS] - Monitoring tool: [GRAFANA, DATADOG, ETC] - Team that will use the dashboard: [ON CALL, PRODUCT, LEADERSHIP] </inputs> <task> Define what the dashboard should show, organized by what matters most to the team that will use it, covering golden signals like latency, traffic, errors, and saturation as well as any service specific metric. </task> <constraints> Do not just list every available metric, prioritize what actually indicates the service is healthy from the user's perspective. Tie each panel to a specific question it answers. </constraints> <format> Table with columns: Panel or metric, Question it answers, Why it matters for this audience. </format>