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

# Statuses and lifecycle

Every incident has a **status** that describes where it is in its life. An incident opens as `NEW` and moves toward `RESOLVED` as your team investigates and fixes the underlying problem.

## The statuses

| Status           | Meaning                                                                                                                                                                                                                   |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `NEW`            | Just opened; no one has started work yet.                                                                                                                                                                                 |
| `INVESTIGATING`  | A Support Operator is diagnosing the problem.                                                                                                                                                                             |
| `MITIGATING`     | A fix or workaround is being applied.                                                                                                                                                                                     |
| `WAITING_ON_OEM` | Blocked on the hardware vendor; a person owns closure.                                                                                                                                                                    |
| `POST_MORTEM`    | The problem is handled; the incident is being written up before closing.                                                                                                                                                  |
| `RESOLVED`       | Closed. This is terminal.                                                                                                                                                                                                 |
| `MERGED`         | Folded into another incident by a merge. This is terminal, and is set only by a merge — you never move an incident here yourself. See [Merging, splitting, and linking](/guides/incidents/merging-splitting-and-linking). |

## Allowed transitions

An incident can only move between statuses along defined paths. From any working status you can resolve; `WAITING_ON_OEM` must return to active work before it can be resolved.

| From             | Can move to                                                  |
| ---------------- | ------------------------------------------------------------ |
| `NEW`            | `INVESTIGATING`, `RESOLVED`                                  |
| `INVESTIGATING`  | `MITIGATING`, `WAITING_ON_OEM`, `POST_MORTEM`, `RESOLVED`    |
| `MITIGATING`     | `INVESTIGATING`, `WAITING_ON_OEM`, `POST_MORTEM`, `RESOLVED` |
| `WAITING_ON_OEM` | `INVESTIGATING`, `MITIGATING`                                |
| `POST_MORTEM`    | `RESOLVED`                                                   |
| `RESOLVED`       | — (terminal)                                                 |
| `MERGED`         | — (terminal)                                                 |

Resolving an incident requires **resolution notes**, unless they were already recorded on the incident earlier. A status change can carry an optional reason, which is recorded on the incident's history.

You change an incident's status in the console, or through the API with `PATCH /incidents/{id}` — see [API usage](/guides/incidents/api-usage). Several incidents can be moved at once with a bulk status change; incidents that cannot take the requested transition are skipped and reported rather than failing the whole request.

## Automatic resolution

Some incidents close themselves. When the condition that opened an incident clears — a faulted charger reports itself healthy again, or an offline station comes back online — the platform records the recovery. Once **every** affected station on the incident has recovered, the incident resolves automatically:

* Its status becomes `RESOLVED`.
* It is marked as **auto-resolved**, so you can tell incidents the platform closed from those a Support Operator closed (the list can be filtered on this).

Automatic resolution only closes incidents that are still in an early working state — `NEW`, `INVESTIGATING`, or `MITIGATING`. Once a person has moved an incident to `WAITING_ON_OEM` or `POST_MORTEM`, closure is theirs to make: the platform will still record that stations recovered, but it leaves the incident open for a Support Operator to close deliberately.

Two kinds of recovery drive automatic resolution: a **fault clearing** on a charger, and **connectivity being restored** to a station. Your network can turn either off — see [Auto-resolution](/guides/incidents/settings/auto-resolution). When a recovery type is turned off, recoveries are still recorded on the roster, but the incident stays open for a Support Operator to close.

> Automatic resolution depends on the affected stations' recovery, not on their live connectivity alone. A station reading online is not the same as its incident being resolved — see [Affected stations](/guides/incidents/affected-stations).