When an SLA credit regime is triggered: what to do first
An SLA credit regime is triggered the moment the measured service level crosses the contractual threshold, not when someone notices the outage or the helpdesk ticket is closed. The first task is not to calculate the credit. It is to freeze the monitoring data and check which notice clock started running, because that clock is usually shorter than the credit calculation itself.
Foundation
The credit mechanism itself lives in the contract, not in EU law. No EU regulation sets service-level thresholds, credit formulas, or notice periods for a technology contract — that part is negotiated and governed by the applicable national contract law chosen by the parties.
One exception matters in practice. If the trigger event is a security incident rather than routine underperformance — an outage caused by an attack, a configuration failure exploited by a third party, or a data-handling breach — a separate and independent clock can start under Directive (EU) 2022/2555 (NIS2) for entities that fall within its scope. That notification duty runs regardless of what the SLA says, and it does not wait for the credit claim to be filed.
Practical consequence
Two deadlines can be live at the same time, and they are not the same deadline. The contractual notice window for claiming a credit is set by the SLA text — often shorter than clients expect, and frequently tied to the date the breach was measurable, not the date it was noticed. The statutory notification window under NIS2, where it applies, runs on its own schedule and is not extended by an ongoing commercial dispute about the credit.
Missing the contractual notice window usually forfeits the credit entirely, even where the underperformance is not disputed. Missing a statutory notification window is a separate exposure that a credit negotiation does not cure. Treat them as two files from the first hour, not one.
What to do first
The sequence below assumes an outage or degradation has already been detected. Each step names who normally carries it, because delay usually comes from nobody owning the next action rather than from the substance being unclear.
| Step | Action | Who does it | Deadline pressure |
|---|---|---|---|
| 1 | Export and store the monitoring data and service logs before automated retention rules purge them | Operations or IT lead | Same day |
| 2 | Locate the SLA clause and confirm the exact notice deadline for a credit claim | Contract owner | Before the contractual window closes |
| 3 | Assess whether the trigger event is, or may be, a security incident | IT security | Within hours |
| 4 | If step 3 is yes, check whether the entity falls within NIS2 scope and start the notification assessment | Compliance or legal | On the statutory clock, in parallel |
| 5 | Send written notice under the contract, referencing the measured breach and the applicable clause | Contract manager | Before the contractual window closes |
| 6 | Keep the evidence file separate from the credit calculation itself | Legal | Ongoing |
The order matters more than the speed of any single step. A credit claim sent without the underlying log export attached is routinely disputed on evidentiary grounds alone, before the substance of the breach is even discussed.
Who decides
Most technology contracts name the body that verifies whether a service level was actually breached — a service management committee, a designated technical representative, or an independent auditor under an escalation clause. That body works from the monitoring data, not from the SLA wording; a well-drafted claim gives it the extract, the measurement method, and the threshold side by side.
Where the customer and the provider disagree on whether the threshold was crossed, the dispute moves to the forum named in the contract's governing law and jurisdiction clause — arbitration or the courts, depending on what was signed. That forum decides on the evidence submitted at the time, which is precisely why step 1 above is not optional.
If your situation differs
If the affected service is delivered through a subcontractor, check the flow-down clause before invoking the credit against the prime contractor. Credits do not automatically pass through a supply chain; the prime's own SLA with its subcontractor may set a different threshold and a different notice period entirely.
If the outage affected content that references a third-party work later removed from the platform, the evidentiary steps differ from a pure uptime claim — see When the referenced work is removed and the evidence for what to preserve in that scenario.
If the credit regime is disputed on the ground that the underlying software was never delivered in an escrow-compliant state, that is a different trigger with its own sequence, not a variant of the credit claim.
What this page does not cover
This page does not calculate a credit amount, does not draft the notice letter, and does not tell you whether your specific SLA threshold was in fact crossed — that depends on the wording of your contract and the raw monitoring data, both of which sit outside a general situation page. It also does not cover how long the underlying logs and correspondence should be kept once the dispute closes; that question is answered separately in Retention: the report, the extracts and our copy explained.
Sources and limits
The credit clause, the notice period, and the escalation forum come from your own contract, which this page cannot see. Where the trigger event also involves a counterparty whose standing or filings need checking, a factual extract narrows that question before any negotiation starts — see Counterparty in Latvia and its limits and the deadline for what such a check can and cannot establish.
Where the dispute turns on whether a particular document was filed, amended, or registered at a given date, a document-level extract answers that narrower question directly — see Document in Latvia and its limits in practice for the scope of that check.
Sources checked for this page: Directive (EU) 2022/2555 (NIS2), current text. This page does not cite national contract law, since the credit mechanism itself is set by the individual agreement rather than by a uniform EU or national statute.
Related situations
Escrow triggers follow a related but distinct sequence, with their own release conditions and evidence chain — see When source code escrow is demanded step by step.
FAQ
What is the first step when an SLA credit regime is triggered?
Export and preserve the monitoring data and service logs before any automated retention rule deletes them. Everything that follows — the notice, the credit calculation, any dispute — depends on that extract existing in a form the other side can check.
Which deadline is already running?
At least one: the contractual notice window for the credit claim, set out in the SLA itself. If the trigger event involves a security incident, a separate statutory notification clock under NIS2 may be running at the same time, independently of the contract.
Who decides, and on what evidence?
The body named in the contract for service-level verification — a committee, a technical representative, or an auditor — decides based on the monitoring data and the measurement method, not on the SLA wording alone. A disputed claim moves to the forum named in the governing law clause.