SLA Breach: Service Credits, Penalty Clauses and How to See One Coming

TL;DR

• An SLA breach happens when a provider misses a service level written into a contract, such as uptime, response time or resolution time. The contract, not the incident, decides what the breach costs.
• The usual consequence is a service credit: a percentage of the monthly fee that steps up as performance falls. AWS, for example, credits 10%, 30% or 100% of the EC2 charge depending on monthly uptime (aws.amazon.com). Repeated breaches often add a termination right.
• Most SLA penalties are visible before they trigger. The signs sit in the ticket queue and in customer email weeks before the measurement period closes. Nobody adds them up against the contract.
• Sentra joins the contract terms and ticket data with what customers and staff say in email, chat and calls, and raises an SLA breach that is about to trigger a penalty to the account owner with the evidence. A named person approves before anything goes out.

What is an SLA breach?

An SLA breach is a failure to meet a service level that a contract commits to, measured over the period and by the method the contract defines. A 99.9% monthly uptime commitment is breached when measured uptime for that month falls below 99.9%, after any agreed exclusions such as scheduled maintenance.

Google's SRE book draws the useful distinction. A service level indicator (SLI) is "a carefully defined quantitative measure of some aspect of the level of service." A service level objective (SLO) is a target for that measure. An SLA is "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain" (sre.google). If missing the target has no consequence, it is an SLO, not an SLA.

That gives three questions for any suspected breach:

1. What exactly was promised? The metric, the threshold and the measurement window.

2. How is it measured? Whose data counts, what is excluded, and whether the clock runs in business or calendar hours.

3. What follows a miss? A credit, a claim process, an escalation, or a right to terminate.

Common SLA metrics

The numbers in this table are typical ranges for illustration. Your contract's definitions govern. For supply chains, the delivery commitment is often expressed as on time in full; see OTIF.

SLA penalty and service credits: how they work

A service credit is a reduction in future fees when a service level is missed. It is usually tiered, so the credit grows as performance falls. The AWS Compute SLA is a well-documented example (aws.amazon.com):

Four contract mechanics decide what a breach is actually worth.

• Claim process. Some credits apply automatically. Others must be claimed. AWS requires a support case received "by the end of the second billing cycle after which the incident occurred," with incident dates, times, resource IDs and logs, and says missing information disqualifies the claim (aws.amazon.com). An unclaimed credit is money the customer never sees.
• Form of credit. AWS applies credits against future payments rather than as refunds (aws.amazon.com). A customer leaving at renewal may get nothing from a credit.
• Sole remedy. Many SLAs state that credits are the customer's "sole and exclusive" remedy for the failure, as the AWS SLA does unless the agreement provides otherwise (aws.amazon.com). That clause limits a damages claim, so read it before you escalate.
• Cap and escalation. Credits are normally capped, often at a share of the monthly fee. A well-drafted contract adds a further remedy once the cap is hit, such as termination for persistent failure, as contracko.com notes. Without one, the customer may have no recourse after the cap.

Service credit formula

For a tiered SLA, the credit for the period is:

Service credit = monthly fee for the affected service × credit percentage for the tier reached, subject to the cap.

Some contracts use a linear formula instead, such as a fixed percentage per point of uptime missed. Contracko gives an illustrative example of 5% of the monthly fee for each percentage point below 99.9% (contracko.com).

Is an SLA penalty enforceable?

Courts treat a payment for breach differently from a price adjustment, and some service credits are drafted to sit on the price side of that line. Where a clause is challenged as a penalty, the test depends on the governing law.

• England and Wales. In Cavendish Square Holding v Makdessi [2015] UKSC 67, the Supreme Court replaced the older "genuine pre-estimate of loss" approach. The question is whether the clause imposes a detriment out of all proportion to the innocent party's legitimate interest in performance.
• United States, sale of goods. UCC 2-718 allows liquidated damages "at an amount which is reasonable in the light of the anticipated or actual harm caused by the breach," and states that "a term fixing unreasonably large liquidated damages is void as a penalty" (law.cornell.edu). Service contracts fall under state common law, so check the rule for your governing law with counsel.

For most operators the practical point is simpler: a credit that is proportionate, capped and clearly tied to the service level is the norm, and the contract wording decides the outcome.

Early warning: how to see a breach coming

Uptime and response SLAs are measured over a period, so a breach builds up across that period before it becomes final. That makes it predictable.

Track the remaining allowance. A 99.9% monthly uptime commitment in a 30-day month allows 43.2 minutes of downtime (43,200 minutes × 0.1%). If 35 minutes are used by day 12, one more short incident breaches the month. Report allowance used and allowance left, not just uptime to date.

