Events

An event is something your monitoring noticed: a server's CPU stays above 90%, a disk fills up, a health check fails. Events arrive from monitoring tools through an integration, or from the API, and land on the Events console. Each one is matched to the configuration item and the service it is about. Whoever watches the console acknowledges it, closes the noise, and raises an incident when it matters.

Events come with the Event Management plugin, built on Incident Management and Service Configuration. With the CMDB plugin on too, events are matched to configuration items and set their health. If you don't see Events under Event Management in the sidebar, the plugin is off; an admin turns it on under Platform → Plugins.

Who can use it

Who	Can
Operations	Read events and work on them: report, acknowledge, close, set the CI and service, raise or link an incident.
Incident Responder	The same.
Incident Manager	The same, and the dashboard.
Whoever holds rule.settings	Rules on events.
Agent, Viewer	Read events.
Auditor	Read events and the dashboard.
Analyst	The dashboard.
Platform Administrator, Organization Administrator	Everything.

An event belongs to a unit: the unit its integration's endpoint puts it in, or the one it was reported in. You see the events of the units you work in, and you work on them with event.write there. Raising an incident from an event also needs the right to declare incidents.

One event per alert

A monitoring tool repeats an alert while the problem lasts, and says when it is over. The desk keeps one event for it:

• The first report opens an event, EVT-1, EVT-2 …, with its severity, message and source.
• A repeat of the same alert (the same source and alert id, such as SigNoz's fingerprint) updates the event: how many times it was seen, when it was last seen, and the severity if it changed. A change of severity shows in the event's history.
• A clear (resolved, OK) closes it, as Cleared.
• Firing again within the hour after closing reopens the same event. Later, it is a new one.

Without an alert id, every report is an event of its own.

Severity

Critical, Major, Minor, Warning and Info. Monitoring tools' own words are understood: error and high are Major, medium is Minor, low and notice are Info, 1 to 5 go from Critical to Info, and an unknown word is a Warning.

While a Critical event is open or acknowledged, its configuration item (or, without one, its service) is in an outage; a Major one degrades it. Their health comes back when the event closes or drops below Major.

Matching the CI and the service

An event names what it is about in the source's own words: a host name, an FQDN, an IP address, a service name. The desk looks for a configuration item with that identifier or name, and a service with that code or name, in the event's organization. When nothing matches, the event keeps the source's words, shown faintly in the list, and you set the CI or service by hand on the event's page.

During a change

While a change is being carried out on an event's configuration item or service (started and not finished yet), its events are suppressed: kept, with Suppressed and the change on the event's page, but they set no health and no automation raises an incident from them. A clear closes a suppressed event as usual. When the change is finished, closed or cancelled and the alert still fires, the event opens again, and from then on it is handled as a new one. The Events console lists suppressed events with the Suppressed state filter.

Several alerts, one incident

When an incident is already open on an event's configuration item or service, a new event there is linked to it straight away and acknowledged, rather than waiting for someone to raise another. The incident's timeline lists each event linked to it.

Automations

Rules on events raise incidents, link, acknowledge, close or note events without anyone at the console: for example, raise an incident from a Major event on a production server that has lasted five minutes. See Rules on events. What a rule did shows in the event's history, by the automation's name.

The Events page

Open Events in the sidebar. The red number next to it is how many Critical and Major events aren't closed. The console looks again every 30 seconds.

The list shows the events that aren't closed, most recently seen first: the message with how many times it was seen (×3), the severity, the state, the CI, the service, the incident it is linked to, and when it was last seen. Columns adds when it was first seen, the reference and the source.

• Search finds words in the message, the alert name and the host or service the source named, or a key like EVT-12.
• Filters: State (Open, Acknowledged, Suppressed, Closed or Any state; not closed by default) and Severity.
• At a glance: how many events are Critical and major, Not acknowledged, and have No CI. Click a chip to show only those.
• Selecting events: tick the box at the start of a row. Acknowledge and Close work on every one selected.
• Keyboard: j and k move through the list, Enter opens, / jumps to the search.

The states:

State	Means
Open	Reported, nobody has taken it yet.
Acknowledged	Someone is looking at it.
Suppressed	While a change is being carried out on its CI or service: kept, never escalated.
Closed	Cleared by its source, or closed by someone.

The event page

The page shows the message, the description, the event's history (reported, severity changes, acknowledged, cleared, reopened, the CI or service set, the incident) and the alert as the source sent it. The side panel has the severity, the state, when it was first and last seen, the CI and service (to change them), the source, and a link back to the alert in the monitoring tool.

• Acknowledge says you are on it.
• Close… closes it, with a note when you want one (noise during a backup, for example). Closing is recorded in the audit log with the note.
• Raise incident declares an incident from the event, in its unit, on its CI and service, starting when the event was first seen. Its impact and urgency follow from the severity (Critical: high and high, Major: high and medium, Minor: medium and medium, Warning: low and medium, Info: low and low); change them, or the title, before raising. The incident's summary links back to the event.
• Link to an incident (under …) links the event to an open incident instead, when one is already being worked on. Several events can be linked to the same incident.

An open event that is raised or linked is acknowledged with it. The incident's timeline shows each event raised from it or linked to it.

The dashboard and evidence

The Event Management dashboard shows what is live and needs an incident, and over a period what came in, what became an incident and what was noise. For auditors, Monitoring events is a source of evidence: every event of a period, and one event's history as a PDF.

Reporting an event yourself

Through the API, POST /api/v1/x/events with the unit, the message and the severity reports an event the same way monitoring does; give it a sourceKey so repeats update it. See Event Management in the API.

AI assistants

With the MCP server, an assistant can list and read events, acknowledge and close them, and raise or link an incident from one, with the same permissions as the person.