A Sydney infrastructure team we spoke with used to lose the first hour of any production incident to a single question: where is the runbook, and is it even current. Their answer now is Claude Code, wired into the same repository as their Terraform and their alerting config, so the runbook, the infrastructure definition, and the incident notes are never more than one prompt apart.
Where Claude Code actually sits in a DevOps day
Most Australian platform teams are not looking for another dashboard. They are looking for the three hours a week that go missing between deploys: writing the runbook nobody reads until 2am, reviewing a colleague's Terraform module line by line, and typing up the incident report after everyone just wants to go home. Claude Code sits inside the existing terminal and repo, reading the actual infrastructure-as-code and the actual monitoring config rather than a stale wiki page.
Runbook generation: Claude Code reads the Terraform, Pulumi, or CloudFormation for a service and drafts a runbook from what is actually deployed, not from someone's memory of last quarter's architecture.
IaC review: Before a plan is applied, Claude Code can flag a security group left wide open, a missing tag policy, or a resource that will force a replace instead of an in-place update.
Incident drafts: Paste in the Slack thread, the alert timeline, and the commands that were run, and get a structured draft incident report while the details are still fresh.
Alert triage notes: Claude Code can summarise a noisy PagerDuty history into the two or three alerts worth tuning this sprint.
Writing runbooks that people actually open
The reason most runbooks go stale is that updating them is a separate chore from the work itself. A Melbourne-based SaaS platform team changed that by asking Claude Code to regenerate the runbook for a service as part of the pull request whenever the underlying Terraform changes. The model reads the module, the variables, and the existing runbook, then proposes a diff rather than a rewrite, so a human reviewer can approve or correct it in under five minutes.
That team estimated the old process cost roughly $38,000 a year in engineer time once you add up the quarterly runbook audits, the Slack archaeology during incidents, and the onboarding sessions where a new hire had to be walked through undocumented steps. Folding runbook maintenance into the existing PR review did not eliminate that cost, but it cut the audit and onboarding portion by more than half within two quarters.
Reviewing infrastructure-as-code before it ships
IaC review is the part of the job that gets rushed under deadline pressure, which is exactly when a misconfigured IAM role or an open ingress rule slips through. Claude Code can run a first pass on a Terraform plan before a human reviewer even opens the pull request: checking for drift against the last known-good state, flagging resources without cost tags, and calling out changes that look like they will trigger a destroy-and-recreate rather than the safe update the author intended.
For regulated businesses, this matters beyond tidiness. A financial services client with APRA reporting obligations needed an audit trail showing that every infrastructure change had been reviewed against their change management policy, not just approved by whoever was online. Having Claude Code produce a written review comment on every plan, referencing the specific policy clause, gave the compliance team something concrete to point to instead of a verbal assurance that someone looked at it.
Drafting incident reports while the details are still fresh
Post-incident reviews suffer from the same problem as runbooks: by the time anyone sits down to write the report, half the detail has evaporated. Feeding Claude Code the raw material, timestamps from the monitoring tool, the command history, and the Slack thread, produces a first draft with a timeline, a plain-English summary of impact, and a list of contributing factors within minutes rather than days. Engineers still own the judgement calls about root cause and remediation, but they are editing a draft instead of staring at a blank page at 11pm.
One Brisbane logistics company tracked the change directly: incident reports that used to take an on-call engineer two to three hours to write the following day were drafted in under fifteen minutes, with the human review taking another twenty. Multiplied across roughly 40 incidents a year, that is enough reclaimed time to justify the setup on its own.
What this costs and how AU teams are rolling it out
Most teams start with a single service, usually whichever one generates the most on-call pages, and expand from there. A typical setup for a team of six to ten engineers, covering Claude Code seats, the initial runbook backfill, and an afternoon workshop on prompting patterns for IaC review, runs in the order of $6,000 to $9,000 as a one-off, with ongoing seat costs scaling with headcount. Businesses with existing compliance obligations under the Privacy Act should also confirm what infrastructure metadata and log excerpts are being pasted into prompts, since runbooks and incident drafts often reference customer-facing systems even when they do not contain customer data directly.
The pattern that works best in practice is narrow scope first: one service, one runbook, one review cycle, measured against what the team was doing before. Teams that try to roll Claude Code across every service and every review gate in week one tend to generate noise that reviewers learn to ignore, which defeats the purpose.
If you want a second opinion on where this fits in your own pipeline, book a short session with Automata AI and we will walk through your current runbook and IaC review process against what Claude Code can realistically take off your plate.
