Before we get into the specifics, a note on how Parachute fits into an existing alerting stack. Parachute does not replace PagerDuty, Opsgenie, or Datadog. Those tools are responsible for detecting the signal and notifying the on-call. Parachute is responsible for what happens between the alert firing and the on-call opening their terminal: the automated runbook execution, evidence collection, and initial containment steps.
The three integrations below are the ones teams ask about most when evaluating Parachute. Each works slightly differently in terms of how alert metadata flows into Parachute, which affects what your runbooks can do automatically.
PagerDuty
The PagerDuty integration uses PagerDuty's webhook v3 API. When an incident is triggered in PagerDuty, PagerDuty sends a incident.triggered event payload to your Parachute webhook endpoint. Parachute parses the payload and matches it against your runbook trigger conditions.
The key fields Parachute extracts from PagerDuty payloads are the incident severity, the service name (which maps to the affected system in most PagerDuty configurations), and the alert body, which typically contains the raw monitoring data that caused the incident to be triggered.
The practical limitation of the PagerDuty integration is that the richness of data available to Parachute depends on what PagerDuty received from your monitoring tools. If your PagerDuty service is configured to receive events from a SIEM and those events include host identifiers, Parachute can extract those identifiers and use them in runbook actions (for example, to identify which EC2 instance to isolate). If the alert body is minimal, Parachute may need to query CloudTrail or your asset inventory to fill in the gaps.
Setup involves three steps: creating a webhook subscription in your PagerDuty account pointing to your Parachute webhook URL, configuring the event types you want forwarded (typically incident.triggered and optionally incident.escalated), and adding the PagerDuty webhook signature secret to your Parachute workspace settings so that Parachute can verify that incoming events are genuine. The full setup walkthrough is in the Parachute quickstart docs.
What Parachute can do immediately on a PagerDuty trigger
With a well-structured PagerDuty payload, Parachute can begin host isolation, pull logs for the relevant asset, and post an initial summary to Slack before the on-call has acknowledged the PagerDuty incident. The timeline: PagerDuty fires, Parachute receives the webhook within one to two seconds, runbook execution begins. If the runbook's first action is host isolation and the EC2 instance identifier is present in the payload, the isolation API call goes out immediately.
Opsgenie
The Opsgenie integration works on a similar principle but uses Opsgenie's integration webhooks, which can be configured at the team level. When an alert is created in Opsgenie, Parachute receives a webhook with the alert details including message, alias, description, and any tags or extra properties you have configured on the alert.
One thing that makes Opsgenie useful here: Opsgenie's alert model supports rich custom property fields. Teams that route alerts through Opsgenie often attach structured metadata (instance ID, environment, region, affected service tier) as alert properties. Those properties flow through to Parachute and are available as variables in your runbook actions. If your Opsgenie alert includes a property called affected_instance_id, your runbook can reference {{ alert.properties.affected_instance_id }} directly in the isolation step.
This makes the Opsgenie integration particularly well-suited to teams that have already invested in enriching their alert metadata. The enrichment work you did to make Opsgenie dashboards more useful also makes Parachute runbooks more precise.
Routing by team in Opsgenie
If your Opsgenie setup has multiple teams with different alerting responsibilities, Parachute supports team-scoped runbook triggers. You can configure a runbook to only execute when an alert is routed to the security team's Opsgenie schedule, rather than triggering on all Opsgenie alerts across the organisation. This is important for teams where Parachute should only act on security-relevant alerts, not on application performance or infrastructure alerts that happen to come through the same Opsgenie instance.
Datadog
The Datadog integration is the most direct of the three, in the sense that Datadog is often both the monitoring layer and the alerting layer. Many security teams using Datadog for their SIEM-adjacent logging and correlation work will have Datadog monitors set up for the security-relevant signals, and those monitors can fire directly to Parachute via Datadog's webhook notification channel.
When you configure a Datadog monitor to send webhook notifications to Parachute, the payload includes the monitor name, the triggering condition, the affected host or service (from Datadog's tagging system), and the full alert message body including any @mentions or custom variables you have included in the monitor notification template.
The Datadog-specific advantage is that if your monitors are built on Datadog's log analytics, the monitor notification can include inline log data as part of the alert body. Parachute can parse structured log excerpts from the alert payload and include them in the initial evidence package, before making any additional API calls.
Datadog as a trigger vs Datadog as an evidence source
There is an important distinction in how Parachute uses Datadog in more advanced configurations. Datadog can function as the trigger source (the monitor fires, Parachute receives the webhook) and separately as an evidence source (Parachute queries the Datadog Logs API to pull additional log context for the affected host during runbook execution). These are two separate integration paths and both can be active simultaneously.
When Parachute is configured to query Datadog logs during runbook execution, it performs a targeted search for the affected host's logs in the relevant time window, extracts the pertinent events, and includes them in the evidence package. This is particularly useful when the initial alert payload from Datadog does not contain all the log context needed for the investigation.
Choosing between them for your first setup
If your team is already on PagerDuty and you are routing all security alerts through it, start with the PagerDuty integration. The setup is straightforward and it gives Parachute visibility into all your P1 and P2 incidents regardless of which monitoring tool generated the underlying signal.
If your team does its detection work primarily in Datadog and you are comfortable with Datadog's monitor notification system, the Datadog integration gives you the most direct path from detection to automated response, without an intermediate alerting tool in the loop.
Opsgenie is the right starting point if your team has invested heavily in alert metadata enrichment. The richer your Opsgenie alert properties, the more precise your Parachute runbook actions can be from the first step.
All three integrations can run simultaneously in the same Parachute workspace. Teams with overlapping alerting stacks often configure Parachute to accept from all three, with runbook routing rules that ensure each alert type gets the appropriate response regardless of which tool it came through.
