I Cut 3 Hours of Weekly SRE Toil to 20 Minutes With Claude Code

Last Updated on July 30, 2026 by Editorial Team Author(s): Moiz Ezzy Originally published on Towards AI. I Cut 3 Hours of Weekly SRE Toil to 20 Minutes With Claude Code Created by Author 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. What Claude Code Actually Is (And Why It’s Different) 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: Pro: $20/month — Claude Code included, good for getting started Max 5x: $100/month — 5x Pro’s usage limits, higher output limits Max 20x: $200/month — 20x Pro’s usage, for daily heavy use (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. Setup: The CLAUDE.md File That Changes Everything 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: # CLAUDE.md — SRE Infrastructure Repository## ContextThis is the SRE infrastructure repository for a multi-region AWS deployment.Primary stack: EKS (Kubernetes 1.29), Terraform 1.8, Datadog for observability,PagerDuty for alerting, GitHub Actions for CI/CD.## Coding Conventions- Terraform: modules in /modules, environments in /environments/{prod,staging,dev}- Always use remote state (S3 backend + DynamoDB lock table)- Tag every resource with: Environment, Team, Service, CostCenter- No hardcoded values - use variables.tf for all configuration- Kubernetes manifests: namespace per service, resource requests and limits required## SRE Standards- SLO targets: 99.9% availability for production services- Alert thresholds: fire at 10% below SLO (i.e. P99 > 450ms when SLO is 500ms)- Runbooks: stored in /runbooks/{service-name}/, named {alert-name}.md- Postmortem template: /templates/postmortem.md- All kubectl commands: use namespaces explicitly, never default namespace## Incident Response- Severity 1: customer-facing, paging the on-call immediately- Severity 2: degraded, notify team channel- Severity 3: internal only, ticket created- Runbook format: Impact → Detection → Mitigation options → Escalation## What NOT to Do- Never run terraform apply without my explicit confirmation- Never delete resources without listing them first- Never commit credentials or secrets- Always validate Terraform with terraform validate before showing output 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. Workflow 1: Runbook Generation (45 min → 5 min) 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: # In the repo root, start Claude Codeclaude# Prompt:> I have a new PagerDuty alert: "EKS node memory utilisation > 85% for 10 minutes > on cluster prod-us-east-1". Generate a runbook following our standard format > in /runbooks/eks-nodes/high-memory.md. Include kubectl commands to diagnose > the issue, common causes for our stack, and mitigation steps. Claude Code reads the CLAUDE.md context, checks the existing runbooks in /runbooks/ for format consistency, then generates: # EKS Node High Memory Utilisation**Alert:** node_memory_utilisation > 85% for 10 minutes**Severity:** 2 - degraded, notify team channel**Service:** EKS cluster prod-us-east-1## ImpactNode memory pressure can trigger pod evictions, causing service disruptionfor workloads scheduled on the affected node.## Detection```bash# Identify the affected nodekubectl get nodes -o wide | grep -v Ready# Check memory pressure conditionkubectl describe node NODE_NAME | grep -A5 Conditions# See which pods are consuming the most memorykubectl top pods -A --sort-by=memory | head -20# Check for OOMKilled pods in the last hourkubectl get events -A --field-selector reason=OOMKilling \ --sort-by='.lastTimestamp' | tail -20 Common Causes (prod-us-east-1 specific) Memory leak in the payment-service check for VmRSS growth over 6h JVM heap not bounded check Java services for -Xmx flags Batch job running on wrong node group check node selectors Embeddings service loading model into memory […]