BlogDetection

Prometheus alerting rules that don't cry wolf

Write alerts on symptoms with for-durations and good labels so on-call gets pages that actually mean something.

Sep 30, 2025·10 min readIntermediate

Most alerting setups page too much and mean too little. The fix is to alert on symptoms users feel (error rate, latency, saturation), require them to persist with a for: duration, and label them so routing and silencing work. An alert that fires and resolves in 30 seconds is noise.

A rule that means something

alerts.yml
groups:
- name: api
rules:
- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{code=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) > 0.05
for: 10m
labels: { severity: page }
annotations:
summary: "5xx rate above 5% for 10m"

Symptoms, not causes

What to alert on
Cause alerts (noisy)
CPU > 80%
a pod restarted
disk 70% full
high memory
Symptom alerts (useful)
error rate up
p99 latency up
queue not draining
disk full in 4h
for: kills flapping
Without a for-duration, a one-scrape blip pages someone. Ten minutes of sustained breach is a real problem worth waking up for.

Route by severity

alertmanager.yml
route:
receiver: slack
routes:
- matchers: [severity="page"]
receiver: pagerduty
- matchers: [severity="ticket"]
receiver: jira
Go deeper in a courseAdvanced Linux securityDetection, audit pipelines, and alert quality that scales.View course

Related posts