Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt

Use this file to discover all available pages before exploring further.

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

CapabilityWhere it shows up
Composite status badgeDashboard resource-group list and detail page; queryable via GET /api/v1/resource-groups/{id}
Group-scoped uptimeAggregated uptime % over the standard 24h / 7d / 30d / 90d windows
Member health breakdownDetail view drills into each monitor’s last result and each dependency’s current incidents
Alert routing inputNotification policies can match on resource group via tag pivots — pair with tags
Status page surfacePublic status pages can render a resource group as a single component for cleaner customer-facing layouts

​
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

Member statusGroup contribution
All members OPERATIONALGroup is OPERATIONAL
One or more members DEGRADED, none DOWNGroup is DEGRADED
One or more members DOWNGroup is DOWN
Member is in a maintenance windowExcluded from the rollup for the duration of the window
Member dependency has an INVESTIGATING incidentSurfaced as DEGRADED in the rollup unless the underlying provider classifies it as MAJOR
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.