# Incident management

> Track incidents on a Voltmasters EMS project: the incident list with its tabs and filters, and what each entry says about device and type.

Source: https://voltmasters.io/en/docs/voltmasters-platform/incident-management/

### Incident overview

The **Incidents** page lists all active and historical incidents for the project. Each entry shows the project, device, incident type and a description. Use the filters to focus on unresolved issues or to search the incident history.

Project-specific incidents can also be accessed via the **Incidents** tab within a project.

### The tabs

The incident list is split into three tabs:

| Tab | What it shows |
| --- | --- |
| **Open incidents** | Everything currently unresolved. This is the working view. |
| **All** | Open and closed incidents, muted ones excluded. |
| **Muted** | Only the incidents of a muted type, so a silenced type stays inspectable. |

### Muting an incident type

Some alarms are correct but not useful on a given installation: a device that is knowingly offline, a limitation that is expected on this site, a warning about hardware that is being replaced next week. Rather than living with a permanently red list, you can **mute the incident type**.

Muting works **per type**, not per incident. From an incident in the list, use the mute action and choose the scope:

| Scope | Effect |
| --- | --- |
| **Mute for device** | Only this device stops raising this incident type. Other devices keep raising it. |
| **Mute for project** | No device in the project raises this incident type any more. |

Device scope is the one to reach for by default; project scope is for a type that is genuinely irrelevant to the whole installation.

**What muting does and does not do:**

-   Incidents of a muted type are **still recorded**. They move to the **Muted** tab instead of the open list, so nothing is lost and you can always see what has been happening.
-   Muted incidents **no longer send** email or push notifications.
-   Muting is **reversible** at the same scope it was applied: unmute for the device, or unmute for the project.
-   The **Muted by** column shows who muted the type, so a silenced alarm can always be traced back to the person who silenced it and the decision can be revisited.

A type can also be muted for a **deleted** device, which matters when a removed device keeps producing noise on its way out.

> **Warning**
>
> Muting hides a symptom, it does not fix a cause. Use it for a known and accepted situation, and prefer the device scope so the same alarm elsewhere in the installation still reaches you. Review the Muted tab every so often: a mute that was meant to last a week has a way of lasting a year.

### Severity

Each incident has a severity: **Info**, **Warning** or **Critical**. Notifications are deliberately limited: both **email** and **mobile push** notifications are only sent for **Critical** incidents, so the channels stay meaningful and do not fill up with informational noise. Incidents of every severity remain visible in the incident list. Some controller- and grid-level incidents are treated as **emergency notifications** and are surfaced immediately.

### Frequently asked questions

**Which incidents trigger a notification?**

Almost all incidents appear in your incident list, including faults, warnings and informational alerts for devices, the EMS controller and grid limits.

**Email notifications** are bundled and delivered for **Critical** incidents only:

-   A first email is sent once the incident has been open for **at least five minutes** (not yet resolved and not previously included in a bundle).
-   A follow-up email may be sent approximately **twelve hours** after the incident began, if it is still open at that time.

**Mobile push notifications** are likewise limited to **Critical** incidents. A push notification is withdrawn automatically once the incident it announced is resolved.

Incidents of severity *Info* and *Warning* are recorded and shown in the incident list, but do not generate an email or a push notification.

**How long before a notification is sent?**

| Notification channel | Timing |
| --- | --- |
| Email (Critical incidents) | After the incident has been open for at least 5 minutes |
| Email follow-up | Approximately 12 hours after the start of the incident, if still unresolved |
| Mobile push (Critical only) | Sent when the incident is raised, and withdrawn when it is resolved |

**How do I configure notification recipients?**

Under **Settings → Incident rules**, you can control which users receive notifications for this project.

1.  Navigate to **Settings → Incident rules**.
2.  You will see a list of users associated with the project.
3.  Toggle the switch next to a user's name to **on** to enable email and portal notifications for that user.
4.  Toggle it **off** to stop sending notifications to that user.

This configuration is per project; changes here only affect notifications for the current project.

![Voltmasters EMS: Incident rules](https://voltmasters.io/assets/docs/image-78.webp)

*Voltmasters EMS: incident management*