Choose an alerting system
If you already know which alerting system you are using, go directly to Kibana alerting v1, Kibana alerting v2, or Watcher. This page is for readers who are not sure which system fits their needs.
| I want to... | Recommended system |
|---|---|
| Monitor metrics, logs, or uptime using prepackaged rules with minimal setup | Kibana alerting v1 |
| Use solution-specific rules for Security, Observability, APM, or Maps | Kibana alerting v1 |
| Write my own detection logic in ES|QL and control exactly what data each alert carries | Kibana alerting v2 |
| Query alert history in Discover or build dashboards from alert data | Kibana alerting v2 |
| Manage notification routing, grouping, and throttling separately from rule definitions | Kibana alerting v2 |
| Correlate across multiple rules and reduce noise with rules on alerts | Kibana alerting v2 |
| Suppress notifications per host or service without silencing an entire rule | Kibana alerting v2 |
| Define complex alerting logic with Painless scripting or chained inputs | Watcher |
| Kibana alerting v1 | Kibana alerting v2 | Watcher | |
|---|---|---|---|
| Best for | Teams using built-in rule types with form-based setup | Teams that need full control over detection and notification routing | Custom alerting logic requiring scripting |
| Rule definition | Select a rule type and fill in parameters | Write an ES|QL query | Write a JSON watch definition |
| Alert data | Updated in place; limited queryability | Immutable, append-only events queryable with ES|QL in Discover | Watch history index |
| Notifications | Configured per action on each rule | Centralized notification policies, reusable across rules | Action-level throttling and conditions |
| Noise reduction | Snooze per rule, maintenance windows | Per-series snooze, per-episode acknowledgement, activation thresholds, matcher-based routing, rules on alerts | Action conditions and throttling |
| Availability | All deployments | Elastic Stack 9.4+ | Self-managed and Elastic Cloud Hosted only |
Kibana alerting v1 provides prepackaged rule types integrated with Elastic solutions. Rules are configured through forms — no query language is required. Actions are triggered through built-in connectors such as email, Slack, PagerDuty, and webhooks.
Choose Kibana alerting v1 if you want broad rule type coverage out of the box and are working within Observability, Security, APM, Uptime, or Maps.
Get started with Kibana alerting v1 →
Kibana alerting v2 is built on ES|QL. You write the query that defines what to detect and what data each alert carries. Notification policies control routing, grouping, and throttling independently of rules, and alert events are stored as queryable data in standard Elasticsearch indices.
Choose Kibana alerting v2 if you need flexible detection logic, queryable alert history, centralized notification management, or cross-rule correlation.
Get started with Kibana alerting v2 →
Watcher supports custom alerting logic with Painless scripting, chained inputs, and direct Elasticsearch API integration. It is the most flexible system for non-standard use cases but does not integrate with the Kibana alerting management UI.
Watcher is not available in Elastic Cloud Serverless.
The alerting systems are independent and can run side by side:
- Kibana alerting v1 and Kibana alerting v2 share a single Rules navigation entry with separate tabs. Each system writes to its own indices.
- Watcher operates through its own API and management UI.
- Kibana alerting v2 rules on alerts can query alert data produced by any system, enabling cross-system correlation.
There is no forced migration. You can adopt a new system incrementally while your existing rules continue running.