An SLA breach is a measurable failure by a service provider to meet a performance target written into the Service Level Agreement, and it almost always triggers a specific remedy spelled out in that same contract. The breach is defined by numbers, not opinions: an uptime percentage missed, a response time exceeded, a repair window blown. What you can do about it depends on how severe the failure was, how well you documented it, and how the contract allocates risk between you and the provider.
What Counts as a Breach
A breach is tied to a quantitative metric, not a subjective complaint about service quality. The most common benchmark is availability, usually expressed as an uptime percentage. AWS guarantees 99.99% monthly uptime at the region level for its compute services, and Google Cloud sets similar thresholds that vary by deployment configuration and tier.1Amazon Web Services. Amazon Compute Service Level Agreement2Google Cloud. Compute Engine Service Level Agreement (SLA) If the service drops below the agreed percentage during a billing month, the threshold has been violated regardless of why.
Latency is another frequent metric. An agreement might require API responses to stay below a specific millisecond threshold for 95% of requests in a measurement window. Response time commitments for technical support are equally enforceable: if the SLA says a critical ticket must be acknowledged within 30 minutes and acknowledgment takes two hours, that’s a breach. Some agreements also track Mean Time to Repair, calculated by dividing total downtime across a period by the number of incidents that caused it. Repeatedly missing MTTR targets points to a provider that can detect problems but can’t fix them quickly enough.
Breaches are usually categorized as minor or major depending on how far performance deviated from the target. A brief latency dip that barely misses the threshold is minor. A full outage that halts your business is major. That distinction drives the size of the financial remedy and whether you can eventually walk away from the contract.
Exclusions That Don’t Count Against the Provider
Before claiming a breach, check the exclusions. Nearly every SLA carves out events the provider won’t count toward its uptime calculation, and if the downtime falls into one of these buckets, you have no claim no matter how long it lasted.
- Scheduled maintenance windows defined in the agreement and announced in advance.
- Customer-caused outages, including your own misconfigurations, failed deployments, or security lapses.
- Third-party failures outside the provider’s control, such as internet backbone outages or upstream DNS problems.
- Force majeure events like natural disasters, pandemics, and wars, which suspend the provider’s performance obligations for the duration of the event.
Disputes most often arise right here. A provider may classify an outage as a third-party failure while you see it as a problem inside their infrastructure. Independent monitoring data is what turns that argument in your favor.
Service Credits: The Standard Remedy
When a provider breaches, the remedy is almost always service credits rather than cash. Credits are calculated as a percentage of your monthly bill for the affected service and are applied against your next invoice. The percentage scales with severity.
AWS structures compute SLA credits on a sliding scale: uptime below 99.99% but at or above 99.0% earns a 10% credit, below 99.0% but at or above 95.0% earns 30%, and anything below 95.0% earns a 100% credit of the affected service’s monthly charges.1Amazon Web Services. Amazon Compute Service Level Agreement Google Cloud follows a similar tiered structure, with credits of 10%, 25%, or 100% depending on how far uptime fell below the guarantee.2Google Cloud. Compute Engine Service Level Agreement (SLA)
Two limits matter. Even a 100% credit only covers what you paid for the specific service that failed during that billing month; it doesn’t reimburse revenue lost while your application was down. And credits can’t be transferred or cashed out. AWS states explicitly that service credits “will not entitle you to any refund or other payment.”1Amazon Web Services. Amazon Compute Service Level Agreement Google Cloud caps aggregate credits at the total amount due for the affected services in the regions that missed the target.2Google Cloud. Compute Engine Service Level Agreement (SLA)
In contract terms, these credits operate as liquidated damages: a pre-agreed estimate of losses that both parties accept at signing. Under the Uniform Commercial Code, liquidated damages are enforceable when reasonable relative to anticipated harm, the difficulty of proving actual losses, and the impracticality of another adequate remedy. A clause setting unreasonably large damages is void as a penalty.3Legal Information Institute. UCC 2-718 – Liquidation or Limitation of Damages; Deposits Most SLA credits are modest enough that enforceability isn’t the fight. The fight is that credits rarely come close to covering real business losses.
Why Credits Usually Don’t Cover Your Actual Losses
Two more provisions sit behind the credit mechanism and limit anything you might recover through legal action. Understanding them is essential before deciding how hard to push.
The first is a liability cap. The most common structure limits the provider’s total financial exposure to one times the annual fees paid under the contract. Pay $120,000 a year and the maximum recovery across all claims is $120,000, regardless of actual losses. Some enterprise contracts set higher caps for specific categories like data breaches, but those are still ceilings.
The second is the consequential damages exclusion. This clause eliminates provider liability for indirect losses such as lost revenue, lost profits, lost business opportunities, and lost data. Standard terms almost universally exclude liability for these indirect or consequential losses.4UNCITRAL. Notes on the Main Issues of Cloud Computing Contracts For most businesses, the consequential damages are the real damage. A six-hour outage might generate a $500 credit while costing you $50,000 in lost sales. The exclusion is what blocks recovery of that $50,000.
These clauses are generally enforceable between sophisticated commercial parties, especially when both sides had counsel during negotiations. Courts hold parties to clear, unambiguous risk allocations. The practical consequence: the time to negotiate credit percentages, caps, and exclusions is before signing, because after an incident the contract controls.
When a Breach Becomes Material
Isolated misses are annoying but manageable. The situation changes when failures become chronic. Most well-drafted agreements include a chronic failure clause defining when repeated breaches cross into material breach, giving you the right to terminate.
A typical trigger is missing the uptime target three or more times within a rolling six-month window, or cumulative downtime exceeding a defined threshold. Once that line is crossed, the breach is no longer about one bad month. It signals a fundamental inability to deliver.
The legal distinction between minor and material breach is well-established. Courts evaluate materiality by asking how much the failure deprived you of the benefit you reasonably expected, whether you can be adequately compensated for that deprivation, the likelihood the provider will cure, and whether the provider’s conduct reflects good faith. When a provider repeatedly blows through uptime targets despite cure attempts, most of those factors point toward material breach.
Material breach unlocks remedies that credits alone can’t provide. You can issue a termination notice that bypasses the standard contract term, potentially without paying early termination fees. Some agreements also allow pursuit of actual damages beyond the credit structure when termination is triggered by material breach, though this depends on how the liability and exclusion clauses are drafted.
Documenting the Breach
A breach you can’t prove is a breach you can’t claim. Documentation is the foundation of any successful SLA dispute, and collection has to start before an incident, not after.
Your primary data source is your own monitoring infrastructure. Internal system logs should capture exact timestamps for when services became unavailable or degraded. Third-party uptime monitoring tools provide independent verification that can resolve disputes when your data and the provider’s status page disagree. Running an external monitoring service alongside the provider’s dashboard gives you a parallel record the provider can’t edit or reinterpret.
Support tickets matter equally. Every incident should generate a ticket recording the submission time, priority level, and resolution timestamp. That paper trail verifies whether the provider met its response and resolution commitments. Export these records immediately after each incident rather than trusting the provider’s system to retain them indefinitely.
Some agreements include an audit clause granting you the right to inspect the provider’s internal monitoring data. These clauses work best when they specify the audit’s scope, require reasonable advance notice, restrict activities to normal business hours, and impose confidentiality on both sides. Exercising audit rights early establishes that you take compliance seriously.
For every incident, map the data to the specific section and metric in your SLA. A pile of monitoring data without a connection to a contractual obligation is noise. Providers respond to “Section 4.2 guarantees 99.99% monthly uptime; our records show 99.91% in March” far more seriously than “your service was slow last month.”
Filing the Claim
Filing a claim isn’t informal. Providers impose strict procedural requirements and missing a step can disqualify you entirely.
Deadlines come first. AWS requires credit requests to be submitted by the end of the second billing cycle after the incident. The claim must be filed through the AWS Support Center and must include specific dates, times, affected region, resource IDs, and request logs documenting the outage.1Amazon Web Services. Amazon Compute Service Level Agreement Microsoft gives partners two months from the end of the billing month in which the incident took place.5Microsoft. Request a Credit from Microsoft Miss these windows and you forfeit the credit no matter how severe the outage was.
The claim itself must reference specific metrics. Vague complaints don’t trigger the credit mechanism. You need to identify the exact SLA provision that was violated, the measurement period, and the data proving the violation. AWS states explicitly that failing to provide the required information “will disqualify you from receiving a Service Credit.”1Amazon Web Services. Amazon Compute Service Level Agreement
After submission, the provider has a defined review period to verify your data against their records. This cure period typically runs 15 to 30 business days. During the window, the provider may dispute your measurements, reclassify the outage under an exclusion, or acknowledge the breach and issue credits. If the provider fails to respond within the cure period, your contract should specify what happens next, whether that’s automatic credit issuance or escalation.
When the Provider Rejects Your Claim
Most SLA contracts don’t send a rejected claim straight to court. They require a structured escalation first.
The typical path starts with operational contacts: your account manager and the provider’s service delivery team compare monitoring data and try to agree on what happened. If that fails, the dispute escalates to director-level or executive sponsors with authority to approve exceptions and negotiate settlements outside the standard credit structure. This tiered approach exists because most SLA disputes involve ambiguous data rather than clear bad faith, and a conversation between people with decision-making authority tends to resolve them faster than lawyers.
If internal escalation fails, contracts usually specify mediation or arbitration before litigation. Arbitration is binding and typically faster than court proceedings but limits your appeal options. Mediation is non-binding and works best when both parties want to preserve the relationship. Read the dispute resolution clause carefully. Some providers include mandatory arbitration provisions that waive your right to a jury trial.
The escalation process is itself leverage. A provider watching a customer methodically document breaches, file timely claims, and move up the escalation ladder knows litigation is a real possibility. That awareness often produces better settlement offers than the standard credit mechanism provides on its own.
Using Breach History to Renegotiate
Breaches don’t just create backward-looking remedies. A documented pattern of underperformance transforms renewal negotiations from a subjective discussion about pricing into a data-backed conversation about accountability.
When approaching a renegotiation, quantify everything. Calculate total service credits earned, the actual business impact of each outage, and the gap between the two numbers. That gap is your strongest argument. Concessions worth pursuing beyond improved credit percentages include higher liability caps linked to two or three times annual fees, narrower consequential damages exclusions that carve out specific loss categories like data recovery costs or regulatory penalties, tighter uptime commitments that match the provider’s actual delivered performance, shorter cure periods so credits are issued faster, lower thresholds for chronic failure triggers, and a commitment that transition assistance will be provided at no cost if you terminate for cause.
Providers resist these changes during initial negotiations because the customer has no performance data to cite. After a year of documented breaches, the dynamic shifts. The provider knows you have grounds to leave, and retaining a paying customer on revised terms is almost always cheaper than losing one.
Performance Breach Is Not Data Breach
One boundary worth drawing before you treat an SLA incident as routine: not every provider failure is a performance issue. If your provider suffers a data breach that exposes customer records, the legal landscape changes. Performance SLA breaches are governed entirely by the contract. Data security breaches trigger regulatory obligations, notification requirements, and liability that exist independent of what the SLA says. Laws like GDPR and state data breach notification statutes impose their own duties, and consequential damages exclusions may not apply when the breach involves gross negligence or willful misconduct. If your SLA treats both the same, that’s a gap to close at the negotiation table, with separate and higher remedies for security incidents that explicitly survive the general liability cap and damages exclusion.