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

# Incidents Overview

Nayax Energy Core tracks the health of your charging fleet as **incidents**. An incident represents a period of degraded or lost service — a charger reporting a hardware fault, a station that has dropped offline, or a pattern of failing sessions — grouped into a single record that your team can triage, work, and resolve.

Incident management gives network operators one place to see what is wrong across the fleet, who is working it, and how long it has been open, without piecing the story together from raw station logs.

> Incident management is available to networks that have it enabled. If you do not see incidents in your console, contact Nayax Energy Core support to enable it for your network.

## Where incidents come from

Most incidents are opened automatically. When the platform detects a condition worth attention, it opens an incident and adds the affected station to it:

| Condition         | What it means                                                                                  |
| ----------------- | ---------------------------------------------------------------------------------------------- |
| Hardware fault    | A charger reported an error code indicating a hardware or firmware problem.                    |
| Connectivity loss | A station stopped communicating with the platform, based on your network's detection settings. |
| Session failures  | A station shows a pattern of sessions that fail to start or fail mid-charge.                   |

Support Operators can also **open an incident by hand** for something reported another way — a phoned-in problem, for example. See [API usage](/guides/incidents/api-usage) for the create endpoint.

Which automated conditions are active, and how sensitive they are, is governed by your network's [detection rules](/guides/incidents/settings/detection-rules).

## The shape of an incident

Every incident carries:

* A **status** that moves through a lifecycle from new to resolved — see [Statuses and lifecycle](/guides/incidents/statuses-and-lifecycle).
* A **roster of affected stations**. One incident can cover many stations; each station on the roster has its own state within the incident — see [Affected stations](/guides/incidents/affected-stations).
* A **resolution deadline** derived from your network's [SLA rules](/guides/incidents/settings/sla-rules).
* A **timeline** of everything that has happened — status changes, comments, reassignments, and station activity — see [Comments and history](/guides/incidents/comments-and-history).

Related incidents can be **merged**, **split**, or **linked** as your understanding of an event changes — see [Merging, splitting, and linking](/guides/incidents/merging-splitting-and-linking).

## Reading incidents through the API

Everything the console shows is available through the Incident Management API, so you can pull your fleet's incidents into your own tooling. Start with [API usage](/guides/incidents/api-usage), or browse the full reference under [Incident Management API](/api/incident-management/incidents/bulk-change-incident-status).

## Next steps

* [Statuses and lifecycle](/guides/incidents/statuses-and-lifecycle) — the status vocabulary and how incidents close, including automatic resolution.
* [Affected stations](/guides/incidents/affected-stations) — the roster, and why an incident's status and a station's live connectivity can disagree.
* [Merging, splitting, and linking](/guides/incidents/merging-splitting-and-linking) — consolidating and separating incidents.
* [Comments and history](/guides/incidents/comments-and-history) — the activity feed and comment visibility.
* [API usage](/guides/incidents/api-usage) — listing, filtering, and paginating incidents.