Use Discover to query rule events

In Kibana Universal Alerting, events with type: signal don't belong to an alert, so they don't appear on the Alerts page. In Discover, filter .rule-events to those events to review detection history, save it for investigations, or use it as input to a rule that opens an alert.

Before you begin

You have events with type: signal in .rule-events to query.
Your role can query .rule-events in Discover. For privilege details, refer to Configure access.

Key fields for these queries

These fields matter most when you query .rule-events.

Field	Why it matters
`type`	Filter with `type == "signal"` to exclude events with `type: alert`.
`@timestamp`	When Kibana wrote the document. Use for time ranges and sorting.
`rule.id`	Scope results to one rule.
`status`	Always `breached` for events with `type: signal`. These events don't include `recovered` or `no_data`.
`group_hash`	Identifies the series the event belongs to when the rule uses grouping.
`severity`	Optional. Set when the query emits a recognized `severity` column value.
`data`	Rule-defined payload from the source query. Useful for investigation and dashboards.

For the full field list, refer to Field reference. For how the shared schema works conceptually, refer to How Kibana stores rule events.

Common queries

Open Discover and run ES|QL against .rule-events. The following examples cover common workflows.

List recent events

Returns the most recent events with type: signal.

FROM .rule-events
| WHERE type == "signal"
| SORT @timestamp DESC
| KEEP @timestamp, rule.id, status, severity, group_hash, data
| LIMIT 100

Scope events to one rule

Returns events with type: signal from a single rule. Replace my-signal-rule-id with the rule's ID.

FROM .rule-events
| WHERE type == "signal" AND rule.id == "my-signal-rule-id"
| SORT @timestamp DESC
| KEEP @timestamp, status, severity, group_hash, data

Correlate events in a follow-on rule

Events with type: signal are useful for investigation, and as input to a rule that watches accumulated events and opens an alert. For example, one rule records administrator API calls. A separate rule queries those events and opens an alert only when call volume spikes.

Create a rule whose query reads from .rule-events, filters to the first rule's events with type: signal, and applies a threshold:

FROM .rule-events
| WHERE type == "signal"
  AND rule.id == "admin-api-calls"
  AND status == "breached"
| EVAL bucket = BUCKET(@timestamp, 15 minutes)
| STATS event_count = COUNT(*) BY bucket
| WHERE event_count > 10

When this follow-on rule finds a match, Kibana writes a rule event with type: alert. An action policy can evaluate the alert and invoke a workflow. The first rule keeps recording without paging anyone on every individual call.

Tip

You can also correlate events from more than one rule in a single query, for example combining administrator API call events with error-rate events, so neither source pages on its own.

Build a Discover session or dashboard

After you have a working query:

In Discover, save the search so you can reopen it during investigations.
Optionally create a visualization from the saved search, for example a count of events over time broken down by rule.id or severity.
Add the visualization to a dashboard that your team uses for incident review.

Because .rule-events is append-only, dashboards show the full history retained by index lifecycle management (ILM), not only the current state.

Rule mode: How configuration determines whether Kibana opens an alert or keeps matches available for later analysis.
Query alert history in Discover: Alert lifecycle, triage history, and incident-tracing queries.