Beyond Notifications: Why Elastic’s Experimental Alerting Is A New Event Architecture

Alerting systems have traditionally followed a simple, linear path: a condition is met, an alert fires, and a notification is sent. While this model is intuitive, it creates significant overhead. In the classic approach, the rule is the center of the universe. It decides what matters, triggers the action, and often dictates the notification logic. This tight coupling makes systems rigid, noisy, and difficult to manage at scale. Elastic’s experimental alerting system in Kibana breaks this mold by decoupling several concepts that were once glued together. By separating detection, state, evidence, routing, and automation, Elastic is not just refining alerting; it is shifting toward an event-driven architecture.

A Match No Longer Has One Meaning

The most profound change in this design is the distinction between Alert mode and Signal mode. In traditional systems, a rule matches and an alert is immediately born. With this experimental architecture, a rule evaluates data, but the system handles the result differently based on the mode. In Alert mode, the system creates an alert episode. In Signal mode, the match becomes a persistent signal, recorded as a searchable document in Elasticsearch. This subtle shift allows rules to focus on identifying meaningful conditions without being forced to decide who needs to be paged. Detection and action are finally treated as two separate problems.

Detection as Software Engineering

Security and operations teams often struggle with the binary choice of enabling a rule or ignoring it. If a rule is noisy or experimental, activating it in production can overwhelm analysts. Signal mode solves this by preserving the detection result without creating an operational burden. Teams can now implement a mature progression for their rules: detect, signal, observe, tune, and only then promote to full Alert mode. This makes detection development feel more like software development, where testing and tuning occur before an incident is generated.

The Power of Signals as Building Blocks

Signals are the most exciting part of this architecture. Because they are saved as documents in Elasticsearch, they are searchable, visualizable, and aggregatable. This creates a recursive model for detection. A low-level rule can generate signals that a second, higher-level correlation rule then analyzes. This architecture shifts from a simple Rule-to-Alert model to a sophisticated chain of events. A complex incident is no longer a single, isolated trigger but a collection of evidence assembled into an alert episode. This approach naturally reduces noise by requiring multiple signals to confirm a threat before an analyst is interrupted.

Alert Episodes as a State Machine

By introducing the concept of an alert episode, Elastic moves away from treating every match as an independent unit of work. An episode tracks the lifecycle of a problem, moving through states like pending, active, recovering, and inactive. This is transformative for persistent issues like CPU saturation or network latency. Instead of receiving thirty alerts for a single thirty-minute event, the system tracks one episode. The unit of work is now the lifecycle of the problem, making alert queues far easier to reason about and manage.

Action Policies and Decoupling

In older systems, notification logic is often embedded within the rule itself. If eighty rules need to send alerts to the same Slack channel, managing that configuration is a nightmare. Elastic’s action policies decouple routing from the detection logic. A rule determines the condition, while a shared action policy determines where and when to trigger a workflow. This means administrators can update notification settings or escalation policies across hundreds of rules by changing a single shared object. It is a massive win for maintainability.

A New Era for Operations

The true benefit of this architecture is change isolation. Because rules, policies, and workflows are independent, teams can modify one layer without breaking the others. Detection engineers can focus on logic, while SREs can refine policies, and automation specialists can build complex workflows. This creates clear governance boundaries and reduces the blast radius of configuration changes. While the system is currently experimental, it offers a glimpse into the future of operations. By moving away from reactive notifications and toward a structured, state-aware event architecture, Elastic is providing the tools necessary to turn raw telemetry into actionable intelligence.