Grafana-managed alert rules are organised into evaluation groups inside a folder. What does a group actually control at evaluation time, and how should you use grouping when a folder holds many rules?

## What a group is In unified alerting, a Grafana-managed rule lives in a folder, and within that folder it belongs to a named evaluation group. The group is the scheduling unit. It carries one property that matters above all others — the evaluation interval — and it defines an ordering over its member rules. At each tick of the interval, the scheduler walks the group's rules in order and evaluates them one after another. Different groups are independent and run in parallel. So the group is simultaneously a *rate* (how often) and a *serialisation boundary* (what waits for what). ## The two levers grouping gives you **Rate matching.** Evaluation frequency should track the data and the urgency, not a global default. A rule over a metric scraped every fifteen seconds, protecting a user-facing path, justifies a short interval. A rule that runs an expensive aggregation over a day of logs does not — evaluating it every thirty seconds burns query capacity for an answer that cannot change that fast. Putting them in the same group forces one interval on both, so the cheap fast one gets slow or the expensive slow one gets hammered. Separate groups let each be right. **Isolation and load shaping.** Because a group is sequential, a rule whose query takes twenty seconds pushes back everything behind it in that group; if the group's interval is thirty seconds and the total work exceeds it, evaluations start to overrun and effectively skip. Keeping expensive rules in their own group contains that. In the other direction, having *all* rules in one group with the same interval means every query hits the data source at the same instant — a self-inflicted spike. Distributing rules across groups, and where needed offsetting them, smooths the query load. ## What a group is not This is the question's real trap. A group does not aggregate notifications. Two rules in the same evaluation group produce entirely separate alerts and separate notifications unless the *notification policy* groups them by matching labels. Nor does it create an ordering guarantee you can rely on for correctness — the sequential evaluation is a scheduling property, not a transaction; do not design a rule that assumes another rule in the group already ran and did something. ## Interaction with the pending period The pending period on a rule is enforced in evaluations. If a group's interval is one minute and a rule has a five-minute pending period, the condition must hold across five consecutive evaluations. Move that rule into a five-minute group and the same pending period now means five evaluations spanning twenty-five minutes of wall clock — the rule became dramatically less sensitive without anyone editing it. Any change to a group's interval is therefore a change to every member rule's behaviour, and pending periods should be re-checked as multiples of the new interval. ## Choosing a grouping scheme Common workable schemes: - **By cadence.** Groups literally named for their interval, so the interval is visible in the rule's location. Simple and easy to reason about, and it makes the cost of a rule explicit at authoring time. - **By cost.** A group for cheap instant queries and a separate one for heavy range queries, so the expensive ones cannot delay the cheap ones. - **By ownership.** Folders per team (which is also the permission boundary), with groups inside for cadence. This usually reads best in practice because folder permissions and rule ownership already align. Avoid the scheme that feels most natural and is wrong: grouping by *service or incident*, in the hope that the group will bundle the resulting notifications. It will not, and the rules will end up sharing an interval that suits none of them. ## Operational signals Watch for evaluation duration approaching the interval — that is the leading indicator of overrun and skipped evaluations, and it degrades exactly when the system is under stress and the queries get slower. Watch for a single group that has accumulated dozens of rules over time; it started as one interval choice and has become a serial queue. And when many rules query the same data source, remember that the data source's own concurrency limits, not Grafana's, may be the binding constraint.