How to monitor vendor status pages for outage alerts

Just before midnight Pacific time on October 19, 2025, a race condition in the DNS automation behind Amazon DynamoDB left the service's regional endpoint in us-east-1 with an empty DNS record. Anything that needed DynamoDB in that region started failing, and the damage spread to other AWS services that relied on it. By AWS's own summary, the event ran for about fourteen and a half hours.

Plenty of teams that morning had perfectly healthy servers. Their uptime monitors stayed green while their login provider, payment processor, or email service struggled. Most outages are smaller than that one, though. Your email vendor delays sends by forty minutes, support gets a pile of "my password reset never arrived" tickets, and someone eventually finds the vendor's status page, which has said "Degraded performance" for half an hour.

I work on Page Deltas, a tool that watches public web pages and tells you when they change in a way you care about, so keep that in mind when I compare it with other tools below. This post walks through pointing it at the status pages of the vendors you depend on: which URL to pick, how to write a brief that skips the noise, where to send the alert, and where this setup stops being enough.

Why your monitoring stays green

Your uptime monitor asks whether your site answers, and during a vendor outage it usually does. Your APM will show a spike in errors on calls to the vendor, but it can't tell you whether the problem is your code or their service. That's the question a status page answers, and the answer changes what you do next. You don't roll back the deploy you shipped an hour ago. You tell support it's a known issue, and you think about updating your own status page.

So why not subscribe on the vendor's page directly? You should, if it covers you. Many status pages run on Atlassian Statuspage and offer email, SMS, Slack, Teams, or webhook subscriptions, depending on what the vendor turned on. The trouble shows up at the eighth vendor. Each subscription is a separate setup that often lands in one person's inbox, every vendor formats its messages differently, and filtering down to the components you use isn't always offered. Some vendors run a homegrown page with no subscribe button at all.

A change monitor gives you one way of doing it for every vendor. You paste the status page URL, describe what you care about in a sentence, and every alert arrives in the same channel with the same shape.

Which page should you watch?

Pick the page that shows current status, which is usually status.vendor.com. Don't pick the vendor's homepage or its "trust" marketing page. Most SaaS status pages share the same layout: a list of components with a status word next to each one, a banner for active incidents, upcoming scheduled maintenance, and a short list of recent incidents with a link to the full history.

Start with the dependencies your customers would feel first. For most software teams that's a short list.

If you can only watch a few, start at the top. Payments and login failures turn into support tickets within minutes, while a slow CDN might only show up in your metrics. The Free plan's 10 URLs cover all five rows with room left for the extras below.

Two other pages are worth knowing about. The history page (often /history) is a good second monitor for a vendor you rely on heavily. A short incident can start and resolve between two checks of the main page, but it stays listed in the history, so you still hear about it, just later. During a long incident, you can also add the incident's own page as a temporary monitor so each update reaches you. Delete it once the incident is resolved, since every monitor counts toward your URL limit.

Setting it up

The setup takes about five minutes, and it's the same flow as our changelog monitoring guide with a different brief.

1. Create an account and a channel

Sign up for a free account, open Channels, and add the place where alerts should land. I'd create a dedicated channel like #vendor-status rather than posting into #engineering, where it'll get buried. Slack, Discord, and Microsoft Teams take an incoming-webhook URL. In Teams, right-click the channel, choose Connectors, then Incoming Webhook, then Configure, and paste the URL into Page Deltas. Email asks the recipient to confirm a verification message first. Click Send test on each channel so you know it arrives.

2. Add a monitor with a brief

Click New monitor and paste the status page URL. Keep one vendor per monitor so each brief can name that vendor's components, and if different teams care about different vendors, attach a different channel to each monitor.

Status pages change more often than you'd think, even on a quiet day. Uptime percentages tick along, "last updated" timestamps move, and the recent incidents list rolls forward a day at a time with a fresh "No incidents reported" row. Scheduled maintenance gets announced weeks ahead. A plain diff tool fires on all of it.

The monitor's description is the prompt our LLM reads when it decides whether a change matters. Write it like a note to a colleague who's watching the page for you. For an email provider, something like this works:

