Monitor groups

A monitor group is a tag-like collection of monitors that share something operationally — a service, a customer, a team ownership. Groups make incidents and status pages easier to organise.

Manage groups at Monitors → Groups.

What a group buys you

Incident link — link an incident to a group, not individual monitors. Every monitor in the group shows on the incident page.
Status page sections — render a section per group on a public status page. Customers see “API · degraded”, “Web · up” without you naming each monitor.
Alert rule scope — bind one alert rule to a group instead of listing monitor ids one by one. Adding a monitor to the group later auto-applies the rule.
Bulk filter — filter the monitors list by group for quicker navigation in big orgs.

Groups are a flat namespace — no nesting. A monitor can belong to zero, one, or many groups.

Creating a group

Monitors → Groups → New group:

Name — short label shown on status pages and incident pages.
Description — optional. Surfaced on status page sections.
Monitors — pick the monitors to include. You can edit this list later.

Adding monitors to groups

Two ways:

From the group page — Edit monitors, pick from a checkbox list.
From an individual monitor page — Settings → Groups, add the group(s) it should belong to.

Either way the membership is bidirectional; both views stay in sync.

Use in alert rules

When creating an alert rule, set the Scope to “Monitor group” and pick the group. The rule applies to every monitor in the group at firing time, including monitors added after the rule was created.

This is the cleanest way to scale alerting — define one rule per severity per group, then add or remove monitors from the group without touching alert config.

Use on status pages

Add a Section to a status page and set its source to a monitor group. Every monitor in the group renders inside the section with its current status and a configurable history strip.

Sections reorder via drag-and-drop in the status-page editor.

Tips

Keep group counts low — too many groups defeats the purpose. 3-10 groups is comfortable for most orgs. Groups themselves are not capped per plan.
Name by what customers see, not by internal infrastructure. “Checkout” beats “checkout-svc-v2”.
A monitor in multiple groups can appear in multiple status-page sections — useful when one underlying service powers several customer-facing features.