> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spirii.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Faults & Alerts

> Cut the time between a charger failing and you finding out.

The Monitoring list shows every charge box that is offline and every EVSE reporting a fault. Alerts email you when either happens.

## Overview

Charging hardware fails, and the sooner you know the less it costs you. Connect gives you two ways to find out: a list you can work through, and an email for when nobody is looking at the list.

<CardGroup cols={2}>
  <Card title="The Monitoring list" icon="triangle-alert">
    Everything currently offline or faulted, with the error codes the hardware sent and the tools to act on each one.
  </Card>

  <Card title="Alerts" icon="mail">
    An email when a charge box goes offline or an EVSE reports a fault, anywhere in your network.
  </Card>
</CardGroup>

Both reflect what your charge boxes report. Statuses and error codes come from the hardware, so what you see is what the charge box last sent.

## The Monitoring list

Find it in Connect under **Operations → Monitoring**. It lists every charge box currently offline and every EVSE currently in a faulted state, along with the error code and any information message the charge box has sent, and when each was last checked.

### Offline and faulted are different things

Connectivity belongs to the charge box; fault state belongs to the EVSE.

A charge box that has gone offline has stopped talking to the platform, so the last status you have is the last one it managed to send. A faulted EVSE sits on a charge box that is still connected and actively reporting a problem, which is why it can give you an error code and a message.

The list therefore holds two kinds of row, and an offline charge box gives you less to go on than a faulted EVSE does.

### Who sees what

The list respects the customer hierarchy. Impersonation works here, so you can narrow the view to a single customer's sites, and Editors can see the Monitoring list for the locations they have access to.

### Acting on a row

Each row carries the tools for that charge box or EVSE: remote commands, the OCPP logs, its configuration, and its status and connectivity history. The list is where you find the problem; those tools are where you work out what happened and act on it.

## Alerts

Alerts turn the Monitoring list into something that reaches you. Set one up under **Settings → Alerts**: choose the trigger, choose the alert type, give it the email address to notify, and write the subject line you want to see in your inbox.

<Frame>
  <img src="https://mintcdn.com/spirii-7457b714/Hq2YBNx3n8oQoC1s/images/components/alerts.png?fit=max&auto=format&n=Hq2YBNx3n8oQoC1s&q=85&s=28ffa0f1df1950ab8e214bd621e3a3f6" alt="The Create notification dialog in Spirii Connect, showing the notification trigger, notification type, recipient email address, custom email subject line, and an Is active toggle" width="1172" height="1350" data-path="images/components/alerts.png" />
</Frame>

The subject line is the only part of the alert most people read on a phone, so `Charger offline — Munich DC Hub` beats a generic line when three arrive at once. The recipient does not have to be you, so a shared operations inbox works.

### What fires, and when

An alert fires when a charge box goes offline or an EVSE reports a fault, anywhere in your network. There is a delay before it sends, so a charge box that drops and recovers within a few minutes will not generate an email. That keeps a flapping connection from filling your inbox, and it means every alert you receive represents a fault that has persisted.

Alerts tell you when a fault is registered. The Monitoring list is where you see what is currently affected, so a charge box that has recovered drops off it.

## Dependencies & limitations

* **Alerts are network-wide.** An alert covers every charge box and every EVSE under your account.
* **Brief interruptions do not alert.** The delay before sending means a charge box that drops and recovers quickly will not produce an email.
* **The list reflects what the hardware sends.** Statuses, error codes, and information messages come from the charge box. An offline charge box carries no error code, because it stopped reporting.
* **Editors see their own locations.** Impersonation applies, and the list follows the customer hierarchy.

## Related

Once you have found a fault, remote commands are where you act on it.

<CardGroup cols={2}>
  <Card title="Remote commands" icon="terminal" href="/capabilities/operation-monitoring/remote-commands">
    Resetting, rebooting, unlocking, and the rest of what you can send to a charge box.
  </Card>

  <Card title="Live status tracking" icon="activity" href="/capabilities/operation-monitoring/live-status-tracking">
    The live view across every connector, faulted or not.
  </Card>

  <Card title="Charge boxes" icon="plug" href="/components/charging/charge-boxes">
    What a charge box is, and how it relates to the EVSEs it holds.
  </Card>

  <Card title="Team access" icon="lock" href="/capabilities/account/user-management">
    Which roles in your organisation can reach the Operations area.
  </Card>
</CardGroup>
