Trigger PagerDuty Alerts Automatically for Incident Response

Failed pipelines that nobody notices turn into data downtime, broken SLAs, and angry stakeholders. This system blueprint wires Kestra straight into PagerDuty so that any workflow failure or warning across your instance automatically opens an incident, pages the right on-call engineer, and feeds your existing escalation policies. Instead of polling dashboards or scraping logs, you get real-time, structured incident alerting driven by execution events, with deduplication and routing handled by PagerDuty.

How it works

1. A system-level io.kestra.plugin.core.trigger.Flow trigger (on_failure) listens to executions across the whole instance.
2. A dependsOn entry filters what fires: states: [FAILED, WARNING] matches those executions, and its when: "{{ trigger.namespace startsWith 'company' }}" expression scopes alerting to the company namespace tree.
3. When a matching execution is detected, the create_pagerduty_alert task (io.kestra.plugin.pagerduty.PagerDutyExecution) posts an event to the PagerDuty Events API.
4. The event carries a payloadSummary enriched with {{ trigger.executionId }} and {{ taskrun.startDate }}, an eventAction of trigger, plus a deduplicationKey and routingKey so PagerDuty groups duplicates and routes to the correct service.

What you get

• Hands-off incident creation the moment a workflow fails or warns.
• One alerting flow that covers every workflow in a namespace prefix, not per-pipeline wiring.
• Execution metadata (ID, start date) embedded in the alert summary for faster triage.
• Deduplication and routing handled natively by PagerDuty.

Who it's for

• SRE and reliability engineers who own on-call rotations.
• Platform and data-platform teams running shared Kestra instances.
• Operations teams that already standardize on PagerDuty for escalation.

Why orchestrate this with Kestra

PagerDuty reacts to events but does not know when your pipelines fail. Kestra closes that gap. The event-driven Flow trigger fires on real execution status, no cron polling required. Declarative YAML keeps the alerting rule versioned and reviewable, retries and execution lineage stay visible in the Kestra UI, and a single system flow centralizes alerting policy instead of scattering notification logic across hundreds of individual workflows.

Prerequisites

• A Kestra instance with the PagerDuty plugin available.
• A PagerDuty account with an Events API v2 integration on the target service.

Secrets

• PAGERDUTY_EVENT: the PagerDuty Events API v2 integration URL used by the url property.

Quick start

1. Create the PAGERDUTY_EVENT secret with your PagerDuty Events API integration URL.
2. Replace dedupkey and routingkey with the real deduplication and routing keys for your service.
3. Adjust the when expression's namespace prefix to match the namespaces you want to monitor.
4. Save the flow, then trigger a failing test workflow and confirm an incident appears in PagerDuty.

How to extend

• Add more states values or a when expression checking trigger.labels to narrow which failures page.
• Chain a Slack or email notification task alongside the PagerDuty call for redundant channels.
• Set eventAction to resolve in a companion flow on SUCCESS to auto-close incidents.
• Enrich payloadSummary with flow ID, namespace, or attempt count for richer triage context.

Links

• PagerDuty plugin documentation