Skip to content
StatusOwlDocs

Components

Attach monitors to a status page as components, control display order and visibility, and understand how component status is rolled up to a page-level health summary.

Last updated May 9, 2026

A component is the public-facing representation of a service or subsystem on your status page — "API", "Web", "Auth", "Background workers". Visitors see a per-component health row; you control which monitors back each component, the order they appear, and whether they're shown publicly.

This page covers the lifecycle of components on a status page: attach, reorder, hide, detach. For incident reporting against a component, see Incidents.

What a component is

In StatusOwl, a component is a monitor attached to a status page. There is no separate "component" object you create from scratch — a component is a view of an existing monitor, plus per-page settings (display order, visibility). Renaming the underlying monitor renames the component automatically; the monitor's description is shown alongside.

This means every component is backed by exactly one monitor, and the component's status mirrors the monitor's last status.

Component groups are not yet implemented

A common pattern in other status-page tools is to group components under a parent ("API → Auth, Search, Webhooks"). StatusOwl does not currently support component groups — components render as a flat list. If you need hierarchical grouping, signal it by ordering related components together and using descriptive names ("API · Auth", "API · Search"). True grouping is on the roadmap.

Attaching a monitor

  1. Open the status page in the dashboard and find the Components card.
  2. Click Add Component and pick a monitor from your organization's monitor list. A monitor can appear on multiple status pages — attaching it to one page does not detach it from another.
  3. The monitor is added to the bottom of the component list, visible by default.

The component immediately reflects the monitor's most recent check result. You don't need to wait for the next interval; the public page will pick up the existing status on the next cache refresh (within ~15 seconds).

Display order

Components render in the order set on each status page. To reorder:

  1. Open the status page and the Components card.
  2. Drag a component to its new position, or use the per-row Move up / Move down controls.

The new order is persisted as a display_order value on the page-component link; it doesn't affect the monitor itself or any other status page that shares the monitor.

A practical pattern: order components by user-visible severity — your front door (marketing site, login) first, then the things behind it (APIs, internal tools). Visitors form their first impression from the top of the page, so put the highest-leverage signals there.

Hiding a component

Each component has a per-page visibility toggle. A hidden component is not rendered on the public page but still exists in the dashboard and still receives data from the underlying monitor — useful when you want to keep a component configured but don't want to expose it during a noisy incident or while iterating.

Hidden ≠ deleted. The component is still attached to the page; flip the toggle back to show it again.

Per-component metadata

The component inherits its label, description, and current status directly from the underlying monitor. To rename, edit the description, or change target settings, edit the monitor itself — the change appears on every status page the monitor is attached to.

There are currently no per-component icons or link-out URLs. Use a descriptive monitor name as the visible label.

Component status and page rollup

Monitors have a binary status — up or down. The public status page turns those raw states into the three-level rollup that visitors see:

  • Operational — every visible component is up.
  • Degraded — at least one visible component is down.
  • Unknown — no recent data, or no components configured yet.

There is no "partial outage" or "major outage" tier on the rollup — the gradient is binary at the component level. To convey severity to visitors, post an incident with the appropriate impact (minor, major, critical); the incident banner sits above the component list.

Status mirrors the monitor exactly

If a single monitor goes down at 14:03 and recovers at 14:04, the component flickers down → up and the page-level rollup briefly shows Degraded. To filter transient blips out of the public view, use the multi-region setup to require sustained failure before the page surfaces it, or rely on the auto-incident threshold (3 consecutive down results) to control when a public incident opens.

Detaching a component

Detaching removes the component from the page without deleting the underlying monitor. The monitor and its history stay intact and any other status page the monitor is attached to is unaffected.

  1. Open the Components card.
  2. Click the ⋯ menu next to the component → Remove.
  3. Confirm.

If you want to delete the monitor itself (along with its history), do that from the Monitors page — detaching here only severs the page-component link.

Best practices

  • One monitor per user-visible service. Don't attach an internal probe the public won't recognize. If the public won't recognize a name, hide it or don't attach it.
  • Order by severity from the visitor's view. Front door first, deeper services after.
  • Hide while testing. When you spin up a new monitor, attach it hidden, watch a few intervals to confirm it's stable, then unhide.

See also