---
title: Components & grouping
description: Build a status page from components backed by your monitors — or mirror GitHub, Cloudflare, Stripe and 30+ other providers' own status pages.
canonical: https://watchfor.io/docs/status-pages/components
---

# Components & grouping

Build a status page from components backed by your monitors — or mirror GitHub, Cloudflare, Stripe and 30+ other providers' own status pages.

A **component** is one thing on your status page that customers care about —
"API", "Website", "Dashboard", "EU region". Its state is derived from the
[monitors](/docs/monitors) behind it (or from an external provider's status
page), so the page reflects reality without anyone editing it.

## Adding a component

In the page editor choose **Add component**, then:

- **Name** and optional description — use the words your customers use, not
  your internal service names.
- **Monitors** — attach specific monitors, and/or one or more
  [tags](/docs/monitors/tags). A tag-backed component is dynamic: any monitor
  you tag later (`prod`, `eu`, …) joins it automatically.
- **Display mode** — how much detail visitors see (below).

Reorder components with the move up / move down controls; the order is the
order on the public page.

## Display modes

| Mode | What visitors see |
| --- | --- |
| **Rolled-up** (default) | One aggregate indicator for the whole component. |
| **Collapsible group** | The aggregate line, expandable to show each monitor underneath. |
| **Expanded** | Every monitor listed under the component, each with its own state. |

Use rolled-up when customers only need the headline, collapsible when the
detail is useful but noisy, and expanded when each item genuinely matters
(for example, one row per region).

## How a component's state is computed

- A component is **operational** while none of its monitors has an open,
  confirmed [incident](/docs/alerting/incidents).
- A confirmed incident on any of its monitors marks it **degraded** or
  **down**, depending on the severity of the published incident — a *critical*
  announcement shows as down, *major* and *minor* as degraded.
- Monitors inside an active [maintenance window](/docs/monitors/maintenance)
  read as **maintenance** (blue) rather than operational or down.
- A monitor that is merely **Degraded** internally (one location failed,
  nothing confirmed) does not change the public page — the page only ever
  reflects confirmed problems.

Each component builds its own **uptime history**, feeding the heatmap and
uptime percentages visitors see.

> **Info**
>
> Every monitor on a page is visible to whoever can open the page, so keep
> internal-only monitors off public pages — or put them on a
> [private page](/docs/status-pages/visibility) for your team.

## Third-party components

Your service depends on others — GitHub, Cloudflare, Stripe, OpenAI. When one
of *them* has an outage your customers feel it, and "is it you or your
provider?" is the first question they ask. A **third-party component** answers
it by mirroring the provider's own public status page, live, next to your own
components.

To add one, choose **Third-party service** when adding a component and pick a
provider from the catalog. Then either select the specific parts you rely on
(for example GitHub *Actions* and *Webhooks*) or leave them all unselected to
show the provider's overall status as a single line.

The catalog currently covers 30 providers:

| Category | Providers |
| --- | --- |
| Developer & hosting | GitHub, GitLab, npm, Vercel, Netlify, Cloudflare, DigitalOcean, Render |
| Cloud & infrastructure | Google Cloud, Cloudinary, Twilio |
| AI | OpenAI, Anthropic |
| Payments & e-commerce | Stripe, Shopify |
| Email | SendGrid, Mailgun, Resend |
| Observability | Datadog, Sentry |
| Databases | MongoDB Atlas, Supabase, PlanetScale |
| Communications & productivity | Slack, Discord, Zoom, Atlassian (Jira/Confluence), Notion, Linear, Figma |

How they behave:

- Status is **polled every 3 minutes** from the provider's public status
  page — nothing to configure or authenticate.
- A **90-day uptime history** builds up from the moment you add the component,
  so rolled-up and collapsible components show a heatmap and uptime %. A
  provider's past can't be back-filled.
- The same **display modes** apply as for your own components.
- Each third-party component links to the provider's own status page and is
  flagged when its data is momentarily delayed.
- A provider's outage **does not** flip your page's own banner — your overall
  status keeps reflecting only the services you run.
- It counts as a regular component; there's no separate limit.

> **Info**
>
> Don't see a service you need? Almost any provider running a standard public
> status page can be added — [contact us](/contact) with the name and its
> status-page URL.

> **Also via API**
>
> Components (name, description, monitor ids and tags) are created with the
> page or updated through the [status pages API](/docs/api/status-pages).
> Third-party components are managed in the dashboard.

---

Canonical page: https://watchfor.io/docs/status-pages/components · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt