Name services
the way you ship.
Represent APIs, products, and systems as components. Map monitors for live health, then decide what appears on the public status page — one vocabulary from probes to subscribers.
Monitors roll up · visibility & order follow component settings
What components give you
One row per service people recognize
Stop explaining mismatched names in side channels. The same rows power internal views and the page customers open.
Shared vocabulary
One named unit per service — description and visibility separate from internal monitor names.
Monitor mapping
Attach checks so probe results roll into component health without cluttering the public page.
Public visibility
Show or hide each component on the status page without deleting it from the project.
Groups & sections
Organize components into groups that render as scannable sections on the status page.
Incident impact
Reference affected components so timelines and public status stay aligned when things break.
Stable ordering
Lead with critical services so the page matches how you communicate during incidents.
From checks to customers
Health that rolls up
without the noise.
Keep granular monitors in the dashboard. Components give you the readable rows — and the same model feeds incidents, maintenance, and the public page.
- Map many monitors to one component
- Pause checks without deleting the row
- Per-region signals aggregate cleanly
Define the service
Name the component the way customers and docs already talk about it.
Link the checks
Attach monitors so live health drives the row when you want automation.
Publish with control
Set visibility, group, and order for a status page that stays scannable.
Services customers already recognize
Named rows
Live health without page clutter
Monitor-linked
Sections that scan during incidents
Grouped
Same components across every surface
Shared model
Define components
with clarity.
Create an account, add components in your project, and connect monitors when you are ready.