A Sev-1 is the worst moment to be improvising. Production is down, the Australian business on the other end is losing money by the minute, and every keystroke carries risk. Used well, Claude Code can shorten the path from alert to fix. Used carelessly, an agent with shell access can turn a bad incident into a much worse one. This guide covers how to bring Claude into a live incident without handing it the keys to production.
Why an agent helps in a Sev-1, and where it hurts
The hardest part of a severe incident is rarely the fix itself. It is the diagnosis under pressure: reading logs across a dozen services, correlating a deploy with an error spike, and holding the whole system in your head at 2am. This is exactly the kind of pattern-matching where Claude is strong. It can read a stack trace, cross-reference it against recent commits, and propose the two or three most likely causes faster than a tired human can.
The danger is that the same speed applies to mistakes. An agent that can restart a service can also restart the wrong one. Before you invite Claude into an incident channel, be clear about the split:
Claude is good at reading, correlating, and drafting: parsing logs, summarising what changed, and writing the fix as a diff for a human to approve.
Claude is dangerous when it acts directly on production: running migrations, killing processes, or editing live config without a human gate.
The reliable pattern is read-wide, write-narrow. Let the agent see a lot and change almost nothing on its own.
Set the guardrails before the pager goes off
Incident-time is not the moment to decide what an agent is allowed to touch. Those decisions belong in a calm afternoon, written down and tested. For regulated firms this is not optional. Under APRA CPS 230, an operational risk standard that applies to banks, insurers and superannuation trustees, you are expected to control and record who and what can change a critical system. An agent counts.
Read-only by default
Give Claude Code a role that can see production but cannot mutate it. In practice that means a read-only database replica, log access, and metrics, with no write credentials in the environment it runs in. If the agent needs to propose a change, it produces a diff or a command for a human to run, never the change itself.
A few settings make this concrete:
Run the agent against a read replica and observability tooling, not the primary write path.
Keep deploy, restart, and migration commands behind a human-approved step, so nothing ships without a person clicking go.
Log every command Claude suggests and every action a human takes on its advice, so the incident timeline reconstructs cleanly afterward.
Scrub secrets and customer records from anything you paste in, so a diagnosis does not become a notifiable data breach under the Privacy Act.
A calm runbook for using Claude Code mid-incident
When the alert fires, the goal is to move fast without acting rashly. A simple sequence keeps the agent useful and boxed in. First, brief Claude on the blast radius: which service, which customers, what the symptom looks like. Second, ask it to correlate the symptom against the last few deploys and config changes rather than guessing at root cause. Third, have it draft the smallest safe fix as a diff, with a short note on what could go wrong. A human reads that, decides, and runs it.
Concretely, a good incident prompt gives Claude the error, the recent commit list, and the affected service, then asks a narrow question: which of these changes most likely caused this, and what is the smallest reversible fix. You are asking for analysis and a proposal, not for the agent to reach into production and pull a lever.
The economics justify the discipline. For a mid-market retailer running online sales from Sydney or Melbourne, an hour of checkout downtime can cost more than $45,000 in lost orders and support load. Shaving fifteen minutes off diagnosis is real money. Causing a second outage because an agent ran an unreviewed migration can cost far more, and it erodes the trust that makes the tool worth using at all.
After the incident: the write-up almost writes itself
Once the fire is out, Claude earns its keep again. Feed it the incident channel transcript, the commands that were run, and the timestamps, and ask for a blameless post-incident review: timeline, contributing factors, and a short list of follow-up actions. It drafts in minutes what usually takes an engineer an hour, and it does not skip the boring parts. A human still owns the conclusions, but the first draft is on the page while the details are fresh.
The same transcript feeds your controls. If you operate under CPS 230 or hold Australian customer data, that clean timeline is the evidence your risk and compliance teams need, and it is far easier to produce when an agent has been logging alongside you the whole way.
Bringing an agent into a Sev-1 is about restraint as much as speed. Read wide, write narrow, keep a human on every production change, and log everything. Do that, and Claude becomes a fast, tireless second pair of eyes when you need them most. If you want help setting up these guardrails for your own stack, book a brainstorm with Automata AI and we will map it to your systems.
