What a written charging SLA should include (MTTR beats uptime)
The clauses a fleet procurement team should require in a charging SLA, why mean time to repair beats uptime, and how to make credits automatic.
By Antony OkuribidoPublished Updated 7 min read
A charging SLA is the document that decides whether an electrified fleet runs. Most SLAs offered to fleets are written for the provider: a single uptime percentage, measured generously, with credits you have to claim. This guide lists what a fleet procurement team should require instead, clause by clause, and explains why mean time to repair is the number to fight for.
What the market now expects
Procurement practice has moved. In 2026, guidance for fleet charging RFPs calls for monthly per-charger uptime of 97 to 99% with financial penalties, treats mean time to repair as the SLA that matters, and requires OCPP and ISO 15118 support, according to Charged Fleet's feature on the charging reliability layer, Evaisun's EV charger RFP checklist and Aufait Technologies' EV charging RFP guide. The clauses below turn that expectation into contract language.
Clause 1: uptime, measured per dispenser, per month
An uptime number is only meaningful with three qualifiers.
Per dispenser, not per site. A site with 20 dispensers and one dead port reports 95% site uptime while the same port is dead for a month. Per-dispenser measurement makes every port count.
Per calendar month. Annual averages let a bad month hide in a good year. The fleet lives month to month.
Against a target of 97% or higher, the floor in Charged Fleet's 2026 reliability guidance. Below that, the site is unreliable enough that fleet operations will work around it, which defeats the purpose.
MegaWatts publishes a per-dispenser monthly target on its SLA page.
Clause 2: MTTR per fault class
Uptime tells you how much time was lost. Mean time to repair tells you how it was lost, and that is what the fleet feels. A dispenser down 1% of a month is down about seven hours. If those seven hours are 8 p.m. to 3 a.m. on a Tuesday, the vans that came home at 8 did not charge, and the morning routes did not run.
Require MTTR reported monthly, split by fault class: remote-resolved faults, on-site repairs and hardware replacements. Set targets for each. A remote reset should take minutes. An on-site repair should be measured in hours. A replacement should have a hard target in days with spares staged regionally, because a 72-hour replacement promise is only credible if the hardware exists within driving distance.
Clause 3: response time with a named human
Response is not the same as repair, and it should be measured separately. Require acknowledgement by a named engineer within a fixed window, 24 hours at most and far less for depots that operate at night, with remote diagnosis beginning within the hour. A ticket auto-reply is not a response.
Write the escalation path into the SLA with roles: the fleet power engineer first, an operations lead if not acknowledged or resolved within a set time, and an executive for unresolved faults or any safety event. Names go in the agreement; roles go in the SLA.
Clause 4: narrow, listed exclusions
Every SLA excludes something. The question is whether the exclusions are listed or open-ended. Acceptable exclusions are scheduled maintenance agreed in advance with a notice period, customer-caused damage, upstream utility or fuel supply failures outside the provider's scope, and force majeure. Unacceptable exclusions are vague: "third-party software," "network conditions," "vehicle-side faults" without a definition. Everything not listed should count against uptime.
Clause 5: automatic credits
A credit you have to claim is a discount you will not receive. Require a credit schedule tied to per-dispenser monthly uptime bands, applied automatically on the next invoice, with a termination right below a floor. A schedule that starts at 10% of the dispenser's monthly fee for a modest miss and rises to 50% plus termination for a severe one aligns the provider's revenue with your uptime.
Clause 6: protocols and data
Require OCPP 2.0.1 for charger control and telemetry into your charging management or fleet system, ISO 15118 for Plug & Charge and smart-charging communication, and an exportable session record: start, end, kWh, peak kW, state of charge in and out, vehicle identifier. Without your own copy of the data you cannot audit the uptime the provider reports. Aufait's 2026 RFP guide lists these protocol requirements as standard.
Clause 7: safety, insurance and confidentiality
For battery-backed equipment, require the certification set in writing: battery safety, thermal runaway testing and charging system listings, with certificates on request. Require a certificate of insurance before equipment arrives and a statement of which party's policy covers vehicles. For pilots, require confidentiality by default; a provider should not be able to name your site without consent.
Clause 8: scaling and exit
An SLA for a fleet that is growing should say how capacity is added under the same terms, and an SLA for a bridge deployment should say what happens when the permanent utility service is energized. No penalty for exit after a minimum term is the right structure for a mobile deployment.
A checklist to paste into the RFP
- Uptime ≥ 97% per dispenser per calendar month
- MTTR reported monthly by fault class, with targets for remote, on-site and replacement
- Response by a named engineer within 24 hours or less; remote diagnosis within 1 hour
- Escalation path with three levels and time triggers
- Exclusions listed exhaustively; scheduled maintenance with 72-hour notice
- Credits automatic on invoice, banded, with a termination floor
- OCPP 2.0.1, ISO 15118, exportable session data
- Certifications, COI before delivery, NDA-by-default for pilots
- Capacity additions under the same terms; exit tied to utility energization
The MegaWatts SLA is published against this checklist so it can be compared line by line, with the items awaiting founder confirmation marked. Any provider that will not publish theirs is telling you something.
How to read a provider's SLA in ten minutes
Skip the uptime headline and go to four places.
The definitions section. How is "available" defined? A dispenser that powers on but cannot start a session should count as down. A dispenser derated to a fraction of its rated power should count as partially down. If the definition is "responds to a ping," the uptime number is meaningless.
The exclusions. Count them. List them. Anything open-ended, such as "conditions outside the provider's control," should be replaced with a closed list.
The credit mechanism. "Upon written request within 30 days" means you will not collect. "Applied to the next invoice" means you will.
The reporting. If the provider reports uptime and you cannot verify it from your own telemetry, you are taking their word. Require the raw session and fault data.
A note on penalties versus credits
Credits are the practical instrument: they are automatic, proportional and do not require litigation. Penalties beyond credits, such as termination rights and cover costs, belong at the severe end of the schedule. A provider that resists any termination floor is asking you to keep paying for a site that does not work.
Why publish it
An SLA that only exists inside a signed agreement cannot be compared. Publishing the SLA lets a procurement team compare providers before a single call and holds the provider to the same terms for every customer. MegaWatts publishes its SLA for that reason, with each unconfirmed number marked so nobody mistakes a placeholder for a promise.