# Resource groups

> Bundle related resources so they start, stop, and report together.

Source: https://zop.dev/docs/zopnight/concepts/resource-groups

---

A resource group is a named bundle of resources you want to manage as one unit; a dev cluster, a staging stack, a customer's tenant. Once you've grouped them, you can attach a single schedule, run bulk start/stop, and see cost rolled up at the group level.

![Groups page with cards for Trading, Risk, Compliance, Payments, Market Data, and Reference Data workloads, each showing resource count and budget usage](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/9a15a23e-d1e3-444d-b7cc-2ec4c44181e1-groups.png)

*The Groups page; related resources bundled per team, each with a resource count and budget rollup.*

## When to use a group

Use groups when **the same lifecycle policy applies to everything inside**. If your "staging" environment is twelve resources that should all sleep on weeknights and weekends, that's a group. If three of the twelve need to stay on, they belong to a different group (or to no group at all).

**Note**

Each resource can belong to **at most one group**. ZopNight enforces this with a database-level lock to prevent two schedules from fighting over the same resource. If you try to add a resource that's already in another group, you'll be asked to remove it from the first group first.

## Create a group

**Open Groups → New group**

  Give it a name and an optional description. The description shows up in the group list, so use it to explain *why* this group exists; future-you will thank you.

**Add resources**

  Search by name or UID, or filter by type and region. Tick the resources you want and click **Add**. Bulk selection is supported.

**(Optional) Attach a schedule**

  Pick an existing schedule or create a new one. All current and future members will follow it. See [Schedules](https://zop.dev/docs/zopnight/concepts/scheduling) for cron syntax.

## Sequenced execution

Some stacks have dependencies; databases need to be up before app servers; app servers need to be up before workers. ZopNight runs group start/stop in a configurable order. See [Scheduling](https://zop.dev/docs/zopnight/concepts/scheduling) for the same ordering model as it applies to schedules.

| Mode | Behaviour |
|---|---|
| **Auto** (default) | Storage first, compute second, applications third. Works for most stacks. |
| **Custom** | You define the exact order. Use this when auto-ordering doesn't match your dependency graph. |

You can also set a **delay between resources** in minutes. A 2-minute delay between a database start and an app server start gives the DB time to accept connections before the app tries to use it.

**Tip**

If you're not sure whether you need sequencing, start with auto and watch the first run. Sequencing matters most for `Start`; `Stop` is usually fine in reverse order or in parallel.

## Bulk start and stop

Group → **Start all** or **Stop all** runs the action across every member through the worker pool. Four workers run in parallel, ordering and delays are honoured, and a single banner shows progress so you don't have to refresh.

## Budgets per group

Each group can have a monthly budget. ZopNight tracks live spend against it from your cost records (no separate counter to keep in sync; spend is computed on every read).

**Green**

    Spend is below the alert threshold. Nothing to do.

**Yellow**

    Spend has crossed the alert threshold but is below the budget. Time to look.

**Red**

    Spend is over budget for the period. ZopNight fires a notification to the channel attached to the budget.

Budget alerts go through the notification service. Slack, Teams, Google Chat, or webhook.

## Overrides on a group

Just like resources, groups can be overridden ON or OFF for a window. Setting an override at the group level applies to every member. Useful for "everyone stays up tonight, we're cutting a release."

See [Overrides](https://zop.dev/docs/zopnight/concepts/overrides) for the full behaviour.

## Deleting a group

Deleting a group **does not delete its resources**: the resources keep running and stay in the inventory. The group's schedule attachment, sequencing, and budget go away.

Group delete is a soft delete. You won't see deleted groups in the list, but the audit log keeps the trail.
