Groups: how Qevlar groups similar alerts

What is a group?

A group collects alerts that describe the same activity: the same detection firing on the same users, hosts, IP addresses, domains, file hashes or other observables, over a short period. Instead of triaging twenty look-alike rows one by one, you review one group, read one summary, and decide once.

Groups are built from the signal the alerts share, not from their verdict. A group can therefore be malicious (a phishing campaign hitting thirty mailboxes), benign (a misconfigured scanner tripping the same rule every hour) or suspicious. Noise is noise whatever its colour, and grouping benign alerts is where most of the time saving comes from.

Every alert in a group is still fully investigated on its own. Grouping changes how alerts are presented and reviewed. It never skips an investigation, and every alert keeps its own report, verdict, ID and timestamps.

How grouping works

1. Each alert is investigated as usual. Observables are extracted, enriched and assessed, and the alert receives its own verdict and report.
2. Qevlar looks for look-alikes. At the end of the investigation, the alert’s observables and title are compared with other recent alerts from the same profile.
3. A group must share a concrete observable. An alert only joins an existing group when at least one of its observables is already present in that group, and the overall similarity is high enough. Two alerts that merely “feel” similar are not grouped.
4. An AI check confirms the match. Before an alert joins or starts a group, Qevlar’s AI verifies that the alerts genuinely describe the same activity. If it cannot confirm that, the alert stays on its own. Qevlar prefers a missed grouping over a wrong one.
5. New groups start from very recent pairs. A new group is created when a very recent look-alike exists. An existing group keeps accepting matching alerts for 4 days, after which a new group is started for the next wave. Existing groups are never split or shrunk retroactively.
6. The group is described. Once a group exists, Qevlar generates a title naming the shared signal, a summary explaining why the alerts were grouped, a one-sentence verdict, a severity with its reasoning, the observables shared by every member, and recommended next steps. These are regenerated as new alerts join.

Groups in the Investigations list

The Investigations list has three views, selectable at the top left:

• Combined (default): groups and single alerts in one list, sorted by last update. An alert that belongs to a group is shown inside its group, not as a separate row, so the list contains no duplicates.
• Groups: only groups. The Alerts / Group column shows the number of member alerts.
• Alerts: every alert individually, including grouped ones. Grouped alerts carry a #N chip pointing to their group.

Each group row shows the group number (#74), its title, verdict, severity, time span, profile, detection sources, and review state (assigned to whom, reviewed by whom).

• Expand a row with the arrow on the left to preview the first alerts in the group. See all opens the group.
• Search by title, observable value, alert ID or group number.
• Show reviewed alerts: reviewed groups and alerts are hidden by default. Tick this box to show them again.
• Row actions (the ⋮ menu): Confirm verdict, Assign, Change verdict. On a group row these apply to every alert in the group.

The group page

Click a group to open it.

Header

• Title and verdict. The title names the signal the alerts have in common, not the number of alerts or the time span, so it stays stable as the group grows. If a verdict was changed by your team, the original verdict is shown struck through next to the new one.
• Detection source, assignee, severity with a tooltip explaining the severity reasoning.
• Agree / Disagree menu. Agree confirms the verdict of every alert in the group in one click. Disagree: change verdict sets a new verdict for every alert in the group (see below).
• + Add Context lets you record environment knowledge (an approved tool, an expected behaviour) so that future investigations take it into account.

Boundary strip

Three figures tell you what you are deciding on before you read anything else:

• Alerts in group: how many alerts are in the group, with a bar showing how their verdicts are split.
• Time span: from the first to the last alert in the group.
• Observables: the observables every member alert has in common.

Summary tab

• Group summary: why these alerts were grouped, and the group verdict in one sentence. The summary describes the shared activity; the verdict is the only place judgement is expressed.
• Shared observables: the observables found in all member alerts. Click one to open its details.
• Next steps: a preview of the remediation actions recommended for the whole group.
• Alerts in this group: the full list of member alerts with their own verdict, time, and detection. Each row has its own Confirm verdict / Assign / Change verdict menu, and opens the alert’s full report.

Observables tab

Shared observables with their type and tags. Click one to open the side panel: its tags, how Qevlar got to it, the tools used, and where else it was seen (first and last seen in other investigations, and the alerts outside this group that contain it).

Next steps tab

The remediation steps recommended for the group, deduplicated across members. When the same indicator appears in several alerts (the same sender domain in twelve phishing alerts, for instance), it is listed once with every alert that contributed it. A banner reminds you that these steps apply to all alerts in the group. Each step carries a Why? justification and a thumbs up / down so you can tell us whether it was useful.

Reviewing a group

Agree with the group verdict

Agree (header) or Confirm verdict (row menu) confirms the current verdict of every alert in the group and marks them as reviewed. A confirmed group is closed: no further alerts will join it.

Change the group verdict

Disagree: change verdict opens a two-step panel.

1. Choose verdict: pick Malicious (confirmed threat, remediate), Inconclusive (needs further investigation) or Not harmful (benign or expected activity), and explain why you disagree. The reason is mandatory (up to 500 characters). It is stored in the verdict history, visible to your team, and displayed on every alert in the group.
2. Review impact: the panel shows the current verdict split and the verdict every alert will receive. If some alerts were already given a different verdict by hand, they are listed under a warning so you can check before overwriting them.

Applying the change sets the new verdict as client feedback on every alert in the group, marks them all as reviewed, and closes the group. Alerts that have no completed investigation yet are skipped and counted as such in the confirmation.

Change the verdict of a single alert

From the Alerts in this group table, Change verdict on one row changes only that alert.

Assign a group

Assign on a group assigns the group and every alert in it to the chosen teammate.

Frequently asked questions

Does a group verdict override the verdict of its alerts?
No, not by itself. The group verdict is a synthesis of its members’ verdicts. Each alert keeps its own verdict until you explicitly confirm or change it, at the alert or at the group level.

Two alerts in a group have different verdicts. Is that a bug?
No. Grouping is about the shared signal, and the same campaign can contain a user who clicked and nineteen who did not. Divergent members are highlighted in the group so you can read why, and the group verdict wording reflects the split rather than averaging it away.

Why was this alert not grouped with the others?
Most often because it shared no observable with the existing group, because its look-alikes were older than the grouping window, or because the AI check could not confirm the alerts describe the same activity. Qevlar is deliberately conservative here: an incorrect group costs more analyst trust than a missed one. If you believe alerts should have been grouped, use Create Team Feedback on the group.

Why did a new group appear for something that already had a group?
Groups stop accepting new alerts a few days after they were created. Recurring noise therefore shows up as a series of bounded groups rather than one ever-growing group. Existing groups are never split.

Alert groups in the API

Alert groups are available read-only on the public API:

An investigation result also carries a nullable alert_group object when the alert belongs to a similar-alert group, the kind this page describes. It is null for an alert with no look-alikes, even though that alert is still grouped for incident purposes, so an automated workflow can decide whether to act per alert or per group.

Notes:

• /alerts lists only members whose investigation is complete, so it can return fewer rows than the group's alerts_count.
• Each member also carries is_outlier, true when its verdict differs from the group's most common one. In a unanimous group, every member is false.
• The verdict split across members comes from /alerts, not from the group endpoint.
• Every group you cannot reach returns the same 404 — another tenant's, a deleted one, an unknown or malformed ID, or a group of a different kind. The API never distinguishes between them.
• Group verdict changes, assignment and review state are not available through the API yet.