A site that reports poor availability usually has a maintenance story attached to it: the service team is slow, the spare part took three weeks, the technician replaced the wrong board. Those things happen. But when a network looks at a year of downtime records across many sites, the pattern that emerges is less flattering to the equipment decision — most of the hours lost were locked in before the first session was ever started.
This article is about attributing availability, not improving it through effort. It covers how the number is defined, where lost hours actually originate, which decisions set the ceiling, and how to keep a downtime record that makes the attribution possible at all.
Three Definitions, One Number in the Contract
"Availability" is used as if it were a single quantity. It is at least three, and they diverge sharply on the same site:
The measurement source matters as much as the formula. A back-office platform counts a unit as available when it responds to the platform, which is not the same as a driver being able to charge. Charger logs, platform records and manual inspection can produce three different availability figures for the same month, and any of them can be defended.
Which is why the definition belongs in the service agreement, written out, with the source of data named. Without that, every discussion about performance starts with an argument about arithmetic, and the argument tends to be settled by whoever holds the larger file of screenshots.
Where Lost Hours Originate, and When the Decision Was Made
The useful question about a downtime cause is not which part failed. It is when the outcome became likely. Sorting causes by that date separates problems that maintenance can fix from problems that only a different specification can fix.
Only one row in that table — the spares strategy, partly — is genuinely about maintenance speed. Everything above it was settled by a specification, a drawing or a clause. A service team can shorten the outage after a module fails. It cannot add a module that was not ordered, or raise a thermal margin that was designed to a lower ambient.
This is the practical meaning of the claim that selection decides most of the availability: not that maintenance is unimportant, but that it operates inside a ceiling someone else set.
Four Selection Decisions That Set the Ceiling
Redundancy architecture. A cabinet with several power modules and a sharing controller degrades in steps; a cabinet with a single module fails in one. The difference does not show up in a datasheet comparison, because both are quoted at the same output. It shows up in the fourth year, at the first module failure, as either a reduced session or no session. The booster terminal architecture is one example of how the module count and the sharing logic change what a single fault costs.
Thermal margin. Every unit derates somewhere. The question is whether that point sits above the site's real conditions, including the hottest week, a dirty filter, and a cabinet in direct sun against a wall. A specification written to a comfortable ambient number is a specification for a different site.
Connector duty and cable management. The connector is the most-touched part of the system and the least discussed in procurement. Its cycle rating, the strain relief, the weight of the cable and the height of the holster all determine how often a driver reports a failed latch. Bay geometry belongs here too: a cable that drags on the ground fails sooner than one that hangs clear. This is one reason a 60 kW DC station specified for a covered bay and the same model specified for an open forecourt are not the same purchase.
Serviceability. Mean time to repair is a design property before it is a service promise. Front access, module weight, connector accessibility, and whether a fault can be cleared from the platform all decide whether a repair takes one visit or three. A unit that needs two technicians and a lift for a routine swap has a longer outage than its failure rate suggests.
Three Contract Terms That Set the Floor
If selection sets the ceiling, the agreement sets the floor — the point below which performance becomes someone else's problem. Three terms do most of that work.
The definition and its data source. Formula, period, unit of account (per connector or per site), and whether planned work is excluded. A per-site figure can look healthy while one connector is dead; a per-connector figure can look poor while the site serves every driver who arrives.
Response time against restoration time. These are two clocks and only one of them affects availability. A response commitment measures how quickly someone acknowledges the fault; a restoration commitment measures when the unit charges again. Contracts often carry the first and leave the second to discussion.
Spares: level, location, holder. A commitment to supply parts is not a commitment to have them nearby. The useful wording names the stocked items — power module, connector assembly, controller — and where they sit. In a fleet depot where every bay is used overnight, the difference between a part in the region and a part in another country is measured in days of lost service, not hours. The fleet hub charging layout makes that exposure visible, because the schedule has no spare hours in it.
A fourth term is worth adding where the equipment is software-connected: the support end date for the firmware branch, and who is responsible for updates. A unit that is mechanically sound and no longer updated becomes unavailable in a different way — it stays online, and stops being able to complete sessions as the platform around it moves.
The Downtime Record That Makes Attribution Possible
None of the analysis above can be done retrospectively from a monthly availability figure. It needs a record per event, and five fields carry almost all of the value:
- Unit and connector identifier, so a site-level average cannot mask a single dead outlet
- Start and end timestamps, from the first failed session — not from when the ticket was opened. The gap between the two is often the largest single component of the outage
- Fault code as recorded by the unit, alongside the technician's description. The two disagree often enough that keeping only one loses the diagnosis
- Subsystem — power module, connector, controller, communications, payment, grid. This field is what turns a pile of tickets into the table earlier in this article
- Resolution action, including whether a part was replaced, a setting changed, or nothing was found. The last category is the most informative and the most often left out
With those five fields, three questions become answerable: which subsystem costs the most hours, whether the same fault repeats on the same unit, and how much of the total is diagnosis delay rather than repair time. Without them, the conversation stays at the level of impressions, and impressions tend to blame the last person who touched the machine.
A Diagnostic Order That Avoids Replacing the Wrong Part
When a unit is reported as unavailable, the report has already collapsed four different failures into one word. Checking in this order costs less than starting at the hardware:
1 Connected? Does the unit appear on the platform, and when did it last report? A communications loss looks identical to a dead charger at the driver's end.
2 Authorising? Can a session start at all? A refused card, an expired certificate or a payment outage produces a "broken charger" report with a healthy power stage.
3 Delivering? Compare requested power with delivered power. A unit at a fraction of its rating is available by the definition and unusable in practice.
4 Completing? Look at stop reasons. Sessions that end early point at the connector, the vehicle or a protection trip, not at the module.
The order is not arbitrary. It runs from the cheapest check to the most expensive, and from the most common cause to the least. Most misdiagnosis comes from starting at step three because that is the part with a fault code attached.
What "Scheduled" Is Allowed to Cover
Planned work is normally excluded from availability, which is reasonable — a site that is deliberately taken out of service for maintenance is not failing. The exclusion is also where reporting gets flexible.
A firmware update that takes a unit offline for a day is planned in the sense that someone scheduled it. A repair postponed twice and then done during a quiet hour is not. The distinguishing question is whether the work was necessary to keep the unit serviceable, and whether it was performed within a window the operator agreed to. When in doubt, the stricter treatment is to count the hours and note them separately — it keeps the headline figure honest without hiding the maintenance effort.
The same logic applies to events outside the equipment: a grid trip, a site power cut, a bay blocked by construction. These belong in the record with their own tag rather than in a general exclusion, because a pattern of grid events is a design finding, not an excuse.
Availability Is an Architecture Property
The number a site reports at the end of its second year is largely the arithmetic of decisions taken in a meeting room: how many modules, what ambient the thermal design assumed, which connector and how it is stored, whether a spare sits in the region, whether the unit can be updated, and what the contract counts.
That is why availability tends to stay flat despite effort. Service teams can compress the tail of an outage; they cannot move the ceiling. Reading a year of downtime records by origin, rather than by symptom, is what shows the difference — and it is the only version of the analysis that produces a decision rather than an explanation.
For buyers still at the specification stage, the practical output is a short list of questions that belong in the technical evaluation: module count and failure behaviour, derating against the site's real ambient, connector cycle rating and cable management, mean time to repair with one technician, spare stocking point, firmware support window, and the exact availability formula proposed. Six of those seven are answered in writing before the order, or they are answered by the first outage. The technical documentation set is the usual place to check whether the numbers behind them exist at all.
Score uptime before you buy it
Seven questions decide most of the ceiling: module behaviour, derating margin, connector duty, repair time, spare location, support window, and the formula itself. Send the site conditions and the current definition, and the comparison has a basis.
Send your site conditions