PagerDuty integration

The PagerDuty integration posts to the Events API v2. A monitor going down triggers a PagerDuty incident; the same monitor recovering resolves it automatically, because both events carry the same dedup key.

What you need

An Integration Key (also called a routing key) from a PagerDuty service.

In PagerDuty, open the service you want Site Qwality to page.
Integrations → add an “Events API V2” integration.
Copy its Integration Key.

Connect it

In the dashboard, go to Manage → Integrations and click the PagerDuty card. Give it a name, paste the key into Integration Key (Events API v2), choose the Region of your PagerDuty account, and click Add integration.

Or through the API, with POST /integration/pagerduty:

curl -X POST https://api.siteqwality.com/integration/pagerduty \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "friendly_name": "Acme PagerDuty",
    "routing_key": "<events-api-v2-integration-key>",
    "region": "eu"
  }'

Field	Required	Description
`friendly_name`	yes	Up to 256 characters.
`routing_key`	yes	The Events API v2 integration key.
`region`	no	`us` (default) or `eu`.

The key is not validated against PagerDuty at save time, so a typo surfaces as a failed notification later. It never reads back in full; the region reads back as external_ref.region.

Region

PagerDuty keeps US and EU accounts apart, and a key only works in its own region. Choose the region of your PagerDuty account: EU accounts sign in at *.eu.pagerduty.com. US events go to events.pagerduty.com, EU events to events.eu.pagerduty.com. A key sent to the wrong region is refused by PagerDuty and recorded as rejected.

The region is set when you add the integration. To change it, add the integration again with the other region and move your channels to it. An integration with external_ref: null sends to US.

Add it to a notification group

Right after you add the integration, the dashboard offers to do this for you: choose a group or create one, choose which monitors alert that group (the ones that already do, every monitor, or ones you pick), then send a test. If you skipped it, Route alerts on the integration’s card opens the same step. To do it by hand:

Go to Respond → Notifications. Click a group’s name to open it, or click Add group to make a new one.
Under Notifications, click Add notification method. Set Notification type to PagerDuty and choose this integration under Integration.
Choose a Severity for the events this channel sends: Critical (the default), Error, Warning or Info.
Click Done editing, then Save changes (Create group for a new group).

Through the API, create the channel with POST /notification:

curl -X POST https://api.siteqwality.com/notification \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "notification_group_id": "<your-group-id>",
    "type": "pagerduty",
    "details": {
      "pagerduty_integration_id": "<pagerduty-integration-id>",
      "pagerduty_severity": "critical"
    }
  }'

Field	Required	Description
`pagerduty_integration_id`	yes	The integration UUID.
`pagerduty_severity`	no	`critical` (default), `error`, `warning`, or `info`.

Trigger and resolve

Every down/up pair shares one dedup key built from the monitor ID and the ID of the state transition that opened:

sq-http-<monitor-id>-<state-transition-id>
sq-browser-<browser-check-id>-<state-transition-id>

Monitor goes down → event_action: "trigger", summary Monitor DOWN: <name>, source set to the monitor URL, plus custom_details carrying the monitor, URL, and failure reason. For an uptime monitor, payload.custom_details.check.check_type is http, tcp or ping.
Monitor recovers → event_action: "resolve" with the same dedup key and nothing else. PagerDuty closes the incident it opened.

Because the key includes the state transition, a second outage of the same monitor opens a new PagerDuty incident rather than reopening the old one. Repeated triggers within one outage collapse onto the same incident.

Summaries longer than 1024 characters are truncated to fit the Events API limit.

An invalid certificate triggers at the channel’s severity under sq-tls-invalid-<tls-check-id>-<alert-id>, and its recovery resolves that key.

Expiry alerts do not auto-close

Domain and TLS certificate expiry warnings are trigger-only: they key on the check plus the expiry date (sq-dns-expiry-<job-id>-YYYY-MM-DD, sq-tls-expiry-<tls-check-id>-YYYY-MM-DD), so repeated warnings about the same date collapse into one PagerDuty incident, but nothing ever resolves it. Close those incidents in PagerDuty yourself. Renewing does not close them, and because renewal changes the expiry date, the next warning opens a new incident while the old one stays open. Expiry warnings always send at severity warning, ignoring the channel’s configured severity.

Delivery behavior

An event PagerDuty refuses is recorded as rejected and not retried. Other failures are retried, and if every attempt fails, the alert is dropped with no record in alert history, so pair PagerDuty with a second channel for anything you cannot afford to miss. See delivery guarantees.

Limitations

Page speed alerts do not reach PagerDuty. See the coverage table.
Incidents and escalation policies do not page through PagerDuty. The integration sends monitor and alert-rule events only.