Native PagerDuty channel
PulseStack speaks the PagerDuty Events API v2 natively. A monitor going down opens an incident on the right service. The moment it recovers, the same incident resolves itself. Your on-call rota does the rest.
14-day trial. Eight native alert channels. No Zapier hop for PagerDuty.
Checkout API is DOWN: Down from 2/3 locations: London, New York
Service: Production Web (example)
8
native alert channels, PagerDuty included
9
monitor types can page you
v2
PagerDuty Events API, spoken natively
0
middleware hops for PagerDuty
Why native matters
Plenty of tools claim PagerDuty support by routing you through a generic webhook or a third-party automation platform. That adds a moving part between your outage and the person who can fix it. PulseStack talks to PagerDuty directly through the Events API v2, so an incident is created as soon as a monitor is confirmed down.
A monitor that is confirmed down from at least two locations opens a PagerDuty incident on the service you chose.
When the monitor passes again, PulseStack sends a resolve event on the same dedup key and the incident closes itself.
PagerDuty escalation policies, urgency and rotations stay in charge. PulseStack simply supplies the signal.
Setup
The whole thing takes a couple of minutes. You need one integration key from PagerDuty and one monitor in PulseStack.
On the PagerDuty service you want to page, open Integrations, add an integration of type Events API v2 and copy the 32-character integration key it generates.
Open Alert Contacts, click Add contact, choose PagerDuty and paste the key into Integration key. Give it a label you will recognise.
Tick the PagerDuty contact under Notify on failure on each monitor that should page. A monitor with nothing ticked alerts every contact.
Click Send test. PagerDuty opens a test incident at info severity with no dedup key, so resolve it by hand. Real incidents trigger once a failure is confirmed and resolve themselves.
Inside the incident
A page at 3am is only useful if it tells the engineer what broke. PulseStack fills the PagerDuty event with the detail your responder needs before they have even opened a laptop.
POST https://events.pagerduty.com/v2/enqueue
{
"routing_key": "<your 32-character integration key>",
"event_action": "trigger",
"dedup_key": "pulsestack-<monitor id>",
"payload": {
"summary": "Checkout API is DOWN: Down from 2/3 locations: London, New York",
"severity": "critical",
"source": "PulseStack™",
"component": "Checkout API",
"custom_details": {
"monitor_url": "https://api.acme.io/checkout",
"monitor_type": "HTTP",
"error_message": "Down from 2/3 locations: London, New York",
"down_duration": null,
"locations": [
{ "location": "London", "code": "LHR", "status": "DOWN", "response_ms": 412, "status_code": 503 },
{ "location": "New York", "code": "NYC", "status": "DOWN", "response_ms": 388, "status_code": 503 },
{ "location": "Sydney", "code": "SYD", "status": "UP", "response_ms": 291, "status_code": 200 }
]
}
}
}Lifecycle
A check fails. Website, keyword, API, ping and port monitors compare the latest results from London, New York and Sydney; SSL, DNS, domain expiry and heartbeat checks are re-tested 3 seconds later.
Once at least two locations confirm the failure, or the re-test fails too, a trigger event opens a PagerDuty incident and your escalation policy starts paging.
The monitor passes again, a resolve event fires on the same dedup key and the incident closes on its own.
Everything included
Eight native channels
Route alerts wherever your team already works. Zapier and Google Chat are not on this list because they connect through the Webhook channel rather than natively.
SMS alerts are included on the Team and Enterprise plans. See all integrations.
Monitor types
PagerDuty is not limited to website checks. Attach it to whichever monitor type matters, from DNS drift to a silent cron job.
Status codes, response time and content on every page and endpoint.
Alert when expected text vanishes or an error string appears.
TCP connection checks to any host and port.
Confirm the exact service port is open and answering.
Requests with your own method, headers and body, checked for the expected status.
Catch silent cron and background jobs that stop reporting in.
Advance warning before a certificate expires (7 days by default), and an incident if it is not trusted.
Alert when a record stops matching the value you expect.
Advance warning before a domain registration lapses (7 days by default).
Use cases
Critical HTTP and API monitors page the primary rota with high urgency, while lower-stakes checks route to a separate, quieter service.
Heartbeat monitors trigger a PagerDuty incident when a nightly batch job stops checking in, catching failures that never throw an error.
SSL certificate and domain expiry monitors open an incident a set number of days before a lapse (7 by default), so renewal is handled in working hours, not discovered as an outage.
DNS and port monitors page the platform team when a record no longer matches its expected value or a service port stops answering.
Multi-location checks mean a genuine outage pages you, but a single flaky region does not, keeping trust in the alert.
Separate routing keys send staging noise to one service and production incidents to another, so on-call stays focused.
Plans
The Free plan runs 5 HTTP monitors with email alerts. Every paid plan unlocks PagerDuty and all nine monitor types, with SMS alerts included on Team and Enterprise.
Free
5 monitors, HTTP only, 5-min checks, email alerts, no card.
£9/mo
50 monitors, 60s checks, PagerDuty and all monitor types, plus SSL, DNS and domain insights.
£19/mo
150 monitors, 30s checks, plus competitor tracking.
£39/mo
500 monitors, server diagnostics, three seats, SMS included.
£99/mo
2,000 monitors, five seats, SMS included.
All paid plans come with a 14-day trial.
Troubleshooting
Start with Send test next to the contact on the Alert Contacts page. It sends a trigger event straight away, and if PagerDuty refuses it the error shows the status code PagerDuty returned.
PulseStack™ needs the 32-character integration key from an Events API v2 integration on a service, and the form rejects anything that is not 32 hexadecimal characters. A REST API key or user token will not work, and nor will an Event Orchestration routing key (those begin with R0).
If the PagerDuty service is disabled or inside a PagerDuty maintenance window, PagerDuty does not open incidents for it. Check the service's status in PagerDuty.
That is expected. The test event has no dedup key, so PulseStack™ never sends a resolve for it; resolve it in PagerDuty. Real alerts use the dedup key pulsestack- plus the monitor's ID and resolve on recovery.
If a monitor has any contacts ticked under Notify on failure, only those are alerted. Tick the PagerDuty contact, or untick everything so the monitor alerts every contact.
Events are sent when a monitor goes down or recovers, once each and without retries, so a monitor that was already down when you added the key opens nothing until it recovers and fails again. If an incident looks wrong, see why a monitor status can be wrong.
FAQ
PagerDuty is a native alert channel in PulseStack™, built on the PagerDuty Events API v2. On a PagerDuty service, add an Events API v2 integration and copy its 32-character integration key, then add the key in PulseStack™ under Alert Contacts as a PagerDuty contact. No OAuth flow or extra tooling is required.
When a monitor is confirmed down, PulseStack™ sends a trigger event with severity critical and a dedup key made from the monitor's ID. PagerDuty opens an incident on that service and your escalation policy decides who is paged. HTTP, keyword, API, ping and port monitors count as down when two of the three locations fail; SSL, DNS, domain expiry and heartbeat checks must also fail a re-test 3 seconds later.
Yes. As soon as the monitor passes again, PulseStack™ sends a resolve event with the same dedup key and PagerDuty resolves the incident, keeping your incident timeline and MTTR metrics accurate without manual clean-up. The Send test alert has no dedup key, so resolve that one by hand.
PagerDuty is one of eight native alert channels available on PulseStack's paid plans, which start at GBP 9 per month. Every paid plan comes with a 14-day trial, and the free plan covers 5 monitors with HTTP checks and email alerts.
Yes. Tick as many contacts as you like on a monitor, so the same alert goes to PagerDuty and to any of the other native channels (Email, SMS, Slack, Microsoft Teams, Discord, Telegram and Webhooks) at the same time.
It should not. A failed check is re-tested a few seconds later, and a monitor is only marked down when at least two of its three check locations (London, New York and Sydney) fail, so a momentary wobble does not open a PagerDuty incident.
Wire PulseStack into PagerDuty in minutes and stop finding out about outages from your customers. Start free, then keep the channel on any paid plan.