PagerDuty Integration: Page Once Per Outage

Saneops connects to PagerDuty in two directions. Inbound: ingest alerts that PagerDuty receives so Saneops can correlate and deduplicate them. Outbound: page PagerDuty only when a Saneops incident reaches a severity threshold — turning PagerDuty back into the high-signal pager it was meant to be.

Two integration patterns

Pattern A — PagerDuty as a destination (most common)

Keep PagerDuty as your on-call rotation engine. Route Grafana, Datadog, Prometheus etc. into Saneops first; Saneops correlates them into incidents and only pages PagerDuty for severity ≥ critical (or whatever rule you define). Your on-call rotation stays exactly as it is — they just get woken less.

Configure: Integrations → PagerDuty → Connect in Saneops, paste your PagerDuty Events API v2 routing key, set the severity floor.

Pattern B — PagerDuty as a source

If you have legacy alerting tools that already POST to PagerDuty, point a PagerDuty webhook extension at Saneops so we ingest the same events. Saneops will still correlate and deduplicate downstream of PagerDuty — useful while you migrate sources off PagerDuty's ingestion path.

Configure: in PagerDuty, Service → Integrations → Webhooks v3. Paste the Saneops inbound URL: https://app.saneops.in/webhooks/pagerduty/<your-token>.

How Saneops reduces PagerDuty page volume

Correlation: 30 alerts about a flapping Postgres replica become 1 Saneops incident. PagerDuty gets paged once, not 30 times.
Severity gating: Saneops decides what reaches PagerDuty based on severity, business hours, on-call capacity, or any CEL expression you write.
Auto-resolve: When the underlying issue clears, Saneops closes its incident and sends PagerDuty a resolve event — no manual resolve clicking.
Maintenance windows: Saneops's silencing UI suppresses PagerDuty pages during planned changes without touching PagerDuty's own maintenance system.
Workflow runbooks: Auto-ack low severity, auto-page critical, auto-comment on the PagerDuty incident with the LLM-drafted RCA — all configurable per workflow.

Outbound configuration — Events API v2

Saneops sends to PagerDuty's Events API v2 (the modern endpoint). Required field: routing key (32-char hex string from your PagerDuty service's Integrations tab). Optional: a custom event class, severity override, dedup key derivation rule.

# Example PagerDuty event Saneops sends on incident open:
{
  "routing_key": "REDACTED",
  "event_action": "trigger",
  "dedup_key": "saneops:incident:abc-123",
  "payload": {
    "summary": "Postgres replica unreachable — 12 services degraded",
    "source": "saneops",
    "severity": "critical",
    "component": "postgres-primary",
    "custom_details": { "alert_count": 12, "common_labels": { ... } }
  }
}

PagerDuty® is a registered trademark of PagerDuty, Inc. This page is independently produced by Saneops and does not imply endorsement.

Frequently asked questions

Do I keep paying PagerDuty?

Yes — PagerDuty's value is the on-call rotation, escalation policy, and mobile pager experience. Saneops doesn't replicate that. Saneops's job is to make sure PagerDuty pages you 5 times a week instead of 50.

Can I migrate off PagerDuty later?

Yes. Saneops's outbound abstraction supports OpsGenie, Zenduty, Slack, Teams, email, and generic webhook. If you decide to drop PagerDuty, swap the destination in the channel config — your incident logic doesn't change.

How does the dedup_key work?

Saneops derives a stable dedup key per incident (saneops:incident:<uuid>). When Saneops re-emits for the same incident, PagerDuty sees the dedup key match and consolidates updates rather than opening a new PagerDuty incident.

Does Saneops support PagerDuty business services?

Yes. The Events API v2 payload includes the component and group fields, which PagerDuty maps to its service hierarchy. Your existing service routing rules continue to apply.

Is the migration reversible?

Yes — in minutes. Repoint your monitor webhooks back to PagerDuty's direct routing key. Saneops doesn't hold any state PagerDuty needs.

PagerDuty integration — page once per outage