---
title: Reduce noise and false positives
description: Compare and choose the right mechanism to reduce alert noise: tuning, exceptions, suppression, or snoozing.
url: https://www.elastic.co/docs/solutions/security/detect-and-alert/reduce-noise-and-false-positives
products:
  - Elastic Cloud Serverless
  - Elastic Security
applies_to:
  - Serverless Security projects: Generally available
  - Elastic Stack: Generally available
---

# Reduce noise and false positives
Elastic Security provides four distinct mechanisms for managing alert noise, each operating at a different point in the pipeline from raw events to analyst notification. Selecting the wrong tool for your situation reduces effectiveness and can obscure real threats. This page explains when to use each mechanism and how they work together.

## Select the right approach

Use the following table to identify which mechanism matches your situation. If multiple rows apply, refer to [Using them together](#using-them-together).

| Your situation                                                                                                                                                                            | Use this                                                                                                                      | What it does                                                                                                      |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
| The rule fires on activity that isn't suspicious in any environment (for example, the query is too broad and catches normal admin behavior)                                               | [Tune rule logic](https://www.elastic.co/docs/solutions/security/detect-and-alert/tune-detection-rules)                       | Refine the query, threshold, or schedule so the rule only matches what it should                                  |
| The rule correctly identifies a pattern, but a specific known-safe case keeps firing in your environment (for example, an SCCM server triggers your remote service creation rule nightly) | [Exception](https://www.elastic.co/docs/solutions/security/detect-and-alert/rule-exceptions)                                  | Permanently suppress alerts matching specific field values. The rule logic stays unchanged.                       |
| The rule generates many alerts for the same entity in a short window (for example, a compromised host triggers the same rule every 5 minutes for an hour)                                 | [Alert suppression](https://www.elastic.co/docs/solutions/security/detect-and-alert/alert-suppression)                        | After the first alert for a given field value, suppress further alerts for a defined time window                  |
| You need to temporarily stop receiving notifications during scheduled maintenance or a known event                                                                                        | [Snooze actions](/docs/solutions/security/detect-and-alert/manage-detection-rules#snooze-rule-actions)                        | The rule runs and alerts are still created and stored. Only notifications (email, Slack, webhooks) are paused.    |
| A specific known-safe process or user keeps appearing across many different rules (for example, your vulnerability scanner triggers dozens of rules)                                      | [Shared exception list](https://www.elastic.co/docs/solutions/security/detect-and-alert/create-manage-shared-exception-lists) | Apply one exception list across multiple rules simultaneously, avoiding duplicate exceptions rule by rule         |
| You're deploying a new rule and want to observe alert volume before enabling notifications                                                                                                | [Snooze actions](/docs/solutions/security/detect-and-alert/manage-detection-rules#snooze-rule-actions)                        | Enable the rule fully, review alerts in the UI, and only enable notifications once you're confident in the signal |


## How each mechanism works

Each mechanism intervenes at a different stage of the detection pipeline. They are listed here in pipeline order, from earliest to latest.

### Tune rule logic

Acts on: **the rule query, before events are evaluated**
*"The rule is catching the wrong things."*
Modify the rule query, threshold count, look-back window, or schedule to improve detection precision. Tuning is the only mechanism that improves the underlying signal rather than filtering output. Alerts are still created for events matching the revised logic, and change history requires version tracking. Tuning affects all environments using the rule.
Refer to [Tune detection rules](https://www.elastic.co/docs/solutions/security/detect-and-alert/tune-detection-rules) for more guidance.

### Rule exceptions

Acts on: **alert creation, after the rule evaluates but before the alert is written**
*"This specific case is acceptable in my environment."*
Permanently prevent alert creation for events matching defined field conditions. The rule logic stays unchanged. Exceptions are auditable and removable at any time. They can apply to a single rule or be shared across multiple rules through [shared exception lists](https://www.elastic.co/docs/solutions/security/detect-and-alert/create-manage-shared-exception-lists).
Refer to [Rule exceptions](https://www.elastic.co/docs/solutions/security/detect-and-alert/rule-exceptions) for more guidance.

### Alert suppression

Acts on: **alert deduplication, after the first alert is created**
*"I already know about this. Don't repeat it."*
After the first alert fires for a given field value (for example, a specific host or user), suppress subsequent duplicate alerts for a defined time window. Unlike exceptions, suppression is temporary and time-bounded. It acknowledges the signal is real but reduces repetitive noise. Configured per rule, grouped by field value.
Refer to [Suppress detection alerts](https://www.elastic.co/docs/solutions/security/detect-and-alert/alert-suppression) for more guidance.

### Snooze rule actions

Acts on: **notifications, after alerts are created and stored**
*"Don't trigger any actions right now. I'll review later."*
Temporarily pause all of a rule's actions—including notifications (emails, Slack messages, webhooks), ticket creation, and other automated responses—without affecting rule execution or alert creation. Alerts generated during a snooze period are stored normally and visible in the Alerts UI. Snoozing expires automatically or can be canceled manually. For space-wide pausing, use a [maintenance window](https://www.elastic.co/docs/explore-analyze/alerting/alerts/maintenance-windows).
Refer to [Snooze rule actions](/docs/solutions/security/detect-and-alert/manage-detection-rules#snooze-rule-actions) for more guidance.

## Key distinctions


|                         | Tuning logic              | Rule exceptions   | Alert suppression        | Snooze rule actions        |
|-------------------------|---------------------------|-------------------|--------------------------|----------------------------|
| Rule still runs         | Yes                       | Yes               | Yes                      | Yes                        |
| Alert written to index  | Fewer or different alerts | No                | First only               | Yes                        |
| Actions triggered       | For matches               | No                | First only               | No                         |
| Alert visible in UI     | For matches               | No                | First only               | Yes, all alerts            |
| Time-bounded            | No                        | Yes               | Yes, configurable window | Yes, configurable duration |
| Can span multiple rules | No                        | Yes, shared lists | No                       | No                         |

<tip>
  You can also control action frequency without modifying alerts. When configuring [rule actions](/docs/solutions/security/detect-and-alert/common-rule-settings#rule-notifications), you can choose to run actions for each alert, as a summary at custom intervals, or only when specific conditions are met. This provides another way to reduce action noise while still creating all alert records.
</tip>

<important>
  Exceptions and suppression have different forensic implications. Exceptions permanently prevent alert records from being created. If you later need to investigate whether a specific event occurred, the alert data won't be there—though the original events are still available in source logs if retained.Suppression still creates an alert but groups subsequent matches into it instead of creating separate alerts. Use suppression when you need at least one alert record for audit or forensic purposes. Reserve exceptions for activity that is definitively never relevant.
</important>


## Using them together

These four mechanisms are not mutually exclusive. A well-tuned ruleset typically uses all of them simultaneously for different purposes. The following scenario illustrates how they layer on top of each other in practice.
**Scenario: A noisy lateral movement rule in a real environment**

| Situation                                                                                                      | Action                                                                                                                       | Mechanism       |
|----------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|-----------------|
| The base query matches too broadly, catching any remote service creation including from `C:\Windows\`          | Narrow the query to exclude standard install paths. The rule now only fires on services installed to non-standard locations. | Tune rule logic |
| The SCCM deployment server still triggers it every deployment cycle from a known management IP                 | Add an exception: `source.ip: "10.1.5.20" AND user.name: "svc-sccm"`. Those specific alerts are never created.               | Exception       |
| A compromised host generates 30 alerts in an hour. Analysts only need to know about the first one.             | Enable alert suppression grouped by `host.id` with a 1-hour window. One alert per host per hour.                             | Suppression     |
| Planned maintenance window tonight. Legitimate admin activity will trigger alerts, but no one should be paged. | Snooze rule actions for 4 hours. Alerts are created and stored. Notifications are paused. Review them in the morning.        | Snooze actions  |

<note>
  Order of application matters. Tuning and exceptions are evaluated before an alert is created. Suppression groups multiple matching events into a single alert based on specified field values, reducing alert volume without losing coverage. Snoozing acts after suppression, only on notifications. Applying them in the wrong conceptual order leads to gaps. For example, using suppression to handle what should be an exception means the first alert is still stored and may page someone, and the suppression window may expire before the condition is resolved.
</note>