Skip to main content

PagerDuty

InfraSage pages through the PagerDuty Events API v2: high-severity alerts trigger incidents on your service, PagerDuty's escalation policies take it from there, and InfraSage auto-resolves the page when the underlying alert resolves.

Configuration​

One environment variable on the engine:

PAGERDUTY_ROUTING_KEY=<your Events API v2 integration key>

Create the key in PagerDuty under Service → Integrations → Events API v2. When the variable is unset, there is no PagerDuty channel and nothing else about the engine changes.

Optionally tune the paging floor (default high):

PAGER_MIN_SEVERITY=high   # low | medium | high | critical

Only alerts at or above this severity page. This is deliberate: InfraSage's severity calibration scales alert tiers with signal strength, so high genuinely means high. Weak, uncorroborated signals land at low/medium, where they reach your dashboards and Slack instead of your phone.

What gets sent​

A triggered event carries the alert's identity and evidence:

  • summary: [severity] service — message
  • severity: mapped to PagerDuty's scale (critical→critical, high→error, medium→warning)
  • dedup_key: the alert's service:severity fingerprint, so InfraSage-side dedup and PagerDuty-side dedup agree. Repeat fires of the same incident update the same PagerDuty incident instead of re-paging.
  • custom_details: evidence lines, recommended actions, z-score, and the causal incident id
  • links: a deep link to the InfraSage incident room when available

Resolution​

When the alert resolves in InfraSage, whether by an operator, a runbook, or auto-resolution, InfraSage sends a resolve event for the same dedup key and the PagerDuty incident closes on its own.

Escalation, schedules, overrides​

All owned by PagerDuty. InfraSage's job ends at delivering a well-calibrated event to the right service; your escalation policies decide who wakes up.