Alert Grouping

Security Operations Center (SOC) analysts are responsible for detecting and responding to threats before they become incidents, working through a constant stream of alerts generated by detection rules across endpoints, users, networks, and cloud environments. The job isn't reviewing alerts one by one: it's deciding, under time pressure, which ones represent a real attack and which are noise.

The problem was that a single detection rule rarely produced a single alert. A brute-force attempt against 200 endpoints, for example, could generate 200 nearly identical alerts for the same incident, each appearing as its own investigation. Analysts spent a disproportionate share of their shift comparing duplicates and manually deciding whether alerts belonged together, rather than investigating the incidents that mattered. As environments generate more telemetry, this problem compounds. Detection quality alone stops being enough; triage efficiency has to scale with it.

I designed Elastic Security's alert suppression feature to group related events into a single representative alert, cutting volume without hiding any of the underlying evidence analysts rely on to investigate with confidence.

As the senior designer on this feature, I owned the end-to-end experience, from defining the interaction model through shipping across rule creation, alert investigation, and Timeline, working alongside a junior designer, product management, and engineering. I worked closely with the team to make sure the design held up against real detection-engine constraints, not just idealized workflows. I also mentored the junior designer on the team: they owned the Timeline drill-down states under my direction, and through weekly critiques they got to the point of defending that work in engineering reviews on their own. The feature entered the product as a technical preview in Elastic Security 8.6 (January 2023) and rolled out incrementally to more rule types in the releases that followed.

Security teams rely on detection rules to surface suspicious activity as fast as possible. The challenge is that many rules don't generate one alert. They generate hundreds or thousands of nearly identical ones for the same underlying incident. Each appeared in the queue as a separate investigation, even though they all pointed to the same event.

For analysts, this created a constant cycle of repetitive triage: reviewing duplicates, comparing alerts by hand, and deciding whether they represented the same incident, instead of investigating actual threats. As alert volume grew, so did the cognitive load required to figure out what deserved attention at all.

The issue was never detection. Elastic already surfaced suspicious activity effectively. The real challenge was helping analysts quickly understand what deserved their attention while preserving the evidence they relied on to investigate with confidence.

Before designing any grouping logic, I ran secondary research into existing alert-fatigue patterns and detection engineering practices, then led nine qualitative interviews across SOC analysts, SOC managers, and a detection engineer, the three roles closest to the problem, each with a different stake in how alerts get triaged and tuned.

This research shaped not just the design but how we'd measure whether it worked. Before designing the grouping experience, we defined four KPIs to track: average investigation time per incident (analyst effort), number of alerts opened per investigation (noise reduction), time to first meaningful action (prioritization), and percentage of grouped alerts expanded (whether analysts engaged with the grouping instead of bypassing it).

The design attacks noise at two distinct layers, and keeping them distinct was itself a design decision. Grouping in the alerts table works at view time: analysts collapse the queue by rule, host, or user to read it as incidents, without changing any data. Suppression works at write time: the rule itself consolidates duplicate events into one representative alert as they're created. They solve the same fatigue problem with very different trust implications, one is reversible with a click, the other decides what enters the queue at all, so each needed its own transparency model.

Alert suppression needed to be powerful enough for expert analysts, but never opaque. One of the biggest design questions wasn't how to group alerts, but how much of that grouping should be automated. A simpler approach would have hidden duplicate alerts entirely, creating a cleaner queue but making it difficult for analysts to understand what had been suppressed.

Research consistently showed that analysts valued transparency over automation, so rather than hiding grouped events, I designed the experience to surface suppression counts, preserve one-click access to every underlying event, and make the grouping logic configurable. The result reduced noise without asking analysts to blindly trust the system.

The alert detail view surfaces the suppression count, the representative event, and a one-click drill-down to every underlying event, so the investigation pathway stays intact even when hundreds of alerts collapse into a single row. The shipped product surfaces suppression through the flyout's Correlations panel; the concept shown here pushes that further, giving suppression a dedicated summary at the top of the alert details.

Alert suppression is AI-adjacent: the same feature powers ML-based detection rules that identify anomalous patterns across thousands of events, where suppression works differently than it does for standard threshold or query-based rules.

Working on Alert Grouping reinforced that the hardest design problems rarely have a single correct solution. Every decision meant balancing competing needs: reducing noise without hiding evidence, simplifying workflows without limiting flexibility, introducing automation without reducing analyst control. Rather than optimizing for one outcome, I learned to make those tradeoffs explicit and use them as a framework for every design decision that followed.