Skip to main content
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.
  • 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. 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.
  • 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: 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:
It is paginated and can be filtered to just AFFECTED or just RECOVERED rows. See 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.