Alert storage and schema

Detection alerts are stored in hidden Elasticsearch indices, separate from your source event data. This page explains the index structure and the fields that make up an alert document.

Query alerts using the index alias, not the underlying indices directly:

An index alias like .alerts-security.alerts-default doesn't store data itself. It points to one or more real Elasticsearch indices — called backing indices — where the alert documents actually live.

As alert volume grows, Elasticsearch creates new backing indices automatically through a process called rollover. Each backing index has a name like .internal.alerts-security.alerts-<space-id>-NNNNNN (for example, .internal.alerts-security.alerts-default-000001), where the numeric suffix increments with each rollover. New alerts are always written to the latest backing index, but when you query the alias, the results span all of them. You don't need to know which backing index holds a particular alert.

Alert indices use an index lifecycle management (ILM) policy that rolls over after 30 days or when the primary shard reaches 50 GB. There is no delete phase by default, which means alerts accumulate indefinitely unless you add one.

To manage alert index size, you can add a delete phase to the ILM policy attached to the alert indices. For example, you could configure the policy to delete alert indices that are older than 180 days. You can also reduce the rate of alert creation by narrowing rule queries, adding exceptions, or enabling alert suppression.

For backward compatibility, Elastic Security also maintains a .siem-signals-<space-id> alias. New integrations should use .alerts-security.alerts-<space-id>.

Alert index mappings define which fields an alert document can contain and how Elasticsearch indexes them (as a keyword, date, float, and so on). These mappings are system-managed — you do not create or edit them. Elastic Security builds them automatically from three component templates, each contributing a different layer of fields.

When the detection engine initializes for a Kibana space, it composes these three component templates into a single index template (for example, .alerts-security.alerts-default-index-template). That index template controls the mappings for all alert indices in that space.

The result is that every detection alert document can contain fields from all three layers. For example, a single alert might include host.name (from ECS), kibana.alert.uuid (from the technical template), and kibana.alert.risk_score (from the Security template) — all in one document.

ECS component template

Provides standard Elastic Common Schema (ECS) field mappings. These are the same fields you find in event indices (logs-*, filebeat-*), so alert documents share a common schema with the source events that triggered them.

Example fields: host.name (keyword), user.name (keyword), process.pid (long), source.ip (ip), @timestamp (date)

Technical component template

Provides fields that the Kibana alerting framework uses for all rule types — not just security detection rules. These fields track alert identity, rule ownership, and execution metadata.

Example fields: kibana.alert.uuid (keyword), kibana.alert.status (keyword), kibana.alert.rule.uuid (keyword), kibana.alert.rule.execution.uuid (keyword), kibana.space_ids (keyword)

Security mappings component template

Provides fields specific to Elastic Security detection alerts. These cover severity, risk scoring, alert lineage, suppression, and rule parameters. This is the layer that makes detection alerts different from alerts created by other Kibana rule types (like Observability threshold rules).

Example fields: kibana.alert.severity (keyword), kibana.alert.risk_score (float), kibana.alert.ancestors (object), kibana.alert.suppression.docs_count (long), kibana.alert.rule.parameters.query (flattened)

The 1700-field limit accommodates all ECS, technical, and Security-specific fields. If you need additional fields, use runtime fields rather than modifying the index mappings.

Alert documents combine fields from three sources, corresponding to the component templates described above.

Elastic Common Schema (ECS) fields are copied from the source event that triggered the alert. These include fields like host.*, user.*, process.*, source.*, destination.*, and network.*. The specific fields present depend on the source event and the rule type.

The detection engine adds kibana.alert.* fields that describe the alert itself:

For the complete field list, refer to the Alert schema reference.

Every detection alert has event.kind set to signal. This is the key field that identifies a document as a detection alert rather than a raw event or external alert.

When retrieving alert data programmatically, use the fields option in the search API rather than relying on _source. This approach handles field resolution across the component template layers correctly and avoids issues with flattened or multi-valued fields.

For query examples and best practices, refer to Query alert indices.