We spent several years running incident response for security teams before we wrote a line of Parachute. And across that time, across different companies and different stacks and different threat profiles, the same problem kept appearing in a form we could almost predict before we saw it.
The tooling was there. PagerDuty to page the on-call. Datadog or a SIEM for detection. An EDR for endpoint visibility. A Confluence space full of runbooks. And yet, when an alert fired, every team we worked with spent the first 15 to 25 minutes doing manually what should have been automatic: pulling logs, isolating hosts, gathering context, figuring out where the incident started. The tools each did their job in isolation. There was nothing that connected them when it actually mattered.
The Problem Is Not the Tools
We want to be precise about this because the easy interpretation is that the tools are inadequate. They are not. PagerDuty pages people reliably. Datadog detects anomalies well. EDR platforms catch endpoint activity that would have been invisible a decade ago. The monitoring and detection layer for well-resourced teams is genuinely good now.
The gap is the execution layer between detection and response. The alert fires. The on-call engineer wakes up. And then a human has to do, by hand, a set of steps that do not require human judgment. Check which host. Pull the last 4 hours of CloudTrail for that host. Quarantine the instance. Post to the incident Slack channel. Start the timeline. Every one of these steps is procedural, deterministic, and time-sensitive. Every one of them takes minutes to do manually when the window for limiting blast radius is measured in seconds.
Lean security teams feel this more acutely than large ones. A team of four covering a 400-person company does not have the redundancy that a larger SOC does. The on-call engineer who wakes up at 2am is probably also the analyst who will be doing the post-mortem at 9am. The cognitive cost of a slow, manual response compounds in ways that are hard to measure but very visible to the people experiencing it.
What We Built
Parachute is the automated execution layer that runs between the alert and the engineer.
When an alert fires from PagerDuty, Opsgenie, or Datadog, or from a direct webhook, Parachute matches it to a configured runbook. The runbook executes automatically: isolating the relevant host via the cloud provider API, pulling CloudTrail logs or SIEM queries, capturing a process list from the affected endpoint if available, and drafting a structured incident timeline. By the time the on-call engineer opens their laptop, the first-response work is done and the evidence is packaged and waiting for them.
The runbooks are defined in YAML and stored in version control. They are not a black box: every step the system takes is logged with a timestamp, and the original state of anything that was modified is recorded so it can be restored. An engineer can read exactly what Parachute did, in what order, and why. The automation is auditable.
Who We Built It For
Parachute is built for lean security teams: three to ten people covering a company whose risk profile requires a real security program but who cannot staff a large SOC. The companies that ask questions like "how do we make our on-call less punishing without hiring a night shift analyst?"
We are not trying to solve automated threat hunting or continuous monitoring or red team simulation. Those are real problems and there are good tools for them. We are solving a specific and common pain point: the manual execution gap between a detection firing and a human being ready to apply judgment. That gap is where most incidents go sideways for lean teams, and it is the gap Parachute fills.
This is also not a tool for teams who do not have runbooks yet. Parachute executes runbooks. If you have not gone through the work of encoding your incident response procedures, that work comes first. What Parachute does is take procedures you have already thought through and runs them faster and more consistently than a human under stress can. The quality of the runbooks you put in determines the quality of the response you get out.
Where We Are Today
Parachute is live and available for teams to use now. We have built integrations for PagerDuty, Opsgenie, and Datadog on the alert intake side, and AWS EC2 and security group management on the containment side. Slack is the default notification and incident channel. The docs are at withparachute.org/docs and there is a free tier for teams who want to try it before committing.
We are a small team in Sydney. We built this because we needed it, and because the teams we spoke with told us they needed it. If your security team is carrying on-call weight that feels heavier than the incidents actually justify, we would like to show you what a configured Parachute runbook looks like in practice.
You can start for free at withparachute.org/login/register.html. If you want to talk through your specific incident response setup before trying it, reach us at [email protected].
