---
title: Rule Tuning Worker
description: Find what the AlertZero Rule Tuning Worker does in Elastic Security, the false positive thresholds that decide which rules it tunes, and its limits.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/9118/solutions/security/alertzero/watches/rule-tuning-worker
products:
  - Elastic Cloud Serverless
  - Elastic Documentation
  - Elastic Security
applies_to:
  - Serverless Security projects: Preview
  - Elastic Stack: Planned
---

# Rule Tuning Worker
The Rule Tuning Worker is part of the [Detection Watch](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/9118/solutions/security/alertzero/watches/detection-watch). It finds rules that produce too many false positives and proposes one change per rule to reduce them. This page explains when to use the Rule Tuning Worker, what data it needs, how it chooses which rules to tune, where to decide its proposed actions, and which settings and limits apply.

## When to use the Rule Tuning Worker

The Rule Tuning Worker is the right fit when:
- A few rules produce most of your false positives.
- Your analysts, or the [Alert Triage Worker](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/9118/solutions/security/alertzero/watches/alert-triage-worker), close false positives with the false positive reason, so the Rule Tuning Worker can count them.
- You want to test each proposed change against your past alerts before you apply it.

The Rule Tuning Worker isn't the best fit when:
- Your rules rarely produce false positives. With the default settings, a rule needs at least 10 false positives that make up at least 50% of its alerts over 7 days before the Rule Tuning Worker tunes it.
- Your analysts close false positives with a different reason, or without one. The Rule Tuning Worker counts only alerts closed as false positives.
- Your noisiest rules are saved query or machine learning rules. The Rule Tuning Worker can't backtest changes to them, so you need to check those changes yourself.


## Data requirements

- Enabled rules that generated alerts in the space during the analysis window.
- Alerts closed as false positives. For each rule, the Rule Tuning Worker uses the newest 100.


## How it works

On each run, the Rule Tuning Worker:
1. Counts how many false positives each enabled rule produced in its analysis window.
2. For each rule that meets both false positive thresholds, opens an investigation and diagnoses the cause.
3. Proposes one change to the rule's exceptions, query, risk score, threshold, or schedule. Most changes come with a **Backtest**, a [rule preview](/elastic/docs-content/pull/9118/solutions/security/detect-and-alert/validate-and-test-rules#validate-historical-data) that compares how many alerts the rule generated with how many it would have generated after the change.

The Rule Tuning Worker counts every alert closed as a false positive, whether a person or the [Alert Triage Worker](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/9118/solutions/security/alertzero/watches/alert-triage-worker) closed it.
You review the Rule Tuning Worker's proposed changes in the **Configure** section of the **Proposed actions** page. To learn how to review a proposed change and approve it, refer to [Decide a detection change](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/9118/solutions/security/alertzero/decide-detection-change).

### Example

A rule that detects new service creation generated 30 alerts last week, and analysts closed 24 of them as false positives because a software deployment tool creates services. That's 24 false positives at an 80% rate, above both default thresholds. The Rule Tuning Worker diagnoses the cause and proposes an exception for the deployment tool's process. The **Backtest** shows that the rule would have generated 6 alerts instead of 30.

## Settings

<definitions>
  <definition term="Schedule">
    How often the Rule Tuning Worker runs.
    Default: Every 2 hours
  </definition>
  <definition term="Autonomy">
    How much the Rule Tuning Worker does without you. You can set it to **Manual** or **Assisted**, and at either level, you approve each change before it reaches the rule. Refer to [what it does at each level](/elastic/docs-content/pull/9118/solutions/security/alertzero/configure-worker-settings#alertzero-worker-autonomy).
    Default: Manual
  </definition>
  <definition term="Models">
    Opens **Feature settings**, where you select the models that AlertZero uses in the space. The Rule Tuning Worker has no model setting of its own, so it uses the models you select there.
  </definition>
</definitions>

<definitions>
  <definition term="Analysis window (days)">
    How many days of alerts it checks.
    Default: 7 days, and you can set it from 1 to 30 days.
  </definition>
  <definition term="False positive count">
    How many false positives a rule needs in the analysis window.
    Default: 10, and you can set it from 2 to 100.
  </definition>
  <definition term="False positive rate">
    What share of a rule's alerts must be false positives.
    Default: 50%, and you can set it from 0 to 100.
  </definition>
</definitions>


## Limits

- Each time the Rule Tuning Worker runs, it reviews up to 10 rules and uses each rule's newest 100 false positives.
- The Rule Tuning Worker doesn't backtest changes to saved query or machine learning rules, or exceptions on ES|QL rules.