---
title: When your provider is down, say so: third-party status on your status page
description: Checkout breaks because a provider is down, and your status page stays green. Show third-party status next to yours, without taking the blame for it.
canonical: https://watchfor.io/blog/third-party-status-on-your-status-page
---

# When your provider is down, say so: third-party status on your status page

2026-10-20 · WatchFor Team · Monitoring · status-pages, uptime, communication, reliability

Checkout breaks because a provider is down, and your status page stays green. Show third-party status next to yours, without taking the blame for it.

It's 14:07 on a Tuesday. Support pings the engineering channel: some
customers can't pay. A few cards go through, most don't. You open the
dashboard. Checkout is up, the API answers, every monitor is green. Then
someone finds it: your payment provider has posted *degraded performance for
card payments in some regions* on its own status page.

Meanwhile your status page still says **All systems operational**. A customer
who can't pay looks at it, sees green, and draws the obvious conclusion:
either you don't know, or you're not saying. The support queue doubles, and
every reply starts with the same paragraph.

Nothing on your side was broken, so your monitors were right. What was
missing was the one sentence your customers needed: *it's not us, it's the
payment provider, here's their status.*

## "Is it you or them?"

That is the first question anyone asks when something they depend on stops
working. Your status page can answer half of it on its own, the half about
the services you run. The other half lives on GitHub's, Stripe's,
Cloudflare's or OpenAI's status page, and nobody checks five status pages
while they're trying to pay for something.

A **third-party component** puts that half on your page. It mirrors a
provider's own public status page, live, as one more row next to your own
components.

![An Acme status page reading "All systems operational", with Checkout and Public API operational and a Stripe row below marked Degraded, showing Global payments affected and a "Status provided by Stripe" link (illustration)](/blog/third-party-status-on-your-status-page-page.webp)

The illustration shows the shape: your services at the top, the providers
you depend on below them, each with its own state, history and a link to the
provider's page.

## How it works

You add it like any other component. In the component editor, under *What
does this component show?*, choose **Third-party service** instead of *Your
monitors*, then pick the provider from the catalog.

![The WatchFor component editor for an Acme status page, with the choice between "Your monitors" and "Third-party service", the display modes, and the "Incident details on the public page" setting](/blog/third-party-status-on-your-status-page-editor.webp)

A few details matter more than they look:

- **Pick the parts you rely on.** Providers split their status into
  components. You can show GitHub's *Actions* and *Webhooks* without *Copilot*
  and *Codespaces*, or Stripe's *Global payments* without the rest. Leave
  nothing selected and the row shows the provider's overall status as one
  line.
- **It refreshes on its own.** The status is read from the provider's public
  status page every 3 minutes. No API key, nothing to configure.
- **It has a history.** A 90-day uptime heatmap builds up from the day you
  add the component, so visitors see the provider's track record, not only
  this minute. It can't be back-filled; the provider's past isn't ours to
  invent.
- **It links back.** Every third-party row says where the data comes from and
  links to the provider's own status page, and it's flagged when the data is
  momentarily delayed.
- **Same display modes** as your own components: rolled-up, collapsible or
  expanded.

The catalog covers 30 providers today: GitHub, GitLab, npm, Vercel, Netlify,
Cloudflare, DigitalOcean, Render, Google Cloud, Cloudinary, Twilio, OpenAI,
Anthropic, Stripe, Shopify, SendGrid, Mailgun, Resend, Datadog, Sentry,
MongoDB Atlas, Supabase, PlanetScale, Slack, Discord, Zoom, Atlassian (Jira
and Confluence), Notion, Linear and Figma. If one you depend on is missing and
it runs a standard public status page, [tell us](/contact) its name and
status-page URL.

## The rule that keeps it honest

**A provider's outage never changes your page's overall banner.**

It's tempting to think a red row should turn the whole page red. It
shouldn't, in either direction. If a provider's outage flipped your banner,
your page would announce an outage of yours every time GitHub had a bad
afternoon, even when your customers felt nothing. And if third-party rows
could stand in for your own state, a page could quietly blame vendors for
problems that were really yours.

So the banner reflects the services you run, and only those. The provider's
problem shows where it belongs: on the provider's row.

The same goes for notifications. A third-party row is a mirror, not an
incident of yours. It never opens an incident on your page and never emails
your subscribers. When a provider's problem *does* hurt your customers, like
the card payments above, you decide what to say and post it yourself as an
[incident update](/docs/status-pages/updates#writing-incident-updates),
affecting your *Checkout* component, in your words.

## What it can't do

Being clear about the limits saves you a surprise during an outage.

- **It's the provider's word, not ours.** We show what the provider's status
  page says. Providers often confirm an outage some minutes after it starts,
  and sometimes describe it more gently than you'd like. If you know first,
  post your own update; don't wait for theirs.
- **Three minutes is the refresh, not the reaction time.** Combined with the
  point above, a third-party row is for explaining, not for alerting. Your
  own monitors are what tell you something is wrong.
- **Not every provider publishes a usable status feed.** AWS and Azure, for
  example, don't offer a machine-readable view of current component status,
  which is why they aren't in the catalog.
- **Third-party components are managed in the dashboard.** The
  [status pages API](/docs/api/status-pages) creates and updates
  monitor-backed components; third-party rows are added in the editor.

## While you're in the editor: how much to say about your own outages

The screenshot above has a second setting worth a minute: **Incident details
on the public page.** It decides what an automatically published incident
says about *your* components:

| Setting | Visitors see | Good for |
| --- | --- | --- |
| **Status only** | Down or up, nothing about why | The cautious default |
| **Cause** | The kind of problem in plain words, such as *Not reachable*, *SSL certificate expiring* or *Disk space running low*, with no values, paths or names | Most public pages |
| **Full detail** | What was detected, as your team sees it | Private or password-protected pages for internal use |

Third-party rows don't use it: they always show what the provider says. The
setting only changes incidents published after you set it, and you can edit
any notice by hand. The details are in
[incident details on the public page](/docs/status-pages/components#incident-details-on-the-public-page).

## Setting it up

1. Open your status page in the dashboard and choose **Add component**.
2. Under *What does this component show?*, pick **Third-party service**.
3. Search the catalog, pick the provider, and tick the parts your product
   actually depends on.
4. Choose a display mode and save. The row shows up right away, and its
   history fills in from today.

Then add the second and third. A useful test for which providers belong on
the page: *if this provider went down, would my customers notice?* Payments,
sign-in, email delivery, hosting and your CDN usually pass it. The tool your
team uses for sprint planning usually doesn't. Five well-chosen rows answer
"is it you or them?" better than thirty that nobody reads.

## Further reading

- [The complete status page guide](/blog/status-page-complete-guide):
  components, visibility, maintenance and the trust rules behind all of it.
- [Status page best practices](/blog/status-page-best-practices): what to
  write on your worst day.
- [Incident status update templates](/blog/incident-status-update-templates#when-its-your-providers-outage):
  copy-paste wording for every stage, including when it's your provider's outage.
- [Third-party components in the docs](/docs/status-pages/components#third-party-components).

The next time a provider has a bad afternoon, your page can say so in one row,
and your support team can link to it instead of writing the same paragraph
two hundred times.

---

Canonical page: https://watchfor.io/blog/third-party-status-on-your-status-page · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt