A charge point on your network reported a hardware fault several hours ago. Your operations team hasn’t seen it yet. The first person to flag it is a driver who pulled up to charge and found the unit unresponsive.
That scenario plays out regularly on charging networks that have grown faster than the tools used to manage them. As networks scale across locations and markets, keeping ahead of what’s happening across the infrastructure takes more than basic alerts and manual checks. It takes a system that connects detection, attempted recovery, notification, and resolution tracking, so that problems are caught, worked, and confirmed closed without the team having to coordinate across separate tools and inboxes.
The Issues Detection functionality, now live across the AMPECO platform, is that system. It gives CPOs a single place to define what their network watches for, run automatic recovery attempts for hardware faults, route alerts to the right contacts, and track every issue from detection to confirmed resolution. This article covers what it gives CPOs, how it works, and what changes for operations teams and the drivers they serve once it is configured.
What Issues Detection gives CPOs: a closed loop from fault to resolution
CPOs can now define exactly what their network should be watched for, and the platform monitors those conditions continuously. When a defined condition is met, an issue is created, tracked, and either resolved automatically or escalated to the right person for investigation.
Detection rules specify which conditions trigger an issue: hardware faults, charge points going offline, billing suspensions, excessive disconnects, compliance reporting failures, roaming CDR delivery failures, and certificate expiry. The operator configures the rules; the platform monitors for them around the clock.
Let the system attempt to fix certain faults before anyone is paged. For hardware faults specifically, Issues Detection runs auto-recovery before escalating to the team. It requests a status update from the charge point, evaluates the response, sends a soft reboot if the fault persists, and only involves the team if recovery fails. Faults that clear on their own are logged as resolved with no human action required.
Every issue that does reach the team moves through a defined lifecycle: auto-recovery in progress, new, investigating, in progress, and resolved. Status changes, assignees, and resolution details are all recorded in the same system, from the moment the issue is created to the moment it is confirmed closed.
Auto-close conditions take this further. When the underlying problem resolves on its own, the system closes the issue automatically. A charge point that comes back online closes its offline issue. A billing session that completes closes its suspended billing issue. The list stays accurate without manual housekeeping.
Notification rules give operators control over who gets alerted, and when. Rather than broadcasting every alert to everyone, operators configure filters by category, severity, and priority, select immediate or digest delivery, and specify which contacts receive which notifications. The right people get what they need to act; everyone else is not interrupted.
How it works: detection rules, auto-recovery, and notifications
Detection rules
Six built-in detection rule types cover the main categories of operational events CPOs need to monitor:
| Detection rule | What it monitors |
|---|---|
| Charge point hardware fault | Hardware status changes to Faulted or Unavailable |
| Charge points offline | Network status changes to Long-term unavailable |
| Session billing suspended | Billing status changes to Suspended |
| Excessive charge point disconnects | Number of disconnects exceeds a configurable threshold within a defined timeframe |
| Deutschlandnetz reporting failure | A reporting submission fails after a configurable number of attempts |
| Roaming CDR push failure | A CDR delivery fails after all retry attempts |
The Deutschlandnetz rule is a Germany-specific compliance integration. The remaining five rule types apply to all networks regardless of market.
Each rule type comes with predefined trigger conditions, ignore conditions, and auto-close conditions. Ignore conditions prevent issues from being created in situations that should not trigger them; a charge point already in Demo status, for example, does not trigger an issue. The operator enables the rules; the system handles the logic.
Priority adjustments allow operators to refine how urgently each issue is treated. A hardware fault at a high-traffic partner site can automatically receive higher priority than the same fault at a low-volume location, based on charge point tags, location, location tags, or partner assignment. The system evaluates these adjustments when the issue is created, so the operations team starts with correctly prioritized work from the start.
Auto-recovery
Auto-recovery is available for the hardware fault rule only. When a hardware fault is detected, the system works through a defined sequence before alerting anyone:
- Request a status update from the charge point
- Wait for the response and evaluate it
- If the fault has cleared, resolve the issue automatically
- If not, send a soft reboot command to the charge point
- Wait for the charge point to restart and report its status
- If the fault is gone, resolve the issue automatically
- If the fault persists, set the issue to New status and trigger notifications
Every step is logged. Operators can view a timestamped record of what the system attempted under Auto-resolution logs on the issue detail page.
Notification rules
Notification rules define who gets notified when an issue reaches New status, whether that follows a failed auto-recovery attempt or direct detection. Each rule includes filters to target specific categories, severities, priorities, or detection rules; rules are independent, so an issue can match multiple rules and each sends its own notification to its own recipients.
Two delivery modes are available. Immediate sends one email per matching issue, with the title, category, severity, priority, and a direct link to view it in the back office. Daily digest collects all matching new issues from the prior 24 hours into a single summary email, grouped by priority and category. Teams that prefer a morning briefing on overnight events configure their rules accordingly.
Recipient types include operator and partner technical and administrative contacts, suboperator contacts, and specific email addresses. When multiple types are selected, the system deduplicates — no one receives the same notification twice.
Operators building detection rules for hardware faults and connectivity issues can also layer in AI-assisted diagnostics. When creating these rules, operators can enable automatic CoOperator (AMPECO’s AI assistant) insight generation. When active, CoOperator produces an AI diagnostic for every new issue that rule creates, attached to the issue before anyone opens it. That means the person opening the issue sees a probable cause and suggested next step immediately, without needing to start diagnosis from scratch.
What changes for your team — and for the drivers on your network
For the operations team
Problems that were previously unknown until a driver complained or a support ticket arrived are now detected the moment defined conditions are met. A hardware fault that triggers overnight is captured and worked (or auto-recovered) before the next shift, before any driver encounters it.
Some of those hardware faults resolve without anyone being paged. The auto-recovery sequence handles diagnosis and reboot attempts without human involvement. If recovery succeeds, the issue is logged as resolved with a timestamped record of what the system did. The team only sees the issues the platform could not resolve on its own.
Notification rules change the alert dynamic from broadcast to precision. A billing suspension reaches the billing contact. A critical hardware fault at a key partner location reaches the network operations lead. The scope of each notification is defined rather than assumed, which means the right people act on what they receive rather than filtering through alerts that do not apply to them.
The full lifecycle of every issue is visible in one place. From the moment an issue is created to the moment it is confirmed resolved, the status history, assignee, and resolution details are all there. The question of what happened and who handled it always has a clear answer, whether the issue was resolved automatically or worked by the team.
Over time, the issues list becomes a source of pattern data. Filtering by category, severity, priority, and detection rule surfaces patterns that individual alerts never reveal: a specific charge point model generating recurring hardware faults, a location with repeated billing suspensions, a partner network with an elevated disconnect rate. That kind of visibility informs decisions about infrastructure investment, maintenance scheduling, and partner performance reviews.
For EV drivers
Problems that would previously compound into extended outages are detected and worked before drivers encounter them. When hardware faults trigger auto-recovery, some resolve before any driver arrives at the charge point. When issues do reach the team, the right person starts investigating immediately with full context on record. That shows up as fewer failed charge attempts and faster recovery when something does go wrong.
From fault detection to confirmed resolution — all in one system
Issues Detection gives CPOs a single system that watches for what they define as important, attempts to fix hardware faults before alerting anyone, routes notifications to the right people, and tracks every issue through to documented resolution.
Book a demo with AMPECO
Issues Detection is live across the AMPECO platform. To see how detection rules, auto-recovery, and notification workflows could apply to your network, book a demo with our team.
