Alert Noise Rate Calculator

Team or service:

Name the team, service, rotation, or queue represented by this alert sample.

Noise target:

Set the non-actionable alert ceiling for this review window.

Alert sample CSV:

Paste exported alert rows; CSV parsing and analysis stay in this browser.

{{ alerts.length.toLocaleString() }} chars

Review the alert sample

{{ message }}

Repeat group threshold:

Use this to focus remediation on recurring alert names rather than one-off noise.

alerts

Ack target:

Optional response target for the median acknowledgement-delay check.

min

Chart route limit:

Show the top routes by alert volume; smaller values keep dense exports readable.

routes

Metric	Value	Interpretation	Copy
{{ row.metric }}	{{ row.value }}	{{ row.interpretation }}

Route	Alerts	Noise	Signal	Unclassified	Route action	Copy
{{ row.route }}	{{ row.total }}	{{ row.noise }}	{{ row.actionable }}	{{ row.unknown }}	{{ row.action }}

Alert group	Route	Noise share	Volume	Tuning action	Copy
No repeat groups reached the current tuning threshold.
{{ row.group }}	{{ row.route }}	{{ row.noiseShare }}	{{ row.volume }}	{{ row.action }}

Alert	Route	Severity	Classification	Ack delay	Created	Review note	Copy
{{ row.alert }}	{{ row.route }}	{{ row.severity }}	{{ row.classification }}	{{ row.ackDelay }}	{{ row.created }}	{{ row.note }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Alert noise rate is the share of classified alerts that did not require useful human action. In an on-call stream, those alerts may be duplicates, false positives, flapping checks, informational events, or conditions that resolved without intervention. Measuring that share helps a team see whether alerts are earning attention or training responders to ignore the next page.

Noise matters because alerting is a trust system. A low-volume stream with clear action paths keeps people responsive. A stream full of repeats and non-actionable pages creates alert fatigue, slows triage, and makes it easier for a real incident to hide inside routine notification traffic.

A useful noise rate is not just an alert count. It depends on the outcome attached to each alert row. Rows marked as actionable become signal. Rows marked as duplicates, false positives, noise, flapping, auto-resolved, suppressed, ignored, or similar non-actionable outcomes become noise. Rows that cannot be classified should be cleaned up before the rate is used for policy decisions.

A high noise rate should not automatically lead to deleting alerts. It means the review should move from volume complaints to specific tuning work: grouping repeats, changing routing, lowering urgency, adding confirmation, or converting low-urgency events into tickets or dashboard signals.

Technical Details:

Noise rate is a ratio over classified alert outcomes. The numerator is the count of alerts labeled non-actionable. The denominator is the count of alerts with a clear signal or noise outcome. Unknown outcomes are still important for data quality, but they are not counted in the ratio because treating them as either signal or noise would bias the review.

Repeat groups add a second view of the same sample. A group is formed from the alert name and route, then counted across the review window. That grouping helps separate one broad routing problem from a small number of alert names that repeatedly wake the same team.

Formula Core

noise rate = \frac{noise alerts}{signal alerts + noise alerts} * 100

Variables used in the alert noise rate formula
Term	Meaning	Included in rate?
Signal alerts	Rows with an outcome that indicates a page, ticket, incident, escalation, mitigation, fix, or other human action.	Yes, in the denominator.
Noise alerts	Rows with an outcome that indicates no action, a duplicate, a false positive, a flap, an auto-resolved condition, suppression, or informational status.	Yes, in the numerator and denominator.
Unclassified alerts	Rows with a missing or unknown outcome value.	No, but they appear as a warning and in totals.

If a sample has 3 signal alerts, 7 noise alerts, and 2 unclassified alerts, the displayed rate is 7 / (3 + 7) * 100 = 70.0%. The two unclassified rows still appear in the sample volume, but they do not change the percentage until their outcomes are fixed.

Rule Core

Outcome text is normalized before classification, so common spelling and separator differences are handled as the same meaning. Exact values are preferred, and keyword matches catch practical variants when the value still clearly points to signal or noise.

Alert outcome classification rules
Outcome family	Accepted examples	Review meaning
Signal	`yes`, `page`, `incident`, `ticket`, `escalated`, `mitigated`, `fixed`, or a value with an action keyword.	The alert caused or needed human response.
Noise	`no`, `noise`, `false-positive`, `duplicate`, `flap`, `auto-resolved`, `suppressed`, `ignored`, or a value with a noise keyword.	The alert did not need human response in this sample.
Unclassified	Blank values or terms that do not match a known signal or noise pattern.	The row should be reviewed before using the rate as a team metric.

Output Boundaries

Alert noise rate output fields and interpretation boundaries
Output field	What it means	Boundary to remember
`Noise rate`	Percent of classified alerts that were non-actionable.	Compared with `Noise target`; unclassified rows are excluded.
`Classified alerts`	Signal plus noise rows in the denominator.	A low classified count makes the percentage fragile.
`Routes above target`	Routes whose classified noise rate is greater than the current target.	Shown for the busiest routes selected by `Chart route limit`.
`Repeat groups`	Alert-name and route combinations at or above `Repeat group threshold`.	Repeated signal should not be suppressed just because it repeats.
`Median ack delay`	Median minutes between created and acknowledged timestamps when both parse.	Compared with `Ack target`; missing or invalid timestamps produce `n/a`.

File input is intentionally bounded. CSV or TXT files larger than 1 MiB are rejected, and pasted or selected rows are parsed in the browser. That keeps the review focused on a manageable incident slice or rotation window rather than a full monitoring export.

Everyday Use & Decision Guide:

Start with a CSV export that has one alert per row and, ideally, the columns alert, created, acknowledged, actionable, route, and severity. A header row is optional, but a clear header makes mixed exports easier to read. Leave Noise target at a practical first-pass ceiling, then adjust it to match your team's current alert-quality goal.

The best first pass is a focused review window: one team, one service, one queue, or one rotation slice. Use Team or service to label the run, paste the rows or use Browse CSV, and click Normalize rows if the paste includes blank lines or uneven spacing. If the warning box says rows need an actionable/noise value, fix those rows before treating the percentage as a reliable score.

Use Noise Brief for the main percentage, classified volume, routes above target, repeat groups, and median acknowledgement delay.
Open Route Breakdown when one team route, service route, queue, or receiver appears to be producing most of the noise.
Use Noise Tuning Queue to find repeated alert names that reached the current Repeat group threshold.
Check Alert Ledger before suppressing anything. It keeps each row's route, severity, classification, acknowledgement delay, and review note visible.
Use Route Signal Mix when a stacked chart will make the signal, noise, and unclassified split clearer for a review note.

A high route noise rate is a prompt to inspect the rules behind that route, not a reason to mute the route wholesale. If high-severity pages are mostly noise, the safer fix may be confirmation logic or lower urgency. If low-severity duplicates dominate, deduplication, inhibition, grouping, or conversion to ticket-style review may be enough.

Before sharing results, compare Noise rate with Classified alerts and Sample volume. A 70% noise rate across ten classified rows is useful for a tuning conversation, but it is weaker evidence than the same rate across several hundred rows from the same routing policy.

Step-by-Step Guide:

Use the page to turn alert rows into a tuning list, then verify the rows behind any proposed change.

Enter the rotation, service, or queue name in Team or service. The name appears in summaries and exports, so use the label your on-call or incident review process already uses.
Set Noise target to the maximum non-actionable share you want to tolerate for this review window. The summary will show noise high when the classified noise rate is above that target.
Paste CSV rows into Alert sample CSV, drop a CSV or TXT file, or use Browse CSV. If you are exploring the format, Load sample fills the page with a realistic alert set.
Open Advanced when the defaults need tuning. Repeat group threshold controls which repeated alert names enter the queue, Ack target sets the median acknowledgement comparison, and Chart route limit controls how many busy routes appear in the chart and route table.
If Review the alert sample appears, fix the listed problem before using the result. Missing or unknown outcome values become unclassified rows and are excluded from Noise rate.
Read Noise Brief first, then move to Noise Tuning Queue for repeated groups and Route Breakdown for route-level action notes.
Open Alert Ledger before changing an alert rule. Confirm that a noisy group is really non-actionable and not a legitimate signal that repeats during the same incident.

A useful handoff names the target miss, the repeated alert group, the noisy route, and one proposed tuning action that preserves real signal.

Interpreting Results:

Read Noise rate with its denominator. The percentage is most meaningful when Classified alerts is large enough to represent the review window and when Sample volume does not hide many unclassified rows. If unclassified rows are present, treat the result as provisional until the outcomes are corrected.

Above target: Focus on Noise Tuning Queue and Routes above target before changing broad escalation policy.
At or below target: Keep checking repeat groups. A healthy overall rate can still hide one alert name that repeatedly wakes a team.
High repeat count with signal: Do not suppress it by default. It may need incident grouping, dependency inhibition, or runbook cleanup instead.
High median acknowledgement delay: Compare the delay with Ack target and route ownership. Slow acknowledgement may point to routing drift, unclear alert text, or responder overload.

The false-confidence risk is treating a clean percentage as proof that alerting is healthy. The rate measures classified outcomes in the supplied sample. It does not prove that thresholds catch every real incident, that route ownership is correct, or that alert content is actionable.

Worked Examples:

Checkout rotation with too many repeats

A ten-row checkout sample has 3 signal alerts and 7 noise alerts. Noise target is 40%, Repeat group threshold is 2, and the parsed timestamps produce a 5.0 minute Median ack delay. The Noise rate is 70.0%, so the summary shows a target miss. The queue highlights repeated groups such as CPUHigh, PaymentErrors, and QueueDepthWarning, which gives the reviewer concrete alert names to inspect instead of only a complaint about volume.

Small sample with unknown outcomes

A platform queue paste contains 12 rows, but 4 rows have blank or unfamiliar actionable values. If the remaining rows have 5 signal alerts and 3 noise alerts, Noise rate is 37.5% because the denominator is 8 classified rows. The right interpretation is not that the queue is definitely below target. The next move is to fix the four unclassified outcomes, then rerun the review.

Route-level tuning without muting incidents

An infrastructure route has 8 classified alerts: 6 noise and 2 signal. With a 40% target, that route sits at 75.0% noise and appears above target. If the noisy rows are mostly duplicate and flap, the Route action points toward suppression, grouping, and escalation-policy review. The two signal rows still matter, so the safer plan is to deduplicate or inhibit repeats while keeping real incidents on the response path.

FAQ:

What columns can I paste?

The expected fields are alert name, created time, acknowledged time, actionable outcome, route, and severity. Header aliases such as alert_name, fired_at, acked_at, classification, queue, and priority are recognized when present.

Are unclassified rows counted as noise?

No. Unclassified rows are excluded from Noise rate and shown separately. Fix their outcome values before using the percentage for a formal alert review.

Does a high noise rate mean I should delete the alert?

Not by itself. Check Alert Ledger, route, severity, and repeated group context first. Many noisy alerts need grouping, inhibition, urgency changes, or better confirmation rather than removal.

Why does the chart show only some routes?

Chart route limit caps the busiest routes shown in Route Signal Mix and the route table so dense samples stay readable. Use Alert Ledger or the alert rows in JSON when you need row-level context outside the visible route summary.

Does the alert sample leave my browser?

CSV parsing and analysis happen in the browser. Selected files are read locally, and copied or downloaded exports are created from the result you choose to share.

Glossary:

Alert noise rate: The percentage of classified alert rows that were non-actionable.
Signal: An alert outcome that required a page, ticket, incident response, escalation, mitigation, fix, or similar human action.
Noise: An alert outcome that did not require human response, such as a duplicate, false positive, flap, or auto-resolved event.
Unclassified alert: A row whose outcome cannot be mapped to signal or noise.
Repeat group: A recurring combination of alert name and route that meets the selected count threshold.
Median ack delay: The middle acknowledgement delay, in minutes, across rows with parseable created and acknowledged timestamps.

References:

Monitoring Distributed Systems, Google Site Reliability Engineering.
Practical Alerting from Time-Series Data, Google Site Reliability Engineering.
Alerting Principles, PagerDuty Incident Response Documentation.
Noise Reduction, PagerDuty Support.