Incidents

An incident is Memnox saying a human should look at this now. Four detectors open one, and nothing else does, see Risk, drift and incidents for what each detects.

What an incident contains

Evidence is denormalized on purpose: the detail view needs no joins, so an incident opens instantly even when the audit table is large.

Deduplication

While an incident with the same (agent, trigger) pair is unresolved, new evidence attaches to it rather than opening another, for 24 hours.

An agent hitting the same rule in a loop therefore produces one incident with forty evidence events, not forty incidents. That is the difference between a system people watch and a system people mute.

The lifecycle

1. 1

   Open

   Nobody has looked. Notification has fired if configured.

2. 2

   Acknowledged

   Somebody has seen it and is on it. Records who and when.

3. 3

   Resolved

   Requires a resolution note, and records who wrote it.

Notification

Subscribe to incident.opened under Settings → Notifications and your own system is told the moment one opens.

Deliveries are signed with a shared secret you hold. A disabled subscription stays in place for the audit trail and receives nothing. See Notifications.

Reading the summary view

The header on Incidents counts them by status and by severity. It is what the badge in the sidebar is built from, and what a weekly report leads with.

Two numbers matter more than the total: how many are critical and open, and how many have been open without being acknowledged. An unacknowledged incident is one nobody has even claimed yet.

What to do about a recurring incident

A repeated_blocks incident that returns every week is not an agent problem. It is one of two things:

• the agent genuinely needs to do what it is being blocked from, and the policy is wrong;
• the agent has been given a job it should not have, and the capabilities are wrong.

Both are fixed upstream. Resolving the incident repeatedly fixes neither.