PagerDuty Integration

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": { ... } }
  }
}

FAQ

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.

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

PagerDuty integration — page once per outage