PagerDuty alerts that reach whoever is on call.

Uptimia checks your sites from 171+ locations and posts the failure straight to PagerDuty’s Events API v2. Your own escalation policy takes it from there — it rings the phone, and rings the next one when nobody picks up.

Start paging from your monitors → See what triggers an incident
Setup guideGetting the Events API v2 key, step by step Open the guide

A room is not a rota

A chat alert is a broadcast: everyone sees it, so nobody owns it. PagerDuty turns the same failure into an assignment — one name, one countdown, and the next name when the countdown runs out.

The alert as a message in a channel

Seen by everyone, owned by nobody

Signing API fails
04:52 · posted to #alerts
nobody on duty here
The scrollback
three 👍 reactions by breakfast

Everyone who sees the message assumes a colleague nearer a keyboard has it, and on a Sunday the whole room is asleep in unison. A channel has no idea whose weekend it is.

The alert as a PagerDuty incident

One name, one timer, then a phone

Signing API fails
04:52 · trigger event
policy · 4-min timer
The phone that must answer
rings, escalates, records the acknowledgement

PagerDuty already knows whose week it is, which number to ring and what to do when nobody picks up. The one thing it cannot supply is the reason to start: proof from outside your network that a real visitor could not load the page.

A louder channel does not help. An alert with an owner and a stopwatch on it does. Here is a Sunday-morning failover, minute by minute:

The Sunday the handshakes stopped

At 04:52 a regional load balancer stopped completing TLS handshakes at an e-signing platform. Nine monitors failed inside a minute, the graphs inside the platform stayed green, and one phone rang at 04:53 — the one the rota says is holding the pager this week.

