Component Status
Configure the component grid and its display order.
Component Status is the always-on grid that shows live health for each wired component. Visitors use it as the primary signal for whether your services are operational or degraded.
What visitors see
The Component Status block is the core of your status dashboard. It shows each component wired to this dashboard and its current live status (for example, operational, degraded, or in maintenance).
Unlike the other content modules, Component Status cannot be turned off. It is always part of the page. You can still use the arrows in the Content tab to move it up or down relative to incident, maintenance, and history sections.
Visitors see a grid (or compact list, if enabled on the Components tab) of your dashboard's components. Each row or card includes:
- Component name and optional description
- Current status indicator (color and label reflect the highest-severity active published event affecting that component, or operational when none apply)
- Optional uptime history bars when that feature is enabled in the Content tab
If you use component groups, visitors can expand or collapse each named group by clicking its header. Whether groups start expanded or collapsed is controlled by the Expand groups by default toggle on the Components tab — it applies to all named groups uniformly.
Which components appear
Only components you have explicitly added to this dashboard in the Components tab are shown. Adding or removing components there changes what appears on the public page, including which past events appear in history, timeline, uptime, and permalinks. See Dashboard scope.
Uptime history bars
When Uptime history is enabled, each component can show a row of small colored bars — one per recent day (1–7 days, your choice). The rightmost bar is today; earlier bars go backward in time. Uptime does not show future days (unlike the Weekly Activity, which can look ahead for scheduled maintenance).
Bar colors
| Bar color | Meaning |
|---|---|
| Green | No incident or maintenance affected this component that day |
| Red | An incident affected this component that day |
| Blue | Maintenance affected this component that day |
| Red and blue (split) | Both an incident and maintenance affected this component that day |
Which events count
Uptime bars are historical, not a live status summary. They answer: “On this calendar day, did this component overlap a published incident or maintenance window?”
Only published incident and maintenance events are included. Each bar reflects events that list this component as affected and whose start/end window overlaps that day in the visitor’s local time zone.
| Event | Included in uptime bars? | When it colors a day |
|---|---|---|
| Active incident (open, not resolved) | Yes | Every day from the incident start through today, until the incident is resolved |
| Resolved incident | Yes | Each day between the incident’s start and end (resolution) time |
| Active maintenance (in progress) | Yes | Every day from the maintenance start through today, until the window ends |
| Completed maintenance | Yes | Each day between the maintenance start and end time |
| Scheduled maintenance (not yet started) | Yes, when applicable | Only days inside the scheduled window — typically once that window has begun or overlaps a day in the lookback range. Future-only windows do not color bars until those calendar days arrive |
| Informational notice | No | Informational notices never change uptime bar colors. They appear only in Informational Notices |
| Unpublished draft | No | Events must be published to the status dashboard |
Live status vs. uptime. The colored status pill on each component row reflects the current highest-severity active published event (or operational when none apply). Uptime bars can still show red or blue for past days after an incident is resolved or maintenance is completed.
How severity is chosen for the status pill
Component status uses a live ranking pass over active published events:
- Which label wins — the highest
orderamong severities in your current Settings configuration, plus any snapshot labels on open events that no longer exist in config (for example after a rename or delete). Orphaned snapshot labels rank as high impact so the dashboard does not understate service impact. - Color and icon on the pill — taken from the snapshot captured when the event was written, or from your current severity palette when the label still exists in config. If the label was removed from Settings, the pill keeps the snapshot text but may appear in neutral gray.
Event cards and timeline entries use their own event-level severity snapshots; only the component grid combines live ranking with per-event snapshot display fields.
Visitors can click bars for days with activity to open a popover listing the overlapping events (with links to each event’s permalink). Days with no qualifying activity stay green and are not clickable.
Uptime bars are independent of the Weekly Activity chart: uptime is per component and covers your chosen 1–7 recent days; the weekly activity chart summarizes activity across the whole dashboard one week at a time.