Alert states, and who owns one

An alert has two properties that decide whether your queue is a working system or a list of things nobody is doing: a state, which says how far through it you are, and an owner, which says whose problem it is. This article covers both, plus the part people get wrong — what happens to your risk picture after you close one.

There is some unflattering detail here. The logs side and the endpoint side do not use the same vocabulary, the logs side carries two overlapping state fields rather than one, and there is no enforced workflow between states. Those are real properties of the product today rather than things you are misreading.

The states an alert can be in

Alerts raised by the detection library — the logs and detection side — accept six values. Alerts raised by the endpoint sensor accept four of those six. Both start at open.

The gap between the two columns is history rather than design: the modules grew separately and their state lists were never reconciled. It matters rarely in practice, because an endpoint alert you would have called dismissed is usually honestly a false_positive, and one you would have called investigating is covered by acknowledged.

The second field on the logs side

Alerts from the detection library carry a second, independent state alongside the one above — a triage state, with the values new, investigating, pending, resolved and closed. It exists so that an analyst workflow can run without disturbing the original status field, and pending is the value the first field has no equivalent for: waiting on somebody else, usually the person you telephoned.

Two fields describing overlapping things is not ideal and we are not going to pretend otherwise. The practical guidance is to pick one and be consistent across your organisation, because an alert whose status says resolved and whose triage state says investigating is worse than either alone — it tells a colleague, and an auditor, two different stories.

Who owns an alert

Ownership is recorded as an assignment on the alert itself. There is no separate assignment action to remember: the assignee is set on the same update that changes the state, so acknowledging an alert and putting your name on it is one operation rather than two.

The convention that works in an organisation without a rota is simple and it is worth writing down before you need it:

• Acknowledge and assign in the same movement. An alert marked acknowledged with nobody's name on it is the state in which work quietly stops.
• One name, never a group. A shared mailbox is not an owner. If two people are looking, one of them owns it and the other is helping.
• Hand over explicitly. Reassigning is a deliberate act with a record. Leaving an alert assigned to somebody who has gone on holiday is how a critical finding survives a fortnight.
• Unassigned and open is the only honest resting state. If nobody owns it, do not put a name on it to make the board look tidier.

Changing an alert's state or its owner requires the alert-write permission, which the built-in member role holds and viewer does not. That is deliberate: reading the queue and changing the record of what was decided about it are different levels of trust. See Who can see and do what.

Changing the state, and what the platform records

A state change is a single update against the alert, sent as an HTTP PATCH from the console. Two things happen automatically alongside it and both are useful later.

A resolution timestamp

Moving an alert to resolved stamps the moment it happened. That timestamp, subtracted from the alert's creation time, is your real time-to-resolution — which is the only figure in this area that is worth reporting to anybody, because it is measured rather than estimated.

An audit entry

Who changed it, from what, to what, and when. This matters more than it sounds: the record a supervisory authority reads after an incident is the sequence of what was observed, what was decided and what was done, and a status change is one of those decisions.

One rough edge to recognise from its symptom rather than its cause: a state value the platform does not accept is not rejected politely. It reaches the database, the database refuses it, and you get a server error rather than a helpful message:

HTTP 500
{"error":"failed to update alert"}

If you see that while working the queue normally, it is almost certainly a client sending a value from the wrong module's list — an endpoint alert being set to dismissed, for instance. It is our defect rather than your mistake, and the alert itself is untouched.

Why resolved should carry a reason

There is a close-reason field on alerts from the detection library — short, free text, up to eighty characters. It is not mandatory and the platform will let you resolve an alert without it. Fill it in anyway, and fill it in on every alert you close.

The argument is not tidiness. A resolved alert with no reason is indistinguishable, six months later, from an alert somebody closed to make the number go down. That distinction is exactly what an auditor, an insurer or your own successor is trying to establish, and it cannot be reconstructed from the timestamps. Eighty characters is enough for the sentence that matters: confirmed with J. on the phone, was travelling or service account, expected behaviour after the new backup job.

The same logic applies with more force to false_positive. A documented decision that a detection was wrong is a governance act and a legitimate input into tuning the rule later. An undocumented one is indistinguishable from not having looked. Marking a real alert as a false positive to clear the queue is how an organisation trains itself blind, and the reason field is the thing that makes that visible before it becomes a habit.

A closed alert still counts toward risk

This surprises people and it is deliberate. Closing an alert does not immediately clear the risk attached to the person or the machine it named.

Entity risk is computed from the signals observed against that entity over a rolling twenty-four-hour window, and that computation does not consult alert status. So an alert you resolved at nine in the morning keeps contributing to the account's risk score until its underlying signal ages out of the window. What lowers the score is time passing without further signals, not you clicking resolved.

There is a related behaviour on the correlated side worth knowing. A single entity holds one open risk incident at a time: while that incident is open, further signals are folded into it rather than producing a second one. Resolving, dismissing or marking it a false positive is what allows a new incident to be opened for that entity later. So closing there does have an effect — not on the score, but on whether the next burst of activity gets its own case file.

The practical consequence for triage: if you resolve an alert and the subject's risk stays high, do not assume something is broken and do not go looking for another alert to close. Check whether other signals fired against the same entity, wait out the window, and treat a persistently high score as the thing it is — a statement about accumulated observations rather than about your paperwork.

What to do next

1. What to do when an alert arrives — the order to work an alert in, and the actions that destroy evidence.
2. Alert severity, and what a match actually means — why a critical alert is not the same as a certain one.
3. When to bring in a human — the specific signals that mean stop and telephone somebody.
4. Agree the assignment convention above with whoever else works your queue, in writing, before you need it.