Grafana Alert Rule Conditions

An alert rule decides when something deserves human attention. A badly built rule wakes people for nothing, and a missing rule lets real trouble slip by. Conditions give you precise control over what counts as trouble, how long it must last, and what Grafana does when data goes missing.

The Smoke Detector Analogy

A smoke detector samples the air every moment. It stays quiet for a burnt toast smell and sounds off for thick smoke. A good alert rule behaves the same way. It measures a value, compares it with a limit, and waits long enough to be sure before it raises the alarm.

The Three Parts of a Rule

+-----------+     +----------------+     +--------------+
|  Query    | --> |  Expressions   | --> |  Condition   |
| (get data)|     | (shrink, test) |     | (fire or not)|
+-----------+     +----------------+     +--------------+
   A: CPU            B: Reduce(A)           C: B > 85
   per minute        = last value           true / false

Query

The query fetches raw data from a data source. It returns a series of values over time, such as CPU usage for the past ten minutes.

Expressions

Expressions process query results on the Grafana side. Three types matter most.

• Reduce collapses a series of values into one number using a function such as Last, Mean, Min, or Max.
• Math performs calculations, such as dividing errors by total requests.
• Threshold compares one number with a limit and returns true or false.

Condition

The condition names the final expression. When that expression returns true, the rule moves toward firing.

Build a High CPU Rule

Step	Setting
A	Query: average CPU percentage per instance
B	Reduce: function Last, input A
C	Threshold: input B, is above 85
Condition	C

The rule reads the newest CPU value and compares it with 85. A value of 91 sets the condition to true.

Evaluation Group and Interval

Rules live inside evaluation groups. A group has one interval, such as 1 minute, and every rule in the group runs on that schedule. Rules in one group run in order, which suits rules that depend on each other. Choose short intervals for urgent services and longer ones for slow-moving data.

The Pending Period

The pending period is the time a condition must stay true before the alert fires. A pending period of 5 minutes ignores short spikes and reacts only to lasting problems.

CPU %
 90 |      /\    /\/\/\/\/\/\/\/\____
 85 |- - -/- -\- / - - - - - - - - - -  limit
 70 |____/    \/
    +-----------------------------------
         spike   |<-- pending 5 min -->| FIRING
         (ignored)

The first spike drops below the limit before five minutes pass, so no alert fires. Another stretch stays above the limit for the full period, so the alert fires.

Alert States

State	Meaning
Normal	The condition is false
Pending	The condition is true, and the timer runs
Alerting	The condition stayed true for the full pending period
NoData	The query returned nothing
Error	The query or an expression failed

Normal --> Pending --> Alerting --> Normal
              |                     (condition clears)
              +--> Normal           (condition clears early)

Handling Missing Data and Errors

Silence from a data source can mean peace or disaster. Each rule lets you choose the response.

No Data Choices

• NoData sets the rule to the NoData state.
• Alerting treats missing data as a failure.
• Normal treats missing data as healthy.

Error Choices

• Error sets the rule to the Error state.
• Alerting treats the failure as an alert.
• Normal ignores the failure.

Pick Alerting for no data on a service that must always report, such as a heartbeat metric.

Labels and Annotations

Labels are tags such as team=payments or severity=critical. Notification policies read labels to decide who gets the message. Annotations carry descriptive text, such as a summary and a link to a fix guide. Write a summary that a sleepy engineer understands at 3 AM.

Rule Design Checklist

• Alert on symptoms users feel, such as slow pages, before causes such as high CPU.
• Set a pending period that matches the real cost of waiting.
• Add labels for team and severity on every rule.
• Test the rule with the preview button before you save it.
• Review noisy rules monthly and adjust or delete them.