Grafana alerting

Both models end at the same place conceptually — a firing alert grouped, routed, and delivered to a receiver — but they start evaluation in different processes:

Grafana ships with its own embedded, Prometheus-compatible Alertmanager (part of Grafana’s unified alerting system) that notification policies route through by default; a data source of type Alertmanager can be pointed at that internal instance, at a standalone Prometheus Alertmanager, or at a Mimir/Cortex Alertmanager instead, and Grafana’s routing then targets whichever is selected as the default data source for alerting — so "Grafana-managed alerting" and "using Grafana’s own internal Alertmanager" are independently choosable, not the same decision. See Grafana Alerting for the full architecture.

A Grafana-managed alert rule is one or more queries (A, B, …​) against any data source, reduced by an expression, and compared against a threshold — the condition — on an evaluation interval set per evaluation group, analogous to a Prometheus rule group’s interval:

data mirrors what the alert-rule editor’s Query and condition step builds: one or more data-source queries (A, B), plus a built-in expr "expression" data source (math, reduce, resample, or threshold) that combines their results into the boolean condition refId. for, labels, and annotations mean the same thing here as on a Prometheus alerting rule — the pending-before-firing delay, routing metadata matched by notification policies below, and human-readable text — which is deliberate: a team moving a rule from Prometheus to Grafana-managed keeps the same mental model, only the query layer changes. See Grafana Alerting for the rule editor, the expression types, and the full provisioning-file schema.

A notification policy tree is Grafana’s equivalent of Alertmanager’s route block from Alertmanager: a default policy plus nested child policies, each matching on label selectors and, on a match, either handling the alert with its own contact point and grouping/timing settings or continuing to evaluate its children.

object_matchers, group_by, group_wait/group_interval/repeat_interval, and continue are the same grouping and timing knobs Alertmanager’s own route block uses — see Alertmanager for how each behaves — because Grafana’s internal Alertmanager implementation is an Alertmanager. The difference is only where the tree is authored and stored: a Grafana-managed alert’s labels (from the rule above) are what a notification policy’s object_matchers match against, exactly as an Alertmanager route matches a Prometheus alerting rule’s labels.

A contact point is Grafana’s equivalent of an Alertmanager receiver: a named delivery target — email, Slack, PagerDuty, webhook, OpsGenie, and dozens more integrations — that a notification policy points to by name. A contact point can hold several integrations, all notified when it fires:

Contact-point notification templates use the same underlying Go templating as Alertmanager’s templates, so {{ .Labels.job }}/{{ .Annotations.summary }}-style expressions carry over from an Alertmanager configuration with only minor adjustment. Provisioning both files above (via file-based provisioning, Terraform, or the HTTP alerting-provisioning API) keeps notification policies and contact points in version control the same way alertmanager.yml is, rather than left as UI-only edits.

Because Grafana’s routing is itself Alertmanager-shaped, switching where it delivers is a data-source change, not a rule or policy rewrite: add an Alertmanager-type data source pointed at the external instance, set it as the alerting default, and Grafana’s notification policies and contact points stop applying — the external Alertmanager’s own route/receivers configuration takes over, exactly as if the alerts had come from Prometheus directly. This is the common shape for a mixed estate: Grafana keeps evaluating the data sources Prometheus cannot, but every alert — Grafana-managed or Prometheus-native — is routed and silenced in one place. See Grafana Alerting for configuring the Alertmanager choice per organization, and Alertmanager for the receiver/route configuration an external instance still expects.

Continue with Security & Production Operations, or back up to Grafana: Dashboards & Visualization for the panels these alert rules typically sit alongside.