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

# Affected stations

An incident can cover one station or many. The set of stations on an incident is its **roster**. A single-station charger fault has a roster of one; a site that loses its uplink can have a roster of dozens.

Each station on the roster carries its own state within the incident, its own detection time, and — joined in from the station record — its **live** details, including whether it is reachable right now.

## Roster row status vs. live connectivity

This is the most important distinction on this page, because the two answer different questions and can legitimately disagree.

| Field                    | Question it answers                             | Values                  |
| ------------------------ | ----------------------------------------------- | ----------------------- |
| Roster **status**        | Is this station still part of the open problem? | `AFFECTED`, `RECOVERED` |
| Station **connectivity** | Is this station reachable right now?            | `ONLINE`, `OFFLINE`     |

* A station is `AFFECTED` while it is part of the incident's condition, and `RECOVERED` once that condition has cleared for it.
* A station's `connectivity` is its live reachability, independent of any incident.

These are not the same fact, and "not offline" does **not** mean "recovered". A few normal situations show them disagreeing:

* **A station comes back before the incident is resolved.** Connectivity flips to `ONLINE` the moment the station reconnects. The incident does not close until every affected station has recovered and a Support Operator (or automatic resolution) closes it — so you will routinely see an open incident whose stations read `ONLINE`.
* **A brief blip never opens an incident.** A station can read `OFFLINE` for a short moment without any incident being opened for it, based on your network's [detection settings](/guides/incidents/settings/detection-rules). In that window there is no roster row at all.

When you are deciding whether an incident is truly over, read the roster **status**, not the live connectivity. The roster status is the incident's own view of each station.

## What a roster row shows

Each row on the roster carries:

* The **roster status** (`AFFECTED` / `RECOVERED`) and the time the station recovered, if it has.
* This station's own **detection time** — when the condition was first seen for it, which can differ from the incident's overall detection time when stations were folded in by a merge.
* Where the row **came from**: a station folded in by a merge carries `mergedFromIncidentId`, the incident it originally belonged to. Only these rows can be split back out — see [Merging, splitting, and linking](/guides/incidents/merging-splitting-and-linking).
* The **live station**: id, name, charge point id, serial number, firmware version, and current `connectivity`.

## Detection context

The roster tells you which stations are affected and when each was detected. For what was observed when the incident opened, read the incident's `metadata` object. Its keys depend on the condition that opened the incident, and may grow over time:

| Condition         | Keys                                                                                                                                                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Connectivity loss | `offlineSince` — when the station's disconnect was recorded, the start of the offline episode (ISO-8601). `thresholdMinutes` — how long it had to stay offline before the incident opened. |
| Hardware fault    | `status` and `rawStatus` — the status report that opened the incident. `stationLevel` — `true` when the fault was reported against the charge point itself rather than one connector.      |

A manually created incident has an empty `metadata`. Because connectivity loss is only declared once the threshold has elapsed, `offlineSince` is earlier than the incident's detection time — use it when you need the moment a station actually went dark.

## Reading the roster

The incident record itself carries only a count — `affectedStationCount` — not the full roster, so that a large multi-station incident does not force a huge payload onto every read. Fetch the roster from its own endpoint:

```
GET /incident-management/v1/incidents/{id}/affected-stations
```

It is paginated and can be filtered to just `AFFECTED` or just `RECOVERED` rows. See [API usage](/guides/incidents/api-usage) for pagination and filtering.

Stations join an incident's roster when the condition is detected for them, or when another incident is merged in. When you split stations back out, their rows leave this roster — see [Merging, splitting, and linking](/guides/incidents/merging-splitting-and-linking).