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: Support Operators can also open an incident by hand for something reported another way — a phoned-in problem, for example. See API usage for the create endpoint. Which automated conditions are active, and how sensitive they are, is governed by your network’s 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.
• 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.
• A resolution deadline derived from your network’s SLA rules.
• A timeline of everything that has happened — status changes, comments, reassignments, and station activity — see Comments and history.

Related incidents can be merged, split, or linked as your understanding of an event changes — see 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, or browse the full reference under Incident Management API.

​

Next steps

• Statuses and lifecycle — the status vocabulary and how incidents close, including automatic resolution.
• Affected stations — the roster, and why an incident’s status and a station’s live connectivity can disagree.
• Merging, splitting, and linking — consolidating and separating incidents.
• Comments and history — the activity feed and comment visibility.
• API usage — listing, filtering, and paginating incidents.