> ## 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.
# Resource Groups
> Aggregate monitor and service health into DevHelm resource groups for unified status views
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](/status-data/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
| Capability | Where it shows up |
| --------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Composite status badge** | Dashboard resource-group list and detail page; queryable via `GET /api/v1/resource-groups/{id}` |
| **Group-scoped uptime** | Aggregated uptime % over the standard 24h / 7d / 30d / 90d windows |
| **Member health breakdown** | Detail view drills into each monitor's last result and each dependency's current incidents |
| **Alert routing input** | Notification policies can match on resource group via tag pivots — pair with [tags](/platform/tags) |
| **Status page surface** | Public 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.
```bash theme={null}
devhelm resource-groups list
devhelm resource-groups create --name "Payments" --description "Checkout-critical surfaces"
devhelm resource-groups update 42 --name "Payments (v2)"
devhelm resource-groups delete 42
```
Membership editing through the CLI happens via `devhelm deploy` — define members in `devhelm.yml` and re-deploy.
Full reference: [`devhelm resource-groups`](/cli/commands/resource-groups).
```bash theme={null}
curl -X POST https://api.devhelm.io/api/v1/resource-groups \
-H "Authorization: Bearer $DEVHELM_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "Payments", "description": "Checkout-critical surfaces"}'
```
Member management is exposed under `/api/v1/resource-groups/{id}/members`.
## Composite status semantics
| Member status | Group contribution |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| All members `OPERATIONAL` | Group is `OPERATIONAL` |
| One or more members `DEGRADED`, none `DOWN` | Group is `DEGRADED` |
| One or more members `DOWN` | Group is `DOWN` |
| Member is in a [maintenance window](/incidents/maintenance-windows) | Excluded from the rollup for the duration of the window |
| Member dependency has an `INVESTIGATING` incident | Surfaced 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
End-to-end walkthrough for building a group + status-page surface.
Add third-party services as group members.
Compare with resource groups for organizing monitors.
Manage from the command line.