Type to search.

Query alert indices

Serverless Security

Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Stack

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

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.

You can query Elastic Security alert indices to build custom dashboards, create detection rules that correlate alerts, or export alert data for external analysis. This page explains how to query alert data correctly and provides examples for common use cases.

Important

Do not modify alert index mappings. System indices contain internal configuration data—changing mappings can cause rule execution and alert indexing failures. To add custom fields to alert documents, use runtime fields instead.

Query the .alerts-security.alerts-<space-id> index alias, where <space-id> is your Kibana space (for example, default). Do not add a dash or wildcard after the space ID.

Scope Index pattern
Single space .alerts-security.alerts-default
All spaces .alerts-security.alerts-*

Alert events are stored in hidden Elasticsearch indices. You should query the alias (described above) rather than these internal indices directly—the alias automatically points to the correct underlying indices as they roll over.

Type Example Description
Alias (recommended) .alerts-security.alerts-default Points to all alert indices for the space. Use this for queries.
Internal index .internal.alerts-security.alerts-default-000001 First internal index for the default space.
Internal index .internal.alerts-security.alerts-default-000002 Second internal index (created after rollover).

The NNNNNN suffix increments over time as indices roll over (starting from 000001). New alerts are written to the latest index, but the alias spans all of them.

The following examples show common ways to query alert data. Adapt them to your space ID and field values as needed.

Returns the top 10 rules generating the most open alerts. Use this to identify noisy rules or prioritize tuning efforts.

ES|QL
FROM .alerts-security.alerts-default
| WHERE kibana.alert.workflow_status == "open"
| STATS count = COUNT(*) BY kibana.alert.rule.name
| SORT count DESC
| LIMIT 10
  1. Query the alert index for the default space
  2. Filter to untriaged alerts
  3. Group and count by rule
  4. Most alerts first
  5. Top 10 only

Returns critical alerts that haven't been triaged. Use this in Discover, dashboards, or as a filter on the Alerts page.

Text
kibana.alert.severity: "critical" AND kibana.alert.workflow_status: "open"
  • kibana.alert.severity: Filters by severity level (low, medium, high, critical)
  • kibana.alert.workflow_status: Filters by triage state (open, acknowledged, closed)

Returns all active alerts for a specific host. Useful when investigating a potentially compromised system.

Text
host.name: "web-server-01" AND kibana.alert.status: "active"
  • host.name: The hostname from the original event
  • kibana.alert.status: System status (active means the alert condition is ongoing)

Detects hosts triggering multiple alerts within a time window—useful for identifying systems under active attack.

Create a threshold rule with:

  • Index pattern: .alerts-security.alerts-default
  • Query: kibana.alert.workflow_status: "open"
  • Group by: host.name
  • Threshold: Count ≥ 5 (or your preferred value)

This generates a new alert when the same host appears in 5 or more open alerts.

These fields are frequently used in alert queries. For a complete list of alert fields, refer to the Alert schema.

Field Description
kibana.alert.rule.name Name of the rule that generated the alert
kibana.alert.severity Alert severity: low, medium, high, or critical
kibana.alert.risk_score Numeric risk score (0–100)
kibana.alert.workflow_status Triage status: open, acknowledged, or closed
kibana.alert.status System status: active or recovered
@timestamp When the alert was created
host.name Host associated with the alert
user.name User associated with the alert