Native PagerDuty channel

Turn a failed check into a PagerDuty incident, automatically.

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.

PDPagerDuty
Triggered

Checkout API is DOWN

Service: Production Web / High urgency

Monitor
api.acme.io/checkout
Response
503 Service Unavailable
Failed checks
3 in a row
From
London, Frankfurt
Auto-resolves when the monitor passes again
Sent by PulseStack via Events API v2

8

native alert channels, PagerDuty included

8

monitor types can page you

v2

PagerDuty Events API, spoken natively

0

middleware hops for PagerDuty

Why native matters

A direct line to your on-call rota

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 the instant a monitor trips its threshold.

Trigger on failure

A monitor that fails past its consecutive-failure threshold opens a PagerDuty incident on the service you chose.

Resolve on recovery

When the monitor passes again, PulseStack sends a resolve event on the same dedup key and the incident closes itself.

Your rules apply

PagerDuty escalation policies, urgency and rotations stay in charge. PulseStack simply supplies the signal.

Setup

Connect PagerDuty in four steps

The whole thing takes a couple of minutes. You need one integration key from PagerDuty and one monitor in PulseStack.

  1. 01

    Add the integration in PagerDuty

    On the PagerDuty service you want to page, add an integration of type Events API v2 and copy the integration key it generates.

  2. 02

    Paste the key into PulseStack

    In PulseStack, add a PagerDuty alert channel and paste the Events API v2 routing key. Give it a name you will recognise.

  3. 03

    Attach it to your monitors

    Pick the monitors that should page. Attach the PagerDuty channel individually or in bulk from the monitor list.

  4. 04

    Set the threshold and test

    Choose how many consecutive failures should trigger, fire a test alert and watch the incident appear in PagerDuty.

Inside the incident

Every incident lands with context

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.

  • Which monitor failed and the URL or host it checks
  • The HTTP status code or failure reason that was observed
  • How many consecutive checks failed before triggering
  • The checking locations that saw the failure
  • A severity value carried in the Events API v2 payload
  • A stable dedup key so recovery resolves the same incident
Events API v2 payload
{
  "routing_key": "R0ABCDE...",
  "event_action": "trigger",
  "dedup_key": "pulsestack-mon-8842",
  "payload": {
    "summary": "Checkout API is DOWN (503)",
    "source": "api.acme.io/checkout",
    "severity": "critical",
    "component": "HTTP monitor",
    "custom_details": {
      "monitor": "Checkout API",
      "status_code": 503,
      "failed_checks": 3,
      "locations": ["London", "Frankfurt"]
    }
  }
}
On recovery PulseStack reuses the dedup key with event_action: resolve.

Lifecycle

From down to resolved without a human touching PagerDuty

Stage 1

Failure detected

A monitor fails its checks from one or more locations. PulseStack counts consecutive failures against your threshold.

Stage 2

Incident triggered

Once the threshold is met, a trigger event opens a PagerDuty incident and your escalation policy starts paging.

Stage 3

Incident resolved

The monitor passes again, a resolve event fires on the same dedup key and the incident closes on its own.

Everything included

What you get with the PagerDuty channel

Native Events API v2 integration, no third-party bridge
Automatic incident trigger on monitor failure
Automatic incident resolve on monitor recovery
Stable dedup keys so incidents never duplicate
Per-monitor consecutive-failure thresholds
Multiple PagerDuty services via separate routing keys
Works across all eight monitor types
Severity carried in the event payload
Multi-location checks so a single region blip is filtered out
Test alerts to validate routing before an outage
Runs server side, no open tab or agent required
Sits alongside the other seven native channels

Eight native channels

PagerDuty is one of eight, all native

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.

The SMS and voice add-on is available on the Team and Enterprise plans.

Monitor types

Any of these eight can page PagerDuty

PagerDuty is not limited to website checks. Attach it to whichever monitor type matters, from DNS drift to a silent cron job.

HTTP / website

Status codes, response time and content on every page and endpoint.

Keyword

Alert when expected text vanishes or an error string appears.

TCP Ping

Reachability checks for any host from multiple locations.

Port

Confirm the exact service port is open and answering.

API

Multi-step checks with headers, bodies and assertions.

Heartbeat

Catch silent cron and background jobs that stop reporting in.

DNS

Watch records for drift, hijack and propagation failures.

Domain Expiry

Advance warning before a domain lapses and takes you offline.

Use cases

Where teams point PulseStack at PagerDuty

Production on-call

Critical HTTP and API monitors page the primary rota with high urgency, while lower-stakes checks route to a separate, quieter service.

Silent job detection

Heartbeat monitors trigger a PagerDuty incident when a nightly batch job stops checking in, catching failures that never throw an error.

Certificate and domain hygiene

SSL and domain-expiry warnings become scheduled incidents so a lapse is handled during working hours, not discovered as an outage.

DNS and infrastructure drift

DNS and port monitors page the platform team the moment a record changes or a service port stops answering.

Multi-region confidence

Multi-location checks mean a genuine outage pages you, but a single flaky region does not, keeping trust in the alert.

Staging and production split

Separate routing keys send staging noise to one service and production incidents to another, so on-call stays focused.

Plans

PagerDuty from Starter upward

The Free plan runs five HTTP monitors with email alerts. Every paid plan unlocks all eight native channels, including PagerDuty, and all eight monitor types.

Free

Free

5 monitors, HTTP only, 5-min checks, email alerts, no card.

Starter

£15/mo

10 monitors, 60s checks, all channels and all monitor types.

Pro

£39/mo

50 monitors, plus SSL, DNS and domain insights.

Team

£79/mo

100 monitors, server diagnostics, three seats.

Enterprise

£149/mo

200 monitors, 30s checks, five seats.

All paid plans come with a 14-day trial.

FAQ

PagerDuty integration questions

How does PulseStack connect to PagerDuty?

PagerDuty is a native alert channel in PulseStack, built on the PagerDuty Events API v2. You create a service in PagerDuty, copy its integration key, and paste that key into a PagerDuty alert in PulseStack. No OAuth flow or extra tooling is required.

What happens when a monitor fails?

When a monitor crosses your configured consecutive-failure threshold, PulseStack sends a trigger event to PagerDuty, which opens an incident and routes it through your escalation policy so the right on-call engineer is paged.

Do incidents resolve automatically on recovery?

Yes. As soon as the monitor passes again, PulseStack sends a resolve event for that incident and PagerDuty marks it resolved, keeping your incident timeline and MTTR metrics accurate without manual clean-up.

Which plans include the PagerDuty channel?

PagerDuty is one of eight native alert channels available on PulseStack's paid plans, which start at £15 per month. Every paid plan comes with a 14-day trial, and the free plan covers five monitors with email-based HTTP checks.

Can I use PagerDuty alongside other alert channels?

Yes. Alerts are configured per channel, so you can send the same monitor to PagerDuty plus any of the other native channels - Email, SMS, Slack, Microsoft Teams, Discord, Telegram and Webhooks - at the same time.

Will a brief blip page my team?

No. Alerts only fire after a configurable consecutive-failure threshold, so a momentary wobble never opens a PagerDuty incident. You control how many failed checks are needed before an incident is triggered.

Let a failed check page the right person

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.