DevOps & Cloud · Alert noise reduction
QuietPager
Quieter nights for on-call.
Find the alerts that wake people for nothing, see what on-call really costs, and get the exact configuration change that fixes each one.
$ alert-tuner review --pagerduty --days 30 --tz +05:30
240 pages from 6 alerts (56 a week)
200 pages (83%) came from alerts flagged as noise; about 83 of 95 on-call hours
AT003 HighCPU: pages, then clears by itself (145 pages)
AT002 DiskAlmostFull: flapping (40 pages)
AT006 APIErrorRate: fires together with PostgresTooManyConnections
$ alert-tuner review ... --fixes fixes.yml
Wrote fixes.yml
The problem
On-call teams are paged dozens of times a week, mostly by alerts that clear themselves, flap around a threshold or fire alongside another alert. People stop trusting the pager, sleep badly and eventually leave, and nobody can say which alerts to fix first.
What it does
Reads a month of history from PagerDuty, Opsgenie or Prometheus, or a CSV or JSON export from any paging tool
Finds ten kinds of noise: self-resolving, flapping, ignored, always-firing, duplicate, storming, slow-to-acknowledge, low-severity and night-heavy alerts
Shows the loudest alerts, who carried the pages and how many came at night or at weekends
Turns noise into on-call hours, so the cost is a number a manager can act on
Writes the fixes: for: and keep_firing_for on Prometheus rules, Alertmanager inhibit rules, grouping and routes
Lints Prometheus rule files and PrometheusRule objects before they page anyone
Night and weekend in your own time zone; filter by service or team
How it works
- Connect PagerDuty, Opsgenie or Prometheus, or export a month of alerts
- Review the noise report and the fixes file with the team
- Apply the changes and re-run a month later to see pages fall
Works with
Runs in your CI
# Check alerting rules on every change
alert-tuner lint rules/
# Monthly on-call review
alert-tuner review --pagerduty --days 30 --format html --out review.html
Your data
- Read-only API keys; it never changes routing or silences anything.
- Suggested changes are written to a file for you to review and apply.
- Runs on your machine or in CI.
Who it's for
Questions
What counts as noise?
Alerts that clear before anyone can act, flap, are rarely acknowledged, always fire, fire alongside another alert, storm across many instances, or page at warning level.
How do we prove it worked?
Run it again a month later: pages per week, night pages and the share of noise should all fall.
Related
Often used with QuietPager
BlastRadar
Change impact analysisKnow what a change will touch. Before a release, see every service a change can affect and the line of code that links it. After the release, confirm those services are still healthy.
$300–600 (₹10,000–20,000 in India)View product → DevOps & CloudSLOStudio
SLOs and error budgetsReliability you can measure. Define each SLO in a few lines and get correct burn-rate alerts, an error budget everyone understands, and a release gate, on the monitoring you already run.
$1,500–3,000 (₹40,000–80,000 in India)View product → DevOps & CloudTestScope
Test impact selectionRun the tests that matter. Every pull request runs the tests its change can affect, each with a stated reason, and the full suite whenever a change is too broad to trust.
$1,000–2,500 (₹25,000–60,000 in India)View product →See QuietPager on your own data
A 30-minute call. We run the product on your export, repository or document and walk you through the results.