> For the complete documentation index, see [llms.txt](https://docs.voltmasters.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.voltmasters.io/voltmasters-platform/9.-incident-management.md).

# 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.

### 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

<details>

<summary><strong>Which incidents trigger a notification?</strong></summary>

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.

</details>

<details>

<summary><strong>How long before a notification is sent?</strong></summary>

| 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         |

</details>

<details>

<summary><strong>How do I configure notification recipients?</strong></summary>

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.

</details>

<figure><img src="/files/ysTHBZ6HK7AOUeUHINKa" alt="Voltmasters EMS: Incident rules"><figcaption><p>Voltmasters EMS: incident management</p></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.voltmasters.io/voltmasters-platform/9.-incident-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
