The three triage queues, and which two work

Three entries in the navigation look like they might be the same list: Alerts, Notable events and Risk incidents. They are not, they are not layers of one another, and one of the three is empty. Working out which is which by clicking is a genuinely confusing twenty minutes, so this article does it for you.

Alerts — the queue that works

Every detection that fires writes an alert. The alert carries its own triage lifecycle: five states, an assignee and a close reason. It is edited at PATCH /api/v1/organizations/{orgID}/siem/alerts/{alertID}, gated on siem:alerts.write; reading the list needs siem:alerts.read.

The vocabulary is small on purpose and the four close reasons are worth using precisely rather than defaulting to one. False positive means the detection was wrong. Benign expected means the detection was right and the activity is fine — a backup account doing what backup accounts do. Those are different findings about your environment and they lead to different tuning, so collapsing them into one costs you the information later. Alert states and who owns one covers the lifecycle in full, and Suppressing a false positive covers what to do once you have decided.

Risk incidents — the queue that catches what one alert cannot

Risk incidents at /siem/risk is a different question from what fired. It accumulates risk against an entity — a user, a host, an address — across every rule that contributed, and opens an incident when the accumulated score or the diversity of signals crosses a threshold. That is the mechanism that notices an intrusion made of five individually unremarkable events.

Its own status vocabulary is six values, not five, and it is not the same list as the alert states: open, acknowledged, investigating, resolved, false_positive, dismissed. The last three are terminal.

Reading incidents, entities and the policy needs siem:risk.read; changing an incident or the policy needs siem:risk.write. The two minimums in that table are the ones worth understanding before you tune anything: requiring three distinct tactics and two distinct sources is what stops one noisy rule firing forty times from manufacturing an incident on its own. How alerts are grouped into incidents is the full account of the scoring, including what is wired and what is not.

Notable events — an empty queue, and why

The Notable events page describes itself as a triage queue promoting high-risk alerts into analyst cases. That is an accurate description of what it was built to be. Nothing promotes anything into it.

Being specific, because partly built is exactly the state that produces a confident answer from a salesperson and a support ticket from you:

• The table exists and so does the code that would insert a row into it.
• Nothing calls that code. There is no automatic promotion from an alert, no promotion from a risk incident, and no endpoint that lets you create one by hand. The insert function has exactly three appearances in the codebase: its own implementation, its interface declaration, and a test mock.
• The two routes that exist are a list and an update. GET /api/v1/organizations/{orgID}/siem-notable needs siem:alerts.read and returns an empty array. PATCH …/siem-notable/{id} needs siem:alerts.write and has nothing to patch.

Two smaller details, in case you go poking at the API. Its list route is hardcoded to fifty rows with no pagination parameters at all. And the update route accepts a close_reason field which is accepted and then discarded — the statement that runs sets only the triage state, the assignee and the timestamp. A caller would get a 204 and a silently dropped field.

Why write any of this down? Because the honest answer to what does that page do is better than the alternatives. A reader who is told it is empty stops looking. A reader who is not told spends an afternoon assuming they have misconfigured something.

Two more things in the product that look like detection and are not

While we are being direct about inert surfaces, two adjacent ones belong here because they are reachable and would otherwise mislead in the same way.

Alert rules

POST and GET on /organizations/{orgID}/siem/alert-rules store a name, a severity and an opaque condition string. Nothing reads that condition. They are inserted, listed and toggled active, and never evaluated. Do not build a detection here and expect it to fire; use the detection library and its tuning, which is real — see Tuning a detection rule.

Correlation chains

Eight multi-step correlation rules are defined, validated and seeded into the catalogue, describing sequences such as this, then that, within a window. No engine evaluates them. The detection that does work is per-rule, including thresholds, distinct-value counts and cooldowns over a window — see The detection library for what a rule can express.

Neither of those is a defect you can work around; both are gaps you should know about so you do not rely on them. What actually catches a multi-stage intrusion today is the risk accumulation described above, and it does that per entity rather than per named sequence.

So what should you actually work through?

1. 1

   Start at Alerts, filtered to new

   This is your queue. Sort by severity, take the top of the list. What to do when an alert arrives is the procedure if you have no security team.

2. 2

   Set a state and an assignee on anything you touch

   Even if the assignee is you and the state is investigating. An alert nobody has claimed is an alert two people will each assume the other looked at.

3. 3

   Close with the right reason

   false positive and benign expected are different answers. Choosing correctly is what makes next month's tuning conversation possible.

4. 4

   Check Risk incidents at least weekly

   It is the surface that shows you the pattern rather than the event, and its default window is 24 hours for scoring with a seven-day diversity window — so a slow campaign appears here before it appears anywhere else.

5. 5

   Do not check Notable events

   It is empty. Come back to it if a release note says otherwise.

What to read next

1. Alert states and who owns one — the lifecycle in the queue you will actually use.
2. How alerts are grouped into incidents — the risk scoring behind the second queue, and its honest limits.
3. Alert severity and triage — what to take first when everything looks urgent.