When an SLA credit regime is triggered: what it costs to be wrong
A service-level credit regime is a contractual remedy, not a statutory right. Getting the trigger wrong misclassifies an outage, starts the wrong clock, and can forfeit the credit altogether. The immediate cost is not the credit itself but the evidence you fail to preserve while the dispute is still winnable.
The basis: contract first, regulation second
No EU regulation grants a right to a service credit. The right exists only where the agreement's own service schedule defines the metric, the measurement window, and the credit formula. Read that schedule before reading anything else.
A typical schedule sets four things separately: the metric that counts as a breach, the window over which it is measured, the list of exclusions, and the cap on total credits per period. Misreading any one of the four changes the outcome, even where the other three are read correctly.
Regulation enters through a side door. Where the affected service also falls within the scope of Directive (EU) 2022/2555 (NIS2), the provider's duty to classify and report significant incidents generates timestamped records. Those records later become the evidence both sides argue over in the credit dispute.
The schedule and the regulatory record rarely align by accident. A provider's internal incident classification, done for NIS2 purposes, is not the same test as the SLA's own definition of a qualifying event. Treat them as two separate questions, answered from two separate documents.
What changes when the trigger is misread
Three things go wrong in sequence once the wrong trigger is applied. First, the measurement window starts on the wrong date, so the credit is calculated against the wrong period. Second, an exclusion clause — planned maintenance, force majeure, customer-caused fault — gets applied or ignored incorrectly. Third, the periodic or annual cap on credits is reached earlier or later than it should be, changing what remains available later in the term.
| Trigger type | What starts running | Common dispute point |
|---|---|---|
| Availability breach | The measurement window for that period | Whether an exclusion applies |
| Incident overlapping a security event | Both the SLA clock and the NIS2 reporting clock | Which record controls the classification |
| Repeated underperformance across periods | The cumulative cap calculation | Whether credits already paid are deducted first |
The cumulative effect matters more than any single miscalculation. A cap reached one period early removes the remedy for a genuine later breach. A cap reached one period late understates what has already been consumed, and overstates what is still available to negotiate against.
What to do, in order
Speed matters more than completeness at this stage. A partial record taken immediately outweighs a full record reconstructed later.
- Operations lead: pull the raw monitoring logs before any dashboard summary overwrites them.
- Contract owner: locate the service schedule clause defining the trigger, the window, and the exclusions.
- Contract owner: check whether the notice period for claiming the credit has already started to run.
- Finance or legal: confirm whether the periodic or annual credit cap has already been reached this period.
- Legal: draft the notice or the response strictly against the schedule's own wording, not against a general sense of fairness.
- Escalate internally before the contractual response deadline lapses, not after it.
Who decides, and on what evidence
No regulator adjudicates an SLA credit dispute. The first decision-maker is whoever the contract names — typically a joint contract management committee, or a named account owner on each side.
If that committee cannot agree, the escalation clause usually points to a senior executive meeting next, and then to the dispute resolution mechanism chosen in the governing law clause: arbitration, or the courts named there. Some schedules insert an independent expert determination step before either.
Evidence is the monitoring data, the incident log, and any NIS2-driven incident classification record, read against the schedule's own definitions — not against a general notion of what "should" count as downtime. The party holding the monitoring systems usually carries the practical burden of producing that evidence first.
Three forks
If the outage traces to a subcontractor rather than the direct provider, check whether the schedule's credit obligation follows the prime contract or stops at the subcontracting boundary. Many schedules are silent on this point, which favours whichever side raises it first.
If the affected service also distributes royalties encoded on a blockchain, a missed distribution can trigger the SLA credit and a separate on-chain dispute at once. See When royalties encoded on-chain are ignored step by step for how that second track runs.
If the periodic cap has already been exhausted this period, a further breach may still be recorded but generates no further credit. Recording it anyway protects a later claim for termination rights, which usually run on cumulative breach counts rather than on cumulative credit value.
What this page does not resolve
This page does not calculate the credit owed on a specific outage, and it does not tell you which court or arbitral seat will hear a dispute that escalates. Those depend on facts this page cannot hold.
Where the counterparty's standing or structure is itself in doubt, that is a separate factual question, established through its own process. See Counterparty in Cyprus and its limits explained for what can and cannot be established about a Cyprus entity.
Where the dispute turns on whether a document was signed, dated, or amended as claimed, that too is established separately from the credit calculation itself. See Document in Cyprus step by step for that process.
Related reading
The same forfeiture logic — a right that exists only inside a defined window — governs source code escrow disputes as well. See When source code escrow is demanded and its limits.
If your credit dispute is already live, the first working step is preserving the logs named above, today, not after the escalation meeting.
Verified
Reviewed on 4 November 2025. Primary source: Directive (EU) 2022/2555 (NIS2), consolidated text as published on the EU digital strategy portal. For the firm's scope and remit, see About the firm and its scope.
FAQ
What is the first step when an SLA credit regime is triggered?
Preserve the raw monitoring logs before any summary dashboard overwrites them, then locate the schedule's own trigger definition and read it before forming a view.
Which deadline is already running?
Usually the notice period for claiming the credit, and, where NIS2 applies, the incident reporting clock. The two run in parallel but are not the same deadline and do not share a test.
Who decides, and on what evidence?
The contract's own committee or named owner decides first, on the monitoring data and incident log read against the schedule, not on any regulator's ruling.