04:52 Nine checks fail on one escalation policyOne trigger event: “9 monitors down — Signing API +8 more (#482)” sev · critical
04:53 Policy rings the primary — no answerNothing is lost: the policy is already counting down to step two policy · step 1
04:58 Secondary acknowledges, starts region failoverThe summary named the monitor and severity — enough to act on first acknowledged in PagerDuty
05:16 ✅ All-clear: all 9 monitors back upIts own event at severity warning — the responder closes the incident recovery event
24 mindown → up
The engineer who fixed it had never opened Uptimiaweek 2 on the rota
They had joined the rota a fortnight earlier and had no monitoring login. The page carried the monitor’s name, the severity and the component; their runbook did the rest, and the acknowledgement is on record in PagerDuty — Uptimia’s timeline kept the outage and the recovery either way.
9 monitors, 1 triggeracknowledged in 6 min24 minutes downno login needed
Detection came from outside the building. Everything after it stayed in PagerDuty — the rota, the phone call, the escalation, the acknowledgement. no monitoring login needed

One key, nothing to host

Uptimia speaks Events API v2, the same interface PagerDuty’s own integrations use. Create a service, copy its Integration Key, paste it into Uptimia: no OAuth app to authorise, no middleware, no endpoint of your own to keep alive.

Step 12 min

Create the service, copy the key

In PagerDuty, open Services → New Service, name it after the system it covers and pick Events API v2 as the integration type. Its Integrations tab shows the Integration Key — the one value Uptimia stores for this channel.

Web platform · Events API v2 Copy key
R0VE··············KEY · one value, nothing else to configure
Step 21 min

Paste it in Uptimia, fire a test

Under Alerting → Integrations, pick PagerDuty, paste the key and save. Press Send test and an info-severity event lands in the service straight away — you watch the routing work before an outage tests it for you.

Alert this monitor to
PagerDuty · Web platformEmailSlack
test event delivered · severity info · source uptimia.com
Step 3important

Decide which ladder escalates

PagerDuty already owns the rotation, the overrides and the phone calls. Let it keep them — attach the monitor to a single PagerDuty contact. Run an Uptimia ladder alongside it and one outage chases two sets of people.

Who escalates
PagerDuty policy — on call → +4 min secondary → +10 min lead
Uptimia ladder — one step · maintenance windows send nothing
Technical setup guide

Connect PagerDuty to Uptimia

Every step, in the Help Center: creating an Events API v2 service in PagerDuty, copying the Integration Key, and attaching the contact to your monitors.

  • Get an Integration Key in PagerDuty
  • Add the PagerDuty integration
  • Send a test
  • Attach the contact to your monitors
  • Troubleshooting
Open the setup guide → help.uptimia.com

One routing key, every check

Pinging the homepage tells you about the homepage. Uptimia runs twelve monitor types — a login walked step by step, an API chain that dies on its third call, a cron job that never reported in — and every one of them triggers through the same key.

Uptime checksConfirmed by up to three regions first
SSL certificatesExpiry dates and broken handshakes
Domain expiryRenewal dates that creep up
Server metricsCPU, memory, disk and load
1 routing key Events API v2 — every check triggers through it
Heartbeats & cronThe nightly job that never called
TransactionsCheckouts replayed step by step
Virus & malwarePages flagged, hosts blocklisted
Page speedLoad times past your ceiling
Severity rides the event — a confirmed outage arrives critical, a recovery and a server past its CPU, memory or disk threshold arrive warning, so your service rules can route them apart. 12 types · 1 key

One service or one per rota

Every Integration Key you add becomes its own contact in Uptimia, so you decide how coarse the paging is: the whole estate onto one rotation, or each system onto the team that actually owns it.

A single service
One key, one rotation — where most teams start.
Every monitor type triggers into it
One escalation policy, one trigger event
Your policy decides who it wakes
one key, one contact
A service per system
Checkout, platform and infrastructure, each with its own key.
Transaction replays → the payments rota
Servers and heartbeats → infrastructure
Certificates and domains → the renewals queue
keys are just contacts
Pager at night, chat by day
Not every finding is worth a call at four in the morning.
Confirmed outages → PagerDuty
Expiry and threshold warnings → a chat channel
Monthly uptime reports → e-mail
same incident, different audiences
The same incident can also reach SlackMS TeamsDiscordTelegramWhatsAppTwilio SMSEmail

Channels get read.Pagers get answered.

The whole platform on the trial — twelve monitor types, one Integration Key, incidents raised the moment a failure is confirmed.

Start your free 30-day trial →
30 days free no credit card cancel anytime

Trigger in PagerDuty, evidence in Uptimia

The event says what broke and how badly, which is all a responder needs at 04:52. The per-checkpoint verdict, the response-time chart and the incident timeline are waiting in Uptimia for whoever writes the follow-up.

What the event actually carries

Every trigger is the same JSON to Events API v2: a summary of what broke, source uptimia.com, a severity, and a component naming the kind of check — or Incident group whenever an escalation policy raised it. Nothing to map or parse.

summary — Signing API is DOWN (Uptimia incident #479)TEXT severity — criticalPAGES component — Incident groupROUTES

Confirmed before it pages

One unlucky probe never wakes anybody. On uptime, speed, certificate and transaction checks you set how many independent regions must agree — up to three — before an event is sent.

171+ checkpoints · 6 continents

One storm, one incident

Monitors that share an escalation policy — Professional plan and above — and fail together are folded into one Uptimia incident, and PagerDuty gets a single event that names it.

Uptimia incident #482 · 9 monitors

Maintenance stays quiet

Planned windows suppress alerting, so a deploy at 23:00 never turns into a phone call.

23:00–01:00 · muted

Reaction time on record

On an escalation policy — Professional plan and above — Uptimia timestamps its own acknowledgements, so the incident carries who picked it up and how many minutes it took.

acknowledged · 6 min

Facts only — by design

Chat channels get an acknowledge link; PagerDuty and webhook payloads never do — a machine feed of log pipelines must never silence an escalation. Acknowledge in PagerDuty or Uptimia, each for its own.

PagerDuty event — facts, no acknowledgement linkBY DESIGN Chat channels — acknowledgement link includedSLACK · TEAMS Dashboard — one tap ends the ladderUPTIMIA

How PagerDuty monitoring alerts work

Uptimia watches your websites from 171+ external locations and, when a check fails, posts a trigger event to PagerDuty’s Events API v2 using the Integration Key of one of your services. The event carries a summary naming the monitor and what happened, source uptimia.com, a severity — critical for a confirmed outage, warning for a recovery or a server past a resource threshold, info for the test event — and a component describing the kind of check, so PagerDuty’s own rules can route it without reading the text. From there the incident belongs to PagerDuty: its escalation policy picks whoever is on call, rings them, and moves on to the next person when nobody answers. When the check recovers, Uptimia sends a second event carrying the all-clear.

“The pager will close itself when the site comes back”

Recovery is an event, not a resolve

Back up at 05:16
all-clear event sent
no resolve is sent
The incident stays open
until a responder closes it

Every event Uptimia sends is a trigger, never a resolve — a check flapping back up is not an incident anybody handled. The all-clear arrives as its own warning event naming the monitors that came back; the responder closes the incident in PagerDuty.

External probes + your escalation policy

Detected outside, escalated inside

171+ locations
up to three regions must agree
one trigger event
Your on-call policy
rings, escalates, records

An in-house health check shares your region, your load balancer and your bad day, and goes quiet with them. Checkpoints in 70+ countries fail independently of you — which is the only kind of evidence worth waking a colleague at 4am for.

Every event

Seven events, one routing key

Each row is a single POST to Events API v2 — no templates to maintain, no fields to map, nothing to keep running on your side.

Compare all 12 alert channels →
EventSeverityWhat the summary says
Confirmed outagecriticalThe monitor’s name, marked DOWN
Storm digestcritical“9 monitors down — Signing API +8 more (Uptimia incident #482)”
Join updatecriticalHow many more monitors joined the same incident
Still-down remindercritical“Still down: 3 of 9 monitors” when a later escalation step fires
Server thresholdwarningCPU, memory, disk or load past the limit you set
RecoverywarningBack up — a single monitor also reports how long
Test eventinfoA hello from Uptimia, sent when you press Send test

PagerDuty integration FAQ

01What do I need on the PagerDuty side?+
A service with an Events API v2 integration. In PagerDuty: Services → New Service → choose Events API v2 as the integration type, then copy the Integration Key from the service’s Integrations tab. That key is the only value Uptimia stores — there is no app to authorise, no user account to connect and nothing to host.
02Does Uptimia resolve the incident when the site comes back?+
No. Every event Uptimia sends is a trigger, including the all-clear: recovery arrives as its own warning event naming what came back, and the PagerDuty incident stays open until somebody closes it there. A check bouncing back up is not the same thing as an outage that has been dealt with, so the last word belongs to the responder.
03Will one outage page me nine times?+
Not if those monitors share an escalation policy — policies come with the Professional plan and above. Grouping is on by default and folds everything that fails inside the same window into one Uptimia incident, so PagerDuty receives a single event naming it: “9 monitors down — Signing API +8 more (Uptimia incident #482)”. Monitors that join later produce one throttled update event instead of one per monitor, and one all-clear when they are all back. Monitors with no escalation policy attached are alerted one by one, and grouping can be switched off in Alerting settings if that is what you want.
04Whose escalation wins — Uptimia’s or PagerDuty’s?+
Whichever you point the monitor at — and running both doubles the noise. Teams that already live in PagerDuty let it own the rotation and attach the monitor to a single PagerDuty contact. Uptimia’s own escalation policies — timed steps to further people and channels, which you build yourself on the Professional plan and above — are there for teams without an on-call tool.
05Does acknowledging in PagerDuty acknowledge it in Uptimia?+
No — the connection is one-way: Uptimia posts events, PagerDuty never posts back. Acknowledging in PagerDuty stops PagerDuty’s escalation; acknowledging in the Uptimia dashboard stops Uptimia’s. It is also why PagerDuty payloads deliberately carry no acknowledge link, unlike the chat channels — a machine feed and the log pipelines behind it should not be able to silence an escalation.
06Which monitors can trigger an incident?+
All twelve types — uptime, transactions, page speed, real-user monitoring, SSL, domains, malware, servers, heartbeats, blacklists, DNS and API checks. Each writes its own summary naming the monitor and what happened to it, and each sends its own all-clear when the check passes again.
07How do severities map?+
Confirmed outages arrive as critical, and so do expiry and degradation alerts sent per monitor — if you would rather those did not page anyone, send them to a chat channel instead. Server resource thresholds — CPU, memory, disk, load — and every recovery arrive as warning; grouped incidents raised at trouble level do too. The test event arrives as info. Every event also carries source uptimia.com and a component naming the kind of check (“Uptime Monitoring”, “SSL Certificate”, “API Monitoring”), or “Incident group” whenever the alert was raised through an escalation policy (Professional plan and above).
08Can different monitors page different services?+
Yes. Add one integration per Integration Key — each becomes its own contact — then attach monitors to whichever contact matches the rota that owns them. A checkout replay can page the payments service while a disk warning goes to infrastructure.
09What happens if the key is wrong or PagerDuty is unreachable?+
The call is bounded — ten seconds to connect, thirty in total — so a slow or unreachable endpoint cannot hold up the rest of the alerting run, and the result is recorded with the alert. Every other contact on that monitor is notified independently of this one. A mistyped key is worth catching with Send test rather than during an outage.
10Is PagerDuty available on every plan?+
Yes — it is one of 12 built-in alert channels, included on every plan and in the 30-day free trial, with no per-event charge from Uptimia. What you pay PagerDuty for seats and its own escalation features is between you and PagerDuty.

One key, then the rota

Create the service, copy the Integration Key, press Send test. From the next confirmed failure on, the phone that rings belongs to whoever’s turn it is — and the evidence is waiting in Uptimia when they get there.

Start paging from your monitors →
Events API v2 One key, no code 30-day free trial No credit card
PagerDuty is one of 12 built-in alert channels — every Uptimia monitor type can trigger an incident.