> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Alert Intelligence
> Classify which monitors are worth waking someone for, and propose the threshold, dedupe, and suppression fixes that quiet the rest.
Alert Intelligence owns the quality of your alerting itself: which monitors fire usefully, which fire
constantly and get ignored, and what to change about each one. This page explains the outcome the
module owns, the workflow inside it, what you need connected, and what the module gives you to act
on once it runs.
## What this module owns
Every alerting setup accumulates monitors nobody trusts. A threshold was right eighteen months ago,
the service scaled, and now it fires nine times a week and gets acknowledged without being read. The
on-call learns which pages to ignore, and the one that mattered arrives in the same stream as the
ones that never do.
Fixing it is unglamorous, evidence-heavy work: pull each monitor's firing history, decide whether its
alerts were true, false, or simply not actionable, and then argue for a specific change. Alert
hygiene does that work continuously and hands you the proposal — a tuned threshold, a dedupe rule, a
suppression window — with the history that justifies it.
Good looks like a monitor set where every page is worth reading, and where the count of monitors
under review keeps falling instead of quietly growing.
## The workflow inside it
This module contains **1 workflow**.
### Alert noise reduction
Reads your monitors' firing history, classifies each one, and proposes the fix.
| Step | What happens |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1 · Alert ingest** | Backfills each monitor's fire, page, and flap history from the connected providers. This step is shared with the Incident management & troubleshooting workflow, so editing it there changes it here too. |
| **2 · Signal analysis** | Classifies every monitor — true positive, false positive, actionable or not — and records the rationale behind the call. |
| **3 · Noise optimization** | Proposes the change: threshold and window tuning, a dedupe rule, or a suppression window, with the trade-off each one carries. |
Each step delivers its task to the agents bound to it. The analysis step is where the specialists
matter most: one classifies signal quality, one detects flapping patterns, one finds duplicate
signals firing on the same underlying condition.
Steps 2 and 3 are graded by evaluation judges, so a classification and a proposed fix each carry a
verdict you can open. See [Evaluations](/manage-your-agents/optimize/evaluations).
## What it needs connected
| Requirement | Why | Where to set it up |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| A monitoring provider | The module reads monitor definitions and firing history — Datadog, PagerDuty, Grafana, and the other catalog providers | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
| Provider credentials | Each ingest agent needs read access to the provider it polls, and nothing more | [Credentials & secrets](/manage-your-agents/build/credentials-secrets) |
| Classification agents | The specialists bound to the analysis and optimization steps | [Use specialized agents](/manage-your-agents/build/use-specialized-agents) |
## Enabling it
Alert Intelligence appears in the AI SRE family with the workflow it contains.
Enabling the module adds Alert Intelligence to your sidebar, alongside its monitor list.
Point the ingest step at your monitoring provider and bind an agent to each step you expect to
run.
## What you see when it runs
The module's sidebar entry lists your monitors, each one carrying what the workflow concluded about
it:
* **Firing history** — how often it fired and flapped over the last seven days, and how often anyone
acknowledged it.
* **The classification**, and the rationale for it.
* **The proposed fix**, with its trade-offs stated, so you can see what you lose by quieting it.
Every monitor carries its review status and the disposition of its recommendations, so the list
doubles as your work queue. Because
each conclusion is produced by a run, you can open any monitor and read exactly what the agent saw
before it made the call.
## Next steps
Where the alerts you keep end up being investigated.
How a proposed monitor change waits for a human decision.
The judges that grade a classification and a proposed fix.
How workflow steps deliver tasks to agents.
## Related topics
- [Incident management & troubleshooting](/modules-and-workflows/sre/incidents.md)
- [Observability Cost](/modules-and-workflows/cost-optimization/observability-optimization.md)
- [Modules & workflows](/modules-and-workflows/overview.md)
- [Change Intelligence & Risk Control](/modules-and-workflows/ops-automation/change-intelligence.md)
- [CI/CD Health & Remediation](/modules-and-workflows/ops-automation/ci-cd-pipeline-health.md)