Query alert indices

This page explains how you should query alert indices when building rule queries, custom dashboards, or visualizations. It also lists index names and aliases by rule type and includes sample Elasticsearch queries for common cases.

We recommend querying index aliases rather than backing indices directly. Alias names begin with the .alerts- prefix, then include the context, dataset, and space-id parts:

.alerts-{{context}}.{{dataset}}-{{space-id}}
		

For example, the alias for a sample Elasticsearch Query rule is:

.alerts-stack.alerts-default
		

To search across alerts from all contexts, use the .alerts-* pattern. You can narrow queries to a specific alias when you know the rule type (see the tables below).

For additional context, alert events are stored in hidden Elasticsearch indices on self-managed Elastic Stack deployments and Elastic Cloud Hosted. On Serverless, they are stored in data streams. We do not recommend querying these indices directly.

The naming convention for backing indices is:

.internal.alerts-{{context}}.{{dataset}}-{{space-id}}-{{version-number}}
		

version-number identifies the index generation; it starts at 000001 and increments by 1 when the index rolls over.

Each part of the name:

• .internal.alerts- prefix: Present on all alert backing index names.
• context: The product group for the rule type (for example Stack Management, Observability, or Elastic Security).
• dataset: It will always be .alert for alert indices.
• space-id: The Kibana space the index was created for. Elastic Security rules are space-specific; other rules use the default space in the index name.

The two tables below use the same context values so you can match a rule type to both the recommended alias (for queries) and an example backing index (for debugging or mapping checks). Default Kibana space uses the alerts-default segment in names; Elastic Security uses your space ID instead—see Alert index aliases and Alert indices.

Columns in the first table

• Context: Kibana's internal name for which alert index registration a rule type uses. For most rows, it's the same substring that appears after .alerts- in the alias (for example, stack in .alerts-stack.alerts-default). There is one exception: Synthetics and Uptime rules are registered under ml.observability.uptime but still write to the stack path (same alias and backing index as Stack rules).
• Area: The product or feature area those rules belong to (Stack monitoring, Observability, Elastic Security, and so on). Use it when you are looking up indexes by what you are working on in the UI, not by the technical context string.
• Index alias: The name to use in searches and API calls. Prefer aliases over backing indices.
• Rule types: The rule types whose alerts are stored under that context.

Columns in the second table

• Context: Same Context value as the row in the first table.
• Example backing index: A typical first-generation backing index name (for example, suffix -000001). After rollover, the numeric suffix increases. Do not rely on a specific generation in automation; use the alias or a wildcard pattern when possible.

The examples below use the .internal.alerts-* index pattern or the .alerts-* alias pattern. Prefer aliases for production queries when possible.

The following query returns the top 100 alerts from all alert indices.

GET /.internal.alerts-*/_search
{
 "query": {
   "match_all": {}
 },
 "size":100
}
		

The following sample request retrieves index mappings for a sample Elasticsearch rule:

GET /.internal.alerts-stack.alerts-default-000001/_mapping
		

If you want to use the alias instead, use:

GET /.alerts-stack.alerts-default/_mapping
		

The following sample request retrieves 100 recovered alerts:

GET /.internal.alerts-*/_search
{
 "query": {
   "bool": {
     "filter": [{ "term": { "kibana.alert.status": "recovered" } }]
   }
 },
 "size": 100
}
		

The following sample request retrieves 100 active alerts:

GET /.internal.alerts-*/_search
{
 "query": {
   "bool": {
     "filter": [{ "term": { "kibana.alert.status": "active" } }]
   }
 },
 "size": 100
}
		

The following sample request searches for alerts generated by a rule with the UUID 0cc8ed92-cbe6-42bd-800b-19ba5134ffd2.

GET /.internal.alerts-*/_search
{
 "size": 100,
 "query": {
   "bool": {
     "filter": [
       { "term": { "kibana.alert.rule.uuid": "0cc8ed92-cbe6-42bd-800b-19ba5134ffd2" } }
     ]
   }
 }
}
		

The following sample request searches for alerts that were generated during the last hour and have the recovered status:

GET /.internal.alerts-*/_search
{
 "query": {
   "bool": {
     "filter": [
       { "term":  { "kibana.alert.status": "recovered"}},
       {
         "range": {
           "@timestamp": {
             "gte": "now-60m",
             "lte": "now"
           }
         }
       }
     ]
   }
 },
 "size": 100
}
		

The following sample request searches for 100 alerts that were generated by the Elasticsearch rule type:

GET /.internal.alerts-*/_search
{
 "query": {
   "bool": {
     "filter": [
       { "term":  { "kibana.alert.rule.category": "Elasticsearch query"}}
     ]
   }
 },
 "size": 100
}