Grafana lets you write alert rules that Grafana itself evaluates, or rules that are pushed down to be evaluated by the metrics backend. What does each choice change operationally, and how would you decide for a large multi-team estate?

## Two evaluation homes Unified alerting can produce a rule in two shapes, and the difference is *where evaluation happens*. A **Grafana-managed** rule is stored in Grafana, scheduled by Grafana, and evaluated by Grafana issuing queries out to whatever data sources it references. Its instance state lives in Grafana's database and its firing alerts go to the embedded Alertmanager, which owns policies, contact points, silences and mute timings. A **data-source-managed** rule is authored through Grafana but written into the metrics backend's own rule store. From then on the backend evaluates it on its own schedule; Grafana can display it but is not in the path. Notifications leave through that ecosystem's own routing component. ## What Grafana-managed buys - **Expressions.** Reduce, Math, Threshold, Resample run server-side in Grafana, so a rule can express things the data source's query language cannot, and can compare results across sources. - **Cross-data-source rules.** Query A from one backend, query B from another, combine them. There is no other place this can happen. - **Any data source.** Backends with no rule-evaluation capability of their own — many logging, tracing, SQL and cloud-API sources — can only be alerted on this way. - **Uniform semantics.** Per-rule no-data and error handling, one state model, one place to see every rule regardless of the underlying system, and one permission model tied to folders. ## What it costs - **Grafana becomes tier-one.** If Grafana is down or its database is unavailable, those rules are not evaluated. That forces a real high-availability deployment: several instances with shared state, an alerting cluster so the embedded Alertmanager instances gossip and deduplicate notifications rather than each sending its own, and monitoring of the alerting subsystem itself. - **Evaluation load is Grafana's problem.** Every rule is a query issued over the network at its group's interval. Rule count multiplied by frequency multiplied by query cost is a capacity number someone has to own, and it degrades under exactly the conditions that make alerts matter. Evaluation duration approaching the group interval is the leading indicator. - **State is a database.** Instance state and history are persisted; at large rule counts that store and its retention become an operational concern of their own. ## What data-source-managed buys - **Evaluation next to the data**, so no cross-network query per evaluation and far better scaling for high rule counts over one backend. - **Independence from Grafana's availability** for the rules that matter most about that backend. - **The backend's own ecosystem** — its rule language, its recording rules, its existing routing and its existing operational tooling, which a metrics platform team may already run well. And what it costs: no expressions, no cross-source rules, the source's query language only, its state and no-data semantics rather than Grafana's, and split ownership of routing between two systems, which is the part that hurts the humans. ## Deciding for an estate The decision is rarely all-or-nothing; it is a policy about which rules go where. 1. **Default to the data's home.** If a rule reads one metrics backend that has a capable ruler and the platform team runs it, put the rule there. It scales, it survives Grafana, and it lives with the recording rules it depends on. 2. **Use Grafana-managed for what only it can do.** Cross-source correlation, sources without a ruler, and rules that genuinely need server-side expressions. 3. **Do not split routing casually.** Two notification systems mean two places to silence, two sets of contact points and two mental models during an incident. Either centralise routing in one Alertmanager that both paths feed, or accept the split deliberately and document which alerts come from where. 4. **Everything as code.** Whichever home, rules should be provisioned from version control rather than clicked into a UI, so they are reviewable, diffable and restorable. Ad-hoc UI editing at estate scale produces rules nobody can account for. 5. **Enforce a shared label vocabulary across both paths.** Routing, silencing and grouping all key on labels; if the two paths use different names for team or severity, no policy can treat them uniformly. 6. **Monitor the alerting system itself,** from outside it. Evaluation duration, evaluation failures, notification delivery errors and a periodic synthetic alert that must arrive end to end — a monitoring system that fails silently is worse than none, because it is trusted.