The conversation around automation in incident response often gets framed as a replacement question: will this replace the on-call engineer? That framing is wrong in a way that matters practically, because it leads teams to evaluate automation against the wrong success criteria.
Automation in incident response does not replace judgment. It replaces procedure. And the distinction has real implications for what you should and should not automate, and what quality bar those automations need to meet.
What On-Call Engineers Actually Spend Time On
When an alert fires at 2am, a well-functioning on-call rotation looks something like this: the engineer wakes up, acknowledges the alert, opens the relevant runbook or recall from memory the applicable playbook, begins gathering context from the relevant systems, and eventually forms a hypothesis about what is happening and what to do about it. Then they act on it.
The cognitive work, the part that requires a trained human, is the hypothesis formation and the judgment about what action is appropriate given incomplete information. That typically starts no earlier than the 10 to 15 minute mark of a response.
Everything before that point is procedure. Log in to the relevant console. Pull the relevant logs. Run the containment steps in order. Notify the relevant people. None of those steps require judgment. They require execution accuracy and speed.
The on-call engineer is doing that procedural work because there is no system that does it automatically. Not because that procedural work benefits from human involvement. The engineer's skills are idle during the gathering phase, waiting until there is something to think about.
The Cognitive Budget Problem
Human cognitive performance under stress is not linear. An engineer who has spent 20 minutes on procedural information-gathering at 2am, under the anxiety of an unknown incident, arrives at the judgment phase with less cognitive capacity than one who woke up to a structured evidence package already assembled.
This is not a small effect. Sleep-interrupted cognition is measurably impaired even in professional contexts. The 20-minute procedural phase does not just waste time. It consumes cognitive resources that the engineer needs for the actual diagnostic work.
When Parachute runs the procedural steps automatically, the engineer's cognitive entry point to the incident is different. They open Slack and see: host isolated, CloudTrail pulled, three suspicious AssumeRole calls flagged from an external IP, isolation confirmed at 02:14:23. They start at context, not at procedure. The cognitive investment required to get to a useful hypothesis is substantially lower because the hypothesis-forming evidence is already in front of them.
What You Should Not Automate
There are response actions that should not be automated even when technically possible, and being clear about this is part of building justified confidence in the automation you do run.
Do not automate irreversible actions without explicit confirmation gates. Terminating an EC2 instance, deleting a user account, or revoking all tokens for a service are actions that cannot be undone quickly if they turn out to be the wrong call. An automated runbook that isolates a host is running a reversible action. One that terminates the instance and purges the EBS volume is not.
Do not automate actions whose correctness depends on information that is not available in the alert payload. If the right containment action depends on whether the affected host is production or staging, and that information is not reliably in the alert metadata, the automation will get it wrong sometimes. Human judgment in that gap is not a failure of automation; it is the right allocation of roles.
Do not automate escalation decisions. Whether to wake up a second engineer, whether to notify customers, whether to engage a third-party incident response firm, these are judgment calls that require context the automated system does not have. Automation can gather the evidence that informs those decisions. It should not make them.
The Skills Question
A concern some teams raise: if automation handles the procedural steps, do engineers lose the procedural skills over time, and does that matter?
It is a real concern but it cuts in the opposite direction from how it is usually framed. The procedural skills in incident response, running the right CLI commands, knowing which logs to pull first, are not the scarce resource on a lean security team. The scarce resource is diagnostic judgment: the ability to look at a structured evidence set and form an accurate hypothesis about attacker behavior quickly.
Engineers who spend their on-call time on gathering and procedure are not developing diagnostic judgment. They are maintaining procedural muscle memory. Automation that frees them from the procedure allows more time spent on the harder skill, which is the one that matters more for team capability over time.
This is also why we think the quality bar for automated runbooks needs to be high. If the runbook executes incorrectly and the engineer cannot easily identify what the automated system did and why, the automation creates confusion at the exact moment when clarity is most important. The engineer now has to debug the automation while also investigating the incident. Automation that is hard to audit is worse than no automation.
What Good Automation Hands Off
The handoff point from automation to engineer is not a blank slate. It is a structured package. What that package looks like determines how useful the automation actually is in practice.
A Parachute incident record after a runbook execution contains: a timestamped action log showing exactly what the automation did and in what order; the original state of anything that was modified (security groups, network ACLs, IAM policies), so the engineer understands the delta; the raw evidence collected (CloudTrail events, VPC flow log excerpts, process list if available); and any automated flags where the evidence matched a known pattern worth highlighting.
The engineer reads this, understands where the automation stopped, and picks up from there. The automation did not make a diagnosis. It created the conditions for the engineer to make a diagnosis faster, with better information, with less of their cognitive budget spent on setup.
That is the right division of labor. Procedure to the machine. Judgment to the person.
