Skip to content

Website monitoring with PagerDuty alerts

Uptimia checks your sites, certificates and checkout flows from outside your network and raises every confirmed failure as an incident in PagerDuty. Your escalation policy takes it from there — one phone rings, then the next when nobody picks up, until somebody is on it.

Alerts need an owner, not an audience

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:

One outage, one phone call

One failure in your infrastructure can turn nine checks red at once — checkout, API, login, all in the same minute. Uptimia folds them into one incident, and PagerDuty rings one phone: whoever is on call that 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
The person on call had no Uptimia login and never needed one. The page named the monitor, the severity and the component — enough to act on — and the acknowledgement is on record in PagerDuty.
9 monitors, 1 triggeracknowledged in 6 min24 minutes downno login needed
Detection came from outside the building. Everything after it stayed in PagerDuty — the schedule, the phone call, the escalation, the acknowledgement. no monitoring login needed

Connect PagerDuty in three steps

Create a service in PagerDuty, copy the key it gives you, paste it into Uptimia. There is no app to authorise and nothing of your own to keep running.

Step 12 min

Copy the key from PagerDuty

Create a service in PagerDuty — the key it shows is all Uptimia needs.

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

Paste it into Uptimia

Save the key, and a test event proves the routing on the spot.

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

Let PagerDuty own the escalation

Your schedules, overrides and phone calls stay in PagerDuty — Uptimia raises the incident and steps back.

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 the service in PagerDuty, copying the key, and attaching it to your monitors.

Open the setup guide help.uptimia.com

Every check you run can page you

Pinging the homepage tells you about the homepage. Uptimia also walks a login step by step, follows an API chain that dies on its third call and notices a scheduled job that never reported in — and every one of them can raise the page.

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 one key — every check pages 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. every check · one key

Route each system to the team that owns it

Page one rotation for everything, or give each system its own service — the checkout to the storefront team, the servers to the platform team, and the low-stakes findings to a channel that waits for morning.

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 — every kind of check, one key, and an incident 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. 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 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, 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 checks your websites from 171+ external locations and, when a check fails, raises an incident in PagerDuty — your escalation policy rings whoever is on call and keeps going until someone acknowledges. The incident names the monitor, what went wrong and how severe it is, and when the check recovers a second event carries the all-clear into the same service.

“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. 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?+
Every one of them — 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.
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 a built-in alert channel, 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.

Downtime alerts, straight to your on-call

Connect PagerDuty with one key, and every confirmed failure rings whoever is on call — with the evidence waiting in Uptimia when they get there.

Your on-call, not a broadcast One key, no code 30-day free trial No credit card
PagerDuty is a built-in alert channel — every check Uptimia runs can trigger an incident.