On a Thursday in May I spent 45 minutes writing a runbook for an alert I’d already written a runbook for twice, on two other services. Same structure, different service name. That was the moment I started tracking where my week actually went.
The answer was 3 hours. Three hours a week writing runbooks from a blank template, generating boilerplate Terraform, hand-building kubectl commands I'd typed a hundred times, and drafting postmortem docs while I was still tired from the incident.
None of it needed judgment. All of it needed time. And all of it is exactly what Claude Code is built for.
Six weeks later that 3 hours is 20 minutes. This is every workflow I changed the exact prompts, the exact CLAUDE.md, and the two things I still refuse to hand it.
Most AI coding tools are IDE assistants autocomplete that got smarter. GitHub Copilot started there and grew into agent workflows. Cursor is an IDE built around AI. Both are excellent at what they do.
Claude Code is different. It’s terminal-native, built as an agent, and it runs real commands on your machine with your approval. Not suggestions. Actual execution: reading files, running shell commands, editing configs, calling kubectl, running terraform plan. Because it runs in your shell, it uses the same SSH keys, cloud credentials, and kubeconfig you already have loaded.
One thing to be clear about up front: it asks before it acts. Every command surfaces a permission prompt the first time you approve it, deny it, or allow that command going forward. Nothing runs behind your back. That gate is the whole reason I trust it near infrastructure at all.
That distinction matters for SRE work. Most of what I needed to automate wasn’t “write me a function.” It was “read this log, build a runbook for this alert, generate a Terraform module that matches our existing patterns, write a postmortem based on this incident timeline.”
Tasks that span multiple files, require context from your actual codebase, and produce outputs that plug directly into your existing workflow. That’s Claude Code’s home territory.
The pricing, as of July 2026:
(Check claude.com/pricing before you commit the tiers move.)
I run Max 5x. At $100/month it pays for itself if it saves 2 hours of engineer time a month. It saves me 3 hours a week.
Before any workflow, the single most impactful thing you can do is write a CLAUDE.md file in your repository root. This is a context file Claude Code reads at the start of every session your team conventions, your infrastructure patterns, your SRE standards.
Without it, Claude Code gives you generic outputs. With it, you get outputs that match your actual environment.
Here’s mine for an SRE repository:
This file runs at the start of every Claude Code session. It takes 20 minutes to write and affects every single output for the rest of time.
Writing runbooks was my biggest time sink. Every new alert needs one. Every alert has the same structure but different content. I was writing them from a blank template every time.
Now I do this:
Claude Code reads the CLAUDE.md context, checks the existing runbooks in /runbooks/ for format consistency, then generates:
The output includes our naming convention, uses our cluster name, references known issues from our incident history, and matches the exact format of our existing runbooks. I review it, make minor tweaks, commit it.That used to take 45 minutes. It takes 5 now - mostly review time.---## Workflow 2: Terraform Module Generation (2 hours → 15 min)New service needs infrastructure? That used to mean copying an existing module, renaming everything, hunting for the values I forgot to update, running `terraform validate` until it stopped complaining.Now:Claude Code reads the existing modules in /modules/, understands the patterns how we structure variables, how we tag resources, where we put outputs and generates a complete module that matches.
It uses our tag structure. It uses our naming convention. The IAM role has exactly the SES and S3 permissions I specified, nothing more. I run terraform validate, it passes first time, I review the plan.
The old process: 2 hours. The new process: 15 minutes plus review.
Postmortems are the worst kind of writing structured, emotionally loaded, time-sensitive. You’re doing it right after an incident when you’re tired, and it needs to be done before the details fade.
After an incident I now run:
Draft a postmortem for the following incident:> > Date: July 14, 2026> Duration: 47 minutes (02:14 - 03:01 UTC)> Impact: payment-service returning 503 for 40% of checkout requests> Root cause: RDS primary failover triggered by maintenance window, > connection pool not configured with retry logic> Detection: PagerDuty alert at T+3 minutes (error budget burn rate)> Resolution: Increased connection pool max_retries to 3, > added exponential backoff in payment-service config> > Use our postmortem template and make it blameless. > Include a timeline, contributing factors, and action items.
Claude Code reads /templates/postmortem.md, uses the incident details, and produces a structured draft with timeline, contributing factors, and action items blameless framing throughout.
I spend 10 minutes adding colour and specifics only I know. The structure, the timeline, the action item format — all done.
This sounds trivial but it adds up. I spend time constructing kubectl commands with the right flags, right namespaces, right output formats. Especially for less frequent commands I don't have memorised.
Give me a kubectl one-liner that shows all pods in the payments namespace > that have been restarted more than 3 times in the last hour, sorted by > restart count, including the node they're running on.
Response in 3 seconds:
kubectl get pods -n payments \ -o custom-columns="NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount,NODE:.spec.nodeName" \ --sort-by='.status.containerStatuses[0].restartCount' | \ awk 'NR==1 || $2 > 3'
I could figure this out in 4–5 minutes. Claude Code does it in seconds. For 10 commands a day, that’s 40–50 minutes back.
One honest caveat, because it’s the point of the whole article: restartCount is cumulative, not "last hour" so this filters total restarts, not restarts in the window. I caught that on the read-through and asked it to add a --field-selector on recent events instead. The tool is fast; you're still the one who has to know what "correct" looks like.
New service going into production needs Prometheus alert rules. The old process: find a similar service, copy the rules, edit the thresholds, remember which labels to use, write the runbook annotations.
Generate Prometheus alert rules for the notification-service we just created.> It should alert on:> - Error rate > 1% for 5 minutes (Severity: warning) and > 5% for 2 minutes (critical) > - P99 latency > 500ms for 5 minutes> - Pod restart count > 3 in 1 hour> Use our existing alert format from /monitoring/alerts/payment-service.yaml as reference.
Claude Code reads the payment-service alert file, matches the format, and generates:
Labels match our format.
Thresholds match what I specified.
Runbook URLs follow our naming convention.
This used to take 30 minutes. **It takes 3.**
**I want to be direct about this:** *Claude Code is not a replacement for SRE judgment.*
It doesn’t know whether a terraform destroy is safe to run. It doesn't know whether the alert threshold you asked it to set is actually right for your traffic patterns. It doesn't know the organisational context of why your team made a specific architecture decision three years ago.
Three things I don’t use it for:
Incident command. During an active incident, I don’t want an AI making decisions. The cognitive overhead of reviewing AI outputs when things are on fire is worse than just typing the commands myself. Claude Code is for the work before and after incidents, not during them.
Anything touching production state directly. My CLAUDE.md explicitly tells Claude Code never to run terraform apply without my confirmation. I review every plan. I approve every deployment. The automation is in the generation, not the execution.
Code review for critical paths. Payment flows, auth flows, anything security-relevant I read that code myself. Claude Code can suggest improvements, but the judgment call on whether to merge stays with me.
The hours saved are real. But the bigger win is harder to measure.
Toil isn’t just slow it’s distracting. When I spend 45 minutes writing a runbook, I’m not just spending time. I’m context-switching away from the work that requires actual judgment: reliability architecture, SLO design, incident retrospectives, infrastructure planning.
Delegating the structured, repeatable parts to Claude Code means more of my working hours are spent on the work that actually needs a senior engineer. Not because the other work isn’t important it is but because it doesn’t need *me* specifically.
That’s the real ROI. Not 3 hours saved. 3 hours of low-judgment work replaced by 3 hours of high-judgment work. At $100/month, it’s the best infrastructure investment I made this year.
If you want to replicate this for your own SRE workflow:
There’s no separate claude auth step. The first time you run claude, it opens a browser window for you to log in with your Anthropic account (Pro, Max, or Console). Once you're in, it stays authenticated.
Then write your CLAUDE.md. That's the step most people skip and the one that matters most. Spend 20 minutes documenting:
After that, start with the lowest-risk workflow: runbook generation. It has no side effects, the output is easy to review, and the time savings are immediate.
If you carry a pager, the same instinct behind these workflows shows up in [ The nine Linux commands I actually run at 2AM](https://medium.com/developersglobal/9-linux-commands-ive-run-at-2am-more-times-than-i-can-count-cd8e8a1328d7) the difference between reaching for the right thing in the dark and Googling under pressure.
Next in this series: wiring Claude Code into a CI/CD pipeline so runbooks and alert rules generate automatically when a new service ships — no human in the loop for the boilerplate.
If this saved you an afternoon of toil, a clap help’s [ TowardsAI](https://pub.towardsai.net/) show it to more on-call engineers. Follow if you want the CI/CD automation piece when it lands.
[I Cut 3 Hours of Weekly SRE Toil to 20 Minutes With Claude Code](https://pub.towardsai.net/i-cut-3-hours-of-weekly-sre-toil-to-20-minutes-with-claude-code-969f2923cf72) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.