Count response-time misses against the trigger. If three P1 response misses in a quarter give the customer a right to terminate, the second miss is the warning, not the third.

Read what the customer is saying. Ticket data shows the measured service level. Customer email and call notes show how the customer is keeping score. "This is the third outage this month" from a customer's head of IT is often the first sign they are logging incidents to claim a credit or build a case for exit.

Check the measurement source. If the customer measures with their own monitoring and the contract allows it, your internal dashboard may show compliance while their data shows a breach.

Set alert thresholds before the period starts. For example: amber at 50% of the allowance used, red at 80%, and an escalation to the account owner at red.

SLA breach tracker template

Keep one row per contract and service level. Review it weekly during any period in amber or red.

Worked example: a penalty visible two weeks early

Assumptions, all illustrative: a SaaS provider sells a platform to a customer for $40,000 a month. The SLA commits to 99.9% monthly availability measured on a 30-day month, with a service credit of 10% of the monthly fee below 99.9% and 25% below 99.0%. Three missed P1 response times in a calendar quarter give the customer a right to terminate for persistent failure.

By 12 October, two incidents have used 35 of the 43.2 allowed minutes. Engineering's status page shows 99.92% month to date, which looks green. The support queue shows two P1 tickets this quarter where first response took longer than the one hour committed.

The customer's operations director has emailed the account executive twice. The first email asks for an incident report. The second, on 14 October, says the team "is keeping a log of every outage for the renewal review." The renewal is in eight weeks.

Put together, the position is clear. One more incident of nine minutes breaches the month and triggers a $4,000 credit. One more late P1 response gives the customer a termination right just before renewal. The credit is small. The termination right on a $480,000-a-year contract is not.

None of the systems alone shows this. The monitoring tool shows minutes. The ticket system shows response times. The contract sits in a document store. The customer's intent sits in the account executive's inbox. The breach is caught only when someone joins all four against the clause.

The same logic runs the other way when you are the customer. If a vendor missed its SLA and the claim window closes 30 days after month end, the credit is lost unless someone files the claim with the evidence in time. That is a form of revenue leakage on the buy side.

Common SLA mistakes

• Measuring with a different definition from the contract. Internal dashboards often exclude incidents the contract counts, or count in business hours when the SLA runs in calendar hours.
• Watching uptime, not the allowance. 99.92% month to date can be one incident from a breach.
• Treating credits as the only exposure. Termination triggers and renewal leverage usually matter more than the credit.
• Missing the claim window. On the buy side, unclaimed credits lapse. On the sell side, a customer who claims late may still argue the point.
• Ignoring the customer's own log. If the customer is counting, assume a dispute and prepare your evidence.
• No single owner. Engineering owns uptime, support owns response times, and sales owns the relationship. Someone must own the contract outcome.
• No root cause after a breach. A credit closes the month. It does not stop the next breach; run a root cause analysis.

SLA terms are one of the obligations covered in the wider contract compliance guide, alongside price escalators, rebates and renewal notice dates.

How Sentra catches this automatically

The SLA is a clause in a contract. The performance is in ticket and monitoring data. The early warning is in what customers write and say. Sentra connects all three.

Sentra reads email, chat, meetings and documents alongside CRM, support and ERP data. It knows what each contract commits to, which customers it covers and who owns the account. It watches the tickets that count against each service level and the conversations around them, so it can see that a customer is two incidents from a credit, one late response from a termination right, and already keeping a log for renewal.

When a breach is close to triggering a penalty, Sentra raises it to the account owner with the evidence: the clause, the measured position, the tickets, and the customer's own words with the date and source. On the buy side it does the same for a vendor's missed SLA before the claim window closes. Sentra knows when a fact became true and when it stopped being true, so an amended SLA schedule replaces the old one rather than sitting beside it.

A named person approves anything Sentra raises before it reaches anyone else, and Sentra never sends a notice or a claim on its own. Every answer respects each source's existing permissions. Sentra holds SOC 2 Type II and ISO 27001, and runs in the cloud, an isolated VPC or air-gapped on-prem. It works with your support desk, CRM and contract repository rather than replacing them.

To see Sentra catch an SLA breach before the contract clock runs out, book a demo.

How to start

1. List every contract with a service level and a consequence. Start with your top 20 customers by revenue and your top 10 critical vendors.

2. For each, record the metric, window, exclusions, credit tiers, cap, termination trigger and claim window in the tracker above.

3. Map each metric to the system that measures it and confirm the definitions match the contract.

4. Set amber and red thresholds on the remaining allowance, with one owner per contract.

5. Review weekly in any period that goes amber, and add customer signals from email and calls to the row.

FAQ