# Alert rule attached to panel > The chart shows the line to watch; the viewer wants to be told when it's crossed. - Canonical: https://patterns.konigi.com/dashboards/alert-rule - Group: Product mechanics - Level: flow - Status: published - Updated: September 10, 2026 - Also called: threshold alert, monitor from chart --- ## Problem Someone is looking at a chart and realises they cannot watch it forever. The thing they want is for the chart to watch itself, and the moment of wanting that is while looking at the chart, not while sitting in an alerting console three menus away. ## Solution Let a rule be created from the panel, carrying the query with it. The line you just drew becomes the condition, and the panel and the alert stay describing the same thing. The proximity is the point. An alert defined elsewhere drifts from the chart within a quarter, and then two numbers exist: the one on the wall and the one that pages someone. Attaching the rule to the panel makes them one object, which is the only reliable way to keep them equal. What the pattern must not do is make alerting easy enough to be thoughtless, and here the Google SRE book is the correction worth carrying into the UI. Every page should be actionable. Every page response should require intelligence—if a page merely merits a robotic response, it shouldn't be a page. And catching symptoms is worth much more effort than catching causes, with causes reserved for the very definite and very imminent. A one-click "alert on this panel" button is at odds with all three, because the easiest rule to create is a static threshold on a cause-shaped metric like CPU, which is exactly the page that wakes someone for something no user noticed. The interface should make the useful rule as easy as the tempting one: ask for duration as well as threshold, ask what happens on no data, and ask who it goes to. That no-data question is the one products get wrong most often. Grafana treats it as a first-class decision with four mappings—Set No Data state, Set Alerting state, Set Normal state, Keep last state—and defaults to creating a `DatasourceNoData` instance rather than quietly calling silence healthy. A rule that cannot distinguish "the metric is fine" from "the metric stopped arriving" is a rule that will be silent during exactly the outage it was written for. ## Use when The metric has a defensible limit, someone owns the response, and the chart is where people already look. Best where the panel and the rule genuinely describe one thing. ## Don't use when Nobody would act on it. An alert nobody can respond to trains a team to ignore the channel, and the cost lands on the next alert rather than this one. Also avoid it when the condition needs several signals: a per-panel rule encourages single-metric thinking. ## Trade-offs Panel-bound rules scale badly. Two hundred panels means two hundred rules with two hundred owners, each edited by whoever last touched the dashboard. Duplication follows, because the same condition gets attached to the same metric on four dashboards, and now one incident pages four times. The rule's lifecycle also gets tied to the panel's: delete or restructure a dashboard and the alerting goes with it, usually unnoticed. And a static threshold on a chart that autoscales looks reasonable while the traffic pattern quietly outgrows it. ## Checklist - Is this symptom or cause, and if cause, is it definite and imminent? - Could a person act on this at 3am, and would the action be more than restarting something? - Is there a duration condition, or does a single spike page? - What happens on no data, and was that chosen deliberately? - Does the rule use the same query as the panel, or a copy that can drift? - Who owns this rule, and do they know? - Does the same condition exist on another dashboard? - What happens to the rule if the panel or dashboard is deleted? - Is the threshold still right for current traffic, and when was that checked? - How often has this fired, and how often did it lead to action? ## Compare **Grafana** creates alert rules from panels and forces the no-data decision at rule-creation time with four explicit mappings, which is the most honest treatment of the failure mode most products leave implicit. **Prometheus** keeps rules in version-controlled config rather than in a UI, so they get reviewed, diffed and owned like code, at the cost of the create-it-while-looking-at-it immediacy this pattern is named for. **Datadog** makes the monitor the primary object and lets dashboards reference it, which inverts the relationship and stops the same condition being redefined per dashboard. **Sentry** derives alerting from issue behaviour—new, regressed, spiking—rather than from a threshold on a line, which sidesteps threshold staleness entirely and only works because its data has a natural notion of "new". ## Related Threshold line is the visual half of this pattern and should be drawn from the same number. Metric targets is where the limit ought to be defined and owned. Error and stale state covers what the panel shows when the same condition that should alert has instead produced silence. Semantic status color is how the fired state reads on the page. Status history is the record of what this rule has actually done. ## Examples ### Grafana (Grafana Labs) The reference implementation for panel grids, template variables, and stat panels; most other tools are defined by how they differ from it. **Examples / Alert List** — captured September 10, 2026, Grafana Play (signed out; no version string exposed). operational, medium density, dark theme, desktop-web. Seven alerts, and the durations are the story. "Browser market share > 50%" has been firing for 17 days, 15 hours and 12 minutes. Two more have been firing for over three days. An alert that has been true for two and a half weeks is not telling anyone anything—it has become part of the background, and the list it sits in is now a list you scroll past. The other thing worth reading is the names. Six alerts, six conventions: a full sentence, a metric identifier in snake case, a camel-case service name, a two-word phrase, and two that just say "Dynamic". Somebody arriving at this list at three in the morning cannot tell from the names what is broken or how badly, which is work the naming could have done for free. Hotspots in this capture: - [Alert rule attached to panel](https://patterns.konigi.com/dashboards/alert-rule) *(this pattern)* — Seven rules in six naming conventions. Nothing in the list conveys severity or subject. - [Alert rule attached to panel](https://patterns.konigi.com/dashboards/alert-rule) *(this pattern)* — Firing for 17 days. Still actionable, in principle; nobody has acted for two and a half weeks. - [Semantic status color](https://patterns.konigi.com/dashboards/semantic-status-color) — Pending rather than firing: the threshold is met and the duration isn't. Two states, both named. - [Filter bar](https://patterns.konigi.com/dashboards/filter-bar) — "1 instance, 24 hidden by filters"—the list saying what it is not showing you. - [Drill-down](https://patterns.konigi.com/dashboards/drill-down) — The route from an alert back to the rule that defined it, on every row. ## Related patterns - [Threshold line and region](https://patterns.konigi.com/dashboards/threshold-line) — A flat metric has a line it must not cross, and the chart should show where that line is. - [Metric targets](https://patterns.konigi.com/dashboards/metric-targets) — The viewer wants the dashboard to know what 'good' is. - [Error and stale state](https://patterns.konigi.com/dashboards/error-and-stale-state) — One panel's query failed and the viewer must not mistake it for a zero. - [Semantic status color](https://patterns.konigi.com/dashboards/semantic-status-color) — State has to be readable before the number is. - [Status history](https://patterns.konigi.com/dashboards/status-history) — The viewer needs to see when something was up, down, or degraded, over days, in one row. ## Sources - [Google SRE Book, Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/) - [Prometheus, Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) - [Grafana, No Data and Error states in alerting](https://grafana.com/docs/grafana/latest/alerting/fundamentals/alert-rule-evaluation/nodata-and-error-states/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.