Status pages · Free+
Component groups
Five probes flat is fine. Twenty probes flat is a mess. Component groups solve the scaling visual problem without forcing you to spawn separate pages.
Why you need it
The visual difference between a status page customers actually scan and one they bounce from is whether the monitor list reads as a map of your system.
- One-level grouping, deliberately flat. No nested sub-groups; the tree-editor UX overhead outweighs the value at typical 5-30 monitor scales. When you really need depth, two pages with two slugs works.
- Per-page sort order. Groups render in the order you set; ungrouped monitors land in an "Other services" bucket below.
- Public render adapts automatically. Pages with zero groups render flat (back-compat). Pages with groups render section headers between rows.
- SetNull on group delete. Removing a group strands its monitors into Ungrouped — their history isn't lost, just re-bucketed.
Where it pays off
Wherever your page has crossed ~10 monitors:
- SaaS with frontend + API + workers. Frontend (3 monitors), API (8 endpoints), Background workers (4 jobs) — visitor scans the relevant section.
- Multi-region setup. Group by region instead of probe type so a regional outage is visible as a contiguous block of red.
- Customer-vs-internal surfaces. Group customer-facing components first, internal infrastructure second — visitors care about the order.
Available on Free+. Already on StatusPulse? See the full config in Help →
Related
Try Component groups in StatusPulse
5 probes, 1 status page, forever. No credit card. US or EU host — you choose.