Events versus incidents
An event is one emitted notification. A unique incident is the operational condition technicians should manage as one piece of work. Counting both exposes repeated notifications without erasing the underlying problem.
23 fields · 8 worked examples · Public CSV · No signup
Alert noise baseline worksheet.
A loud monitoring system is not automatically a well-monitored system. Establish a 14-day baseline, separate raw events from real incidents, record what responders acted on, and repeat the measurement after each approved change.
Download the worksheetBuild the monitoring policyApply the 24-control reduction checklistBuild an escalation matrixInspect the source
What the worksheet distinguishes
False positives versus non-actionable signals
A false positive says the asserted condition was not present. A valid but non-actionable observation may still be useful for reporting. Define the distinction before classifying records.
Duplicate volume
Repeated events for the same condition, scope, and time window belong to one incident when your documented correlation rule says they do. Preserve the raw event count so the compression is auditable.
Operational outcomes
Volume alone is incomplete. Track acknowledgement and resolution time, after-hours load, ownership, the approved tuning action, and the expected observable result.
A repeatable 14-day method
Freeze definitions first
Document the event source, unique-incident correlation rule, false-positive definition, actionable definition, working hours, and measurement timezone. Do not change them midway through a baseline.
Collect two representative weeks
Export raw alert events and the resulting ticket or incident records. Include weekdays, weekends, maintenance windows, and ordinary customer activity; annotate exceptional outages or migrations.
Reconcile to work performed
For each signal, count total events, unique incidents, duplicates, false positives, actionable incidents, and after-hours events. Link evidence without placing passwords, tokens, sensitive payloads, or customer secrets in the sheet.
Change one mechanism at a time
Choose a bounded adjustment: persistence window, threshold, maintenance behavior, routing, deduplication key, recovery correlation, or device-class policy. Security and loss-of-control alerts require explicit risk review before suppression.
Repeat and compare
Run the same measurement for another representative window. Keep the change only when noise falls without hiding actionable incidents, worsening response, or creating uncovered scope.
Core formulas
| Measure | Formula | How to read it |
|---|---|---|
| Duplicate rate | duplicate_events / total_events | Share of emitted events that repeated an already-correlated incident. |
| Event-to-incident compression | 1 - (unique_incidents / total_events) | How much raw alert volume collapses after correlation. Report the counts beside the percentage. |
| False-positive rate | false_positive_incidents / unique_incidents | Share of investigated incidents where the asserted condition was not present under the documented definition. |
| Actionable yield | actionable_incidents / unique_incidents | Share of incidents that required a technician decision, communication, remediation, or tracked follow-up. |
| After-hours burden | after_hours_events / total_events | Share of emitted volume outside the approved service window; interpret alongside severity and on-call policy. |
| Volume change | (after_total - before_total) / before_total | Direction and size of event-volume change after tuning. Do not treat a reduction alone as success. |
Decision guardrails
Do not tune from volume alone
Review missed detections, severity, affected scope, response time, customer impact, and evidence quality with the counts.
Keep security coverage explicit
Suppression, recovery, and correlation rules for protection failures, privileged activity, remote access, or loss of control need a named risk owner.
Separate correlation from deletion
Grouping events into one incident should not destroy the underlying event history needed for investigation, audit, or later rule review.
Require a rollback condition
Record what result would reverse the change: a missed actionable incident, slower acknowledgement, uncovered scope, or degraded customer communication.
Primary guidance behind the method
Page only for urgent, actionable conditions
Google SRE's monitoring guidance distinguishes pages, tickets, and logging and asks whether an alert is urgent, actionable, user-visible, and non-duplicative. Those questions are why this worksheet separates events, incidents, actionability, acknowledgement time, and after-hours load.
Alert on symptoms and preserve context
Prometheus's official alerting practices recommend simple symptom-oriented alerts tied to user pain, with relevant consoles for diagnosis. The worksheet preserves source, scope, evidence, ownership, and outcome so noise reduction does not discard investigative context.
Match notification urgency to budget risk
Google's SLO alerting workbook uses multiple windows and burn rates to choose between pages and tickets and calls out suppression when overlapping conditions would generate duplicate notifications. The baseline method remains platform-neutral and does not impose SLO thresholds on teams that do not use them.
Audit and adapt the worksheet
The HTML source and CSV source are public. Fork or adapt them for a documented incident model rather than treating the example formulas as universal targets.