Understanding and resolving an alert

An alert watches a set of device metrics and opens an event when something is wrong. There are two kinds of wrong, and telling them apart is the first step in responding to one.

Two kinds of event

The two are independent, and an alert can be configured for either or both. An alert with no threshold event is not evidence that the site is fine — it may simply mean nothing is arriving to evaluate, which is what the stale data event exists to tell you.

Finding events

The Alerts list shows every alert in the project with its priority and whether it is enabled, and flags any with something currently active.

View all events opens the event history. Events are grouped under their alert, each row showing when it triggered, its type, and whether it is still triggered or has been resolved. An Active only toggle filters out everything already closed.

What an event records

Opening an event shows when it triggered, its current status, and — once closed — when it was resolved, by whom, and any resolution note. Beneath that is the trigger data: the actual readings that opened and sustained the event, with device, metric, value and timestamp.

That table is the useful part when you are working out whether a breach was real. A single spike among otherwise normal readings reads very differently from a run of values climbing steadily past the limit.

Responding

1. Identify the event type. Threshold exceeded and stale data lead to completely different responses.
2. For a threshold event, review which device breached, which threshold label was crossed, and the readings in the event's trigger data.
3. Confirm the reading is credible before escalating. Check whether the same alert also has a connection status event, and whether that device has behaved oddly before.
4. Follow your project's response or escalation procedure. BDI Cloud reports that a limit was crossed; the engineering judgement about what it means is yours.
5. Acknowledge, then resolve when the situation is closed out.

For a connection status event, the useful question is where the silence starts. If every device on a connection went quiet together, look at the connection in Pipeline Manager. If one device went quiet alone, look at that instrument or its power.

Acknowledging

Acknowledging records that someone is dealing with the event, and it stops further notifications going out while leaving the event open.

That makes it the right tool when you know what is happening and do not need to keep being told — during planned works that will breach a threshold, for instance. It changes nothing about the measurement, and an acknowledged breach is still a breach.

Acknowledgement can be removed again if it was applied in error.

Resolving

Resolving closes the event. It cannot be undone — a resolved event stays resolved, and a later breach opens a new one.

Events can also resolve themselves when the condition clears — readings returning within limits, or data starting to arrive again. Automatic resolutions are recorded against the event, so the history still shows what happened and who or what closed it.

Add a resolution note when you close something out by hand. Notes can be edited later if you learn more. "Heat from welding in the area" turns an entry in a list into an explanation, and the next person reading the history is usually trying to work out whether a repeat is the same cause.

The history is worth reading when nothing is wrong

Resolved events stay in the alert's history with their trigger data and notes.

A device generating a short connection status event every few days is telling you something about its power or connectivity before it fails completely. A threshold that trips and self-resolves repeatedly is either set too tight or describing real behaviour nobody has looked at yet. Neither shows up if the history is only consulted during an incident.