Loading

Observe and analyze signals in the experimental alerting system

When a rule runs in Signal mode, it writes each match to .rule-events as a signal. Signals don't open alert episodes or trigger notifications. Use them to build detection history, investigate incidents in Discover, create dashboards, or feed follow-on Alert mode rules that correlate activity across sources.

This page shows how to query signals, which fields matter most, and how to turn signal history into Discover sessions and dashboards.

  • You have at least one rule running in Signal mode.
  • Your role can query .rule-events in Discover. For privilege details, refer to Configure access.
  • You've added .rule-events as a data view. If you haven't, follow the steps in Before you begin on the alert history page, using the .ds-.rule-events-* index pattern.

Alert episodes and signals share the .rule-events data stream and most of the same fields. Use type to filter for signals only. Signal documents don't include episode.* fields.

Field Why it matters for signals
type Filter with type == "signal" to exclude alert episode documents.
@timestamp When the evaluation ran. Use for time ranges and sorting.
rule.id Scope results to one Signal mode rule.
status Outcome of the evaluation (breached, recovered, or no_data).
group_hash Identifies the series the signal belongs to when the rule uses grouping.
severity Severity assigned by the rule, if configured.
data Rule-defined payload from the source query. Useful for investigation and dashboards.

For the full shared field list and the alert-only episode.* fields, refer to Rule event data model.

Open Discover, select your .rule-events data view, and run ES|QL against the stream. The following examples cover common signal workflows.

Returns the most recent signal documents across all Signal mode rules.

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

Returns signals 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

Signal mode is useful on its own for investigation, and as input to an Alert mode rule that watches accumulated signals. For example, a Signal mode rule records administrator API calls. A separate Alert mode rule queries those signals and opens an episode only when call volume spikes.

Create an Alert mode rule whose query reads from .rule-events, filters to the Signal mode rule's output, 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 signal_count = COUNT(*) BY bucket
| WHERE signal_count > 10

When this Alert mode rule finds a match, the system opens an alert episode that action policies can route to a workflow. The underlying Signal mode rule keeps recording without paging anyone on every individual call.

Tip

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

After you have a working signal 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 signals 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.