Skip to main content
A resource group rolls up the health of multiple monitors and tracked dependencies into a single composite indicator. Use resource groups to give a team, service, or product surface its own “is everything okay?” health view without forcing consumers to reason about every underlying check.

​
Mental model

A resource group is a labelled set of references:
  • Monitors you own (HTTP, TCP, DNS, ICMP, MCP Server, Heartbeat).
  • Status data services you depend on (e.g. github, aws-s3, stripe) — see Dependencies.
  • Optional specific service components (e.g. aws-s3 → us-east-1).
The group’s overall status is computed from the worst-status member, with the same severity ladder used by incidents (OPERATIONAL → DEGRADED → DOWN).

​
What you get

​
Choosing a grouping strategy

Resource groups work best when the membership maps to something a human cares about as a unit — usually a product surface or a team’s on-call boundary. Examples:
  • “Payments” — Stripe checkout monitor + AWS S3 (us-east-1) dependency + internal payments-api health check.
  • “Auth” — Auth0 dependency + login.example.com HTTP monitor + JWT-issuance heartbeat.
  • “Marketing site” — www.example.com HTTP monitor + Cloudflare dependency + Mailgun dependency.
Avoid one mega-group covering “everything” — that defeats the point of composite health and produces a near-permanent yellow status.

​
Managing resource groups

  1. Open Resource Groups in the sidebar.
  2. Click New Resource Group, name it, and add a description.
  3. Add monitor and dependency members from the searchable picker.
  4. Save — the group’s composite status appears immediately on the list view.

​
Composite status semantics

Rollups are recomputed on every check result and every dependency status change — there’s no batched lag.

​
Resource groups vs tags

Both organize resources, but they answer different questions:
  • Tags are attribute labels (env=prod, team=payments). They make filtering and routing easy but don’t have a composite health concept.
  • Resource groups are membership sets with a computed status. They are the right primitive for “is X up?” answers and for status-page rollups.
It is normal to use both — tag a monitor team=payments for routing, and add it to the Payments resource group for health rollup.

​
Lifecycle notes

  • Deleting a resource group does not delete its members. Membership is a join table; the underlying monitors and dependencies are untouched.
  • Removing a member from a group is instant and recomputes the rollup immediately.
  • Resource groups are workspace-scoped — you cannot share a group across workspaces.

​
Next steps

Resource group health guide

End-to-end walkthrough for building a group + status-page surface.

Dependencies

Add third-party services as group members.

Tags

Compare with resource groups for organizing monitors.

resource-groups CLI

Manage from the command line.