Status page for our email provider. We only use the Email API and
Webhooks components, in the US region.
Alert me when a new incident is posted that affects those components
or that region, when its status or severity changes, or when it's
resolved. Alert me if either component changes from Operational.
Ignore uptime percentages, "last updated" timestamps, the daily
"No incidents reported" rows, and incidents in other regions.
Mention scheduled maintenance only if it starts within 48 hours.
Summarize the affected component, current status, and latest update.

The ignore line does most of the work. If you leave it out, you'll spend the first week getting alerts about the incident list rolling over at midnight.

For a big cloud provider, the region and service names matter even more. A public cloud dashboard covers hundreds of services across dozens of regions, and on a normal week something somewhere is degraded. Name the regions and services you run on, and ask to be told only about those.

3. Let the first check set the baseline

A new monitor runs its first check shortly after you create it. That check stores the starting point, so you won't get an alert on minute one unless the page changes between two checks. Open the monitor afterward and look at the screenshot to confirm it captured the component list you expected.

4. Check now when something feels off

You don't set a check interval in Page Deltas. The schedule is adaptive, so pages that change often get checked more often, and paid plans get priority when the queue is busy. A status page is quiet most of the time, so when your error rate climbs and you suspect a vendor, click Check now on its monitor. The same action is available over the API, limited to once per minute per monitor:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

What to do when an alert lands

When a change matches your brief, you get one message with a plain-language summary and before and after screenshots. If you use the signed webhook, the body looks like this (the values are made up for the example):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "Email provider status",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "New incident: delayed email delivery in the US region. Email API changed from Operational to Degraded Performance. Status: Investigating.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

The first person who sees it should reply in the thread with what it means for you. Support can pin a known-issue reply before the tickets pile up. The on-call engineer can stop digging through a deploy that didn't cause the errors, and if the outage is customer-facing, update your own status page so customers hear it from you first.

If your team lives in PagerDuty or another incident tool, the signed webhook can feed it through a small relay. Our payload isn't in PagerDuty's format, so you need a few lines of code in a serverless function to verify the signature and forward the event:

import crypto from "node:crypto";

export async function handle(rawBody, signature) {
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
    .update(rawBody).digest("hex");
  if (signature.length !== expected.length ||
      !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return 401;
  }
  const alert = JSON.parse(rawBody);
  await fetch("https://events.pagerduty.com/v2/enqueue", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      routing_key: process.env.PAGERDUTY_ROUTING_KEY,
      event_action: "trigger",
      dedup_key: alert.change_id,
      payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
      links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
    }),
  });
  return 200;
}

Hash the raw body before you parse it, or the signature won't match. The channels docs cover the details. Each alert goes out once per channel with no automatic retry, so for vendors you can't live without, attach a second channel of a different type (Slack plus email works) in case the relay or Slack has a bad day.

Where it stops

This setup tells you what a vendor has said publicly, and that comes with a few limits you should know before relying on it.

Vendors are often slow to post. Your own error graphs will sometimes show trouble before the status page admits anything, so treat the alert as confirmation rather than your first warning. And it isn't a replacement for synthetic checks or uptime monitoring on your own API. Those tell you your product is broken. The status page tells you why.

Between checks, a change is picked up on the next scheduled run, and there's no fixed interval you can count on. For the one or two vendors where minutes matter, keep the vendor's own subscription too and use Page Deltas for the rest of the list. We also only see public pages, so a status that only shows up inside a vendor's admin console is out of reach for now.

We compare the text of each page. If a vendor shows status only as a colored dot with no words changing, we won't see it. Visualping lets you watch a pixel region of a page, and it's the better fit for that case. Last, if the status page itself goes down, checks fail instead of alerting, and after 10 failed checks in a row the monitor pauses itself and your admins get a notice.

Start with three vendors

Pick the three vendors whose outages would hurt you most, probably payments, login, and email. Paste their status page URLs, adapt the brief above with the components and regions you use, and send a test alert to #vendor-status. The Free plan covers 10 URLs with AI filtering, every alert channel, and API access, and it doesn't need a credit card. Start monitoring for free.

Julien, Product Manager at Page Deltas