Kibana Universal Alerting glossary
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability We plan to add this functionality in a future Elastic Stack update. Subject to changes. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Serverless
Generally available
Stack
Planned
Planned
These terms appear throughout the Kibana Universal Alerting documentation.
- Action policy
- A configuration that controls which alerts invoke a workflow and how often. A single action policy can apply to alerts from one rule, several rules, or every rule in the space. To learn more, refer to Notifications and actions.
- Alert
- The complete record of one problem, from first detection to recovery, moving through states (pending, active, recovering, inactive). An alert is the grouping of rule events that share
episode.id. To learn more, refer to Alerts. - Breach
- A matching row from a rule run. Kibana writes each breach as a rule event. To learn more, refer to ES|QL query.
- Dispatcher
- The background process that evaluates action policies against eligible alerts on a short interval (around 5 seconds), independent of the rule schedule. To learn more, refer to Reduce notification noise.
- ES|QL
- The language the system uses to evaluate your data. Some creation paths generate the query for you. To learn more, refer to the ES|QL reference.
- Notification
- The message or action a workflow sends (such as a Slack message, an email, or a webhook call) when an alert matches an action policy or a lifecycle trigger fires. To learn more, refer to How the dispatcher evaluates action policies.
- Routing tag
- A tag that links rules to an action policy. When a rule and an action policy share a routing tag, the policy applies to that rule's alerts. Routing tags are separate from rule tags, which only label and filter rules. To learn more, refer to Apply the policy to alerts from specific rules.
- Rule
- The definition of what to watch for in your data, what counts as a match, and how often to check. The rule's mode determines whether its matches open alerts. To learn more, refer to Rules.
- Rule event
- A record Kibana writes to
.rule-eventsfor each matching row in a rule run. Kibana never overwrites these events. Events withtype: alertbelong to an alert, and events withtype: signalare signals. To learn more, refer to Rule events. - Severity
- A label stored on rule events when the query emits a recognized value. Action policies use it only for alerts, so critical alerts can be routed differently from low-priority ones. To learn more, refer to Configure rule severity.
- Signal
- A rule event with
type: signal, kept in.rule-eventsfor later analysis. Signals don't appear on the Alerts page and don't start workflows. To learn more, refer to Query rule events and Rule mode. - Threshold
- The condition a rule uses to decide when something is worth alerting on, including how many times the condition must be met before an alert opens or closes. To learn more, refer to Alert delay and Recovery condition.
- Workflow
- The automation that sends a message or runs an action (such as posting to Slack, sending an email, or calling a webhook) when an action policy or an alert lifecycle trigger invokes it. To learn more, refer to Connect workflows.