Query experimental alerting system signals in Discover

Use ES|QL in Discover to query .rule-events for events with type: signal. This page covers the fields to filter on, example queries, and how to save that history as a Discover session or dashboard.

  • You have at least one rule that writes events with type: signal. For how that is set, refer to Rule mode.
  • Your role can query .rule-events in Discover. For privilege details, refer to Configure access.

The examples on this page use ES|QL (FROM .rule-events). You don't need a data view for those queries. If you query .rule-events with KQL instead, add it as a data view first. Follow the steps in Before you begin on the alert history page, using the .ds-.rule-events-* index pattern.

These fields matter most when you query .rule-events. Filter with type == "signal" to exclude events that belong to an alert episode.

Field Why it matters
type Filter with type == "signal" to exclude events that belong to an alert episode.
@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 Rule event data model.

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

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

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

Events with type: signal are useful for investigation, and as input to a rule that watches accumulated events and groups matches into an episode. For example, one rule records administrator API calls. A separate rule queries those events and groups matches into an episode 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 and groups it into an alert episode. An action policy can evaluate the episode 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.

After you have a working query:

  1. In Discover, save the search so you can reopen it during investigations.
  2. Optionally create a visualization from the saved search, for example a count of events over time broken down by rule.id or severity.
  3. 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.