Email and Slack alerts are fine during the workday. At 3 AM they're a notification nobody sees until morning. PagerDuty exists for the other case: a phone call to whoever is on call, escalation to the next person if they don't acknowledge, and a schedule so it isn't always the same person. CronAlert has a native PagerDuty channel that plugs into that. Setup is one integration key, and it's on the Pro plan at $5 per month.

This guide covers creating the PagerDuty side, adding the channel in CronAlert, what the resulting incident looks like, how deduplication and auto-resolve behave, and how to pair PagerDuty with Slack and maintenance windows so the on-call person is woken up for the right things. If you're deciding between PagerDuty, SMS, and push as your wake-up channel, SMS and phone-call alerts compares them with costs.

How it works

CronAlert checks your monitors on schedule. When one fails, CronAlert sends a trigger event to PagerDuty's Events API v2 for the service you connected, with a summary like "Checkout API is down," severity critical, and the URL, status code, error message, and check region as custom details. PagerDuty opens an incident and runs the service's escalation policy: push, SMS, phone call, next person, according to each responder's notification rules. When the monitor recovers, CronAlert sends a resolve event with the same deduplication key, and the incident closes. Nothing runs on your side.

Step 1: Create a PagerDuty service and integration key

  1. In PagerDuty, go to Services, then Service Directory, and open the service that should receive the alerts, or click New Service. A dedicated "Website Uptime" service keeps monitoring incidents separate from application errors and lets you give it its own escalation policy.
  2. On the service's Integrations tab, click Add Integration, search for Events API v2, and add it.
  3. Copy the Integration Key, a 32-character string. This is the routing key that tells PagerDuty which service an event belongs to. Treat it like a password; anyone with it can open incidents on that service.

While you're there, check the service's escalation policy and the on-call schedule attached to it. A key pointed at a service with no responders creates incidents that page nobody.

Step 2: Add the PagerDuty channel in CronAlert

  1. In CronAlert, open Alert Channels and click Add Channel.
  2. Choose PagerDuty. Give it a name ("On-call pager" is fine) and paste the integration key.
  3. Save, then click Test on the new channel. You should see an incident appear on the PagerDuty service within a few seconds. Acknowledge and resolve it there; it's a good moment to confirm the on-call person's phone actually rang. Testing alert channels covers making this a habit.

That's the whole setup. Alert channels in CronAlert are team-wide, so every monitor in the team now pages PagerDuty when it goes down; there is no per-monitor assignment step. If only some monitors should page, see the section on scoping below.

What the incident contains

The trigger event CronAlert sends looks like this:

{
  "routing_key": "<your integration key>",
  "event_action": "trigger",
  "dedup_key": "cronalert-https://api.example.com/health",
  "payload": {
    "summary": "Checkout API is down",
    "source": "CronAlert",
    "severity": "critical",
    "timestamp": "2026-09-17T03:02:11.000Z",
    "custom_details": {
      "monitor_url": "https://api.example.com/health",
      "status_code": 503,
      "error_message": null,
      "region": "us-east"
    }
  }
}

The resolve event carries the same dedup_key with "event_action": "resolve" and no payload. Two consequences worth knowing:

  • One incident per outage. The dedup key is derived from the monitor's URL, so repeated failing checks during the same outage don't open new incidents; PagerDuty attaches them to the open one. Two monitors with different URLs open separate incidents.
  • Auto-resolve on recovery. When the monitor's next check passes, the incident resolves itself. If you'd rather incidents stay open until a human closes them (for a postmortem, say), turn off auto-resolution on the PagerDuty service or use an event rule; CronAlert will still send the resolve, and PagerDuty decides what to do with it.

Severity is always critical. To page with lower urgency for some monitors, use PagerDuty's event orchestration to set urgency based on the summary text, or the scoping approach below.

Paging for only some monitors

Because channels are team-wide, the clean way to page on-call for production but not staging is a separate team: put staging monitors in a team without a PagerDuty channel. Within one team, PagerDuty's own tools do the filtering: an event rule (or service orchestration rule) that matches summary against a naming convention, such as a [page] prefix on the monitors that warrant a call, and suppresses or lowers the urgency of everything else. This is also how to route different monitors to different escalation policies without multiple CronAlert channels.

Pair it well

  • PagerDuty for waking someone, Slack for everyone else. Keep a Slack channel (free) enabled alongside PagerDuty. The on-call engineer gets the call; the team sees the same incident and its recovery in Slack without being paged. Email is a sensible third channel as a fallback that doesn't depend on either service.
  • Use maintenance windows. A planned deploy that takes the site down for two minutes shouldn't page anyone. Maintenance windows (Pro) suppress alerts for the scheduled period, so the PagerDuty trigger never fires. PagerDuty's own maintenance windows work too, but stopping the event at the source keeps your incident history clean.
  • Tune the escalation policy, not the monitor. It's tempting to slow the monitor down to avoid pages for blips. Instead, keep checks at one minute and let the escalation policy add a few minutes before the first phone call, so a self-healing thirty-second outage becomes a resolved incident nobody was woken for. Avoiding false positives has more on thresholds.
  • Check who's on the schedule. Once a quarter, look at the schedule attached to the service. Departed employees still on a rotation are the most common reason a page goes nowhere. The on-call rotation guide covers keeping a small rotation healthy.

Frequently asked questions

Does CronAlert have a native PagerDuty integration?

Yes. It's a channel type; you paste an Events API v2 integration key and CronAlert sends trigger and resolve events directly.

Which plan includes it?

Pro ($5/month) and above, with Teams and Telegram. Free includes email, push, Slack, Discord, and webhook.

Will incidents auto-resolve?

Yes. The resolve event reuses the trigger's dedup key, so the incident closes when the monitor recovers.

Can I page for only some monitors?

Channels are team-wide. Use a separate team for monitors that shouldn't page, or PagerDuty event rules on the summary text.

What about Opsgenie or Splunk On-Call?

Those use the free webhook channel with their inbound integrations. See Opsgenie and Splunk On-Call.

Wrapping up

One integration key connects CronAlert's checks to PagerDuty's phone calls and escalation, with incidents that deduplicate and close themselves. Add Slack for visibility, maintenance windows for planned work, and a quarterly look at the schedule, and the 3 AM outage reaches the right person without waking the rest of the team. Create a free account, add your monitors, and upgrade to Pro when you're ready to connect the pager. Related reading: incident response workflows, MTTR and the incident metrics that matter, and avoiding alert fatigue.