SLA Credit vs Actual Loss Calculator

A service credit is a discount on next month's invoice. Your loss during an outage is revenue that did not happen. This calculator computes both from the same availability figure and shows what share of one the other actually covers — usually a small single-digit percentage, because a credit is capped by what you pay the vendor while your loss is driven by what your customers pay you. Enter the availability you were given, your SLA target and credit schedule, and what an hour of downtime costs your business.

Calculator

This calculator runs in your browser. Enable JavaScript for live results — the inputs, formula and worked example below remain fully readable without it.

Inputs this calculator takes, with typical values
InputWhat to enterExample
Monthly service feeWhat you pay this vendor for the affected service each month. Credits are almost always calculated against this, not against your total contract.20000 $/mo
SLA target availabilityThe monthly uptime percentage the vendor commits to. Below this figure a credit becomes payable.99.9 %
Availability achievedWhat the service actually delivered over the billing month, from the vendor's status report or your own monitoring.99.5 %
Credit below the targetPercentage of the monthly fee credited when availability falls below the target but stays at or above 99.0%.10 %
Credit below 99.0%Percentage credited when availability falls below 99.0% but stays at or above 95.0%.25 %
Credit below 95.0%Percentage credited when availability falls below 95.0%. This is the top tier in most published schedules.100 %
Revenue exposed per hourRevenue your business carries in an average hour that depends on this service being available.15000 $/h
Share of revenue actually lostThe fraction of that revenue you never recover once customers return. The rest is delayed rather than destroyed.70 %
Response and recovery costYour own engineering, support and communication cost caused by the vendor's outage over the month.8000 $

It returns

  • Share of your loss the credit covers — Service credit divided by your actual loss.
  • Downtime incurred this month
  • Service credit earned
  • Your actual loss
  • Loss left uncovered
  • Loss you bear even at full compliance — What the SLA's own allowed downtime costs you when the vendor exactly meets its commitment.

The formula

Cov=Fc730(1A)revu+R
D=730(1A)

In plain text: Coverage = (fee × creditPct) / (730 × (1 − A) × rev × impact + recovery)

  • FMonthly service fee for the affected service ($)
  • cCredit percentage triggered by the achieved availability (decimal)
  • AAvailability achieved, as a fraction (decimal)
  • revYour revenue exposed per hour of outage ($/h)
  • uShare of that revenue never recovered (decimal)
  • RYour own response and recovery cost ($)

A billing month is taken as 730 hours (8,760 ÷ 12), which is the convention behind the monthly-uptime-percentage definitions in the major public cloud SLAs. The credit percentage is a step function: zero at or above the target, then the first, second and third tiers as availability falls through the target, 99.0% and 95.0%.

Updated Category Reliability & Cost of Downtime Verified against published test cases Reading time 11 min

What a service credit is, and what it is not

A service credit is a percentage of what you pay the vendor, refunded against a future invoice when availability falls below a committed figure. It is not damages, it is not insurance, and in most contracts it is the exclusive remedy — meaning you agree in advance not to pursue anything else for the outage. That last clause is the reason this calculation matters: you are signing away a claim in exchange for a discount whose size you can compute before you sign.

The mismatch is structural, not a case of a stingy vendor. The credit is bounded by your spend with them. The loss is bounded by your customers' spend with you. For most businesses those two numbers differ by an order of magnitude or more, so even a 100% credit — a full month of fees returned — typically covers a small fraction of what a long outage costs. The calculator makes that ratio explicit instead of leaving it as a vague suspicion.

The second thing the calculation reveals is subtler. Even when the vendor performs exactly to its commitment, the allowed downtime still costs you something. A 99.9% monthly SLA permits 43.8 minutes of outage every month, and you absorb all of it with no credit at all. That figure — what full compliance costs you — is often larger than the credit you would earn for a modest breach, which is a useful thing to know before negotiating a target upward.

How the two sides are computed

Downtime. A billing month is treated as 730 hours, which is 8,760 ÷ 12 and matches the monthly-uptime-percentage definitions used by the major cloud providers. Downtime is 730 × (1 − availability), so 99.5% availability is 3.65 hours and 99.9% is 43.8 minutes. Some SLAs use actual calendar-month minutes instead, which moves the figure by up to about 1.6% between February and a 31-day month — immaterial to the comparison, but check which convention your contract uses before disputing a number.

The credit. Credit schedules are step functions, not proportional. The typical shape has three tiers: a small percentage once you drop below the target, a larger one below 99.0%, and the largest below 95.0%. The consequence is that the credit does not increase with the length of the outage within a tier — an outage of two hours and one of six hours can earn exactly the same credit. This calculator applies your own tier percentages, and it returns zero credit whenever the achieved availability meets the target, regardless of how the tiers are set.

Your loss. Downtime hours multiplied by the revenue riding on the service, multiplied by the share you never recover, plus your own response cost. The recovery share is what separates delayed revenue from destroyed revenue and is worth measuring rather than assuming; the incident response cost calculator breaks the same loss down in more detail across responder time, displaced work and credits owed to your own customers.

Coverage. Credit divided by loss. Because the credit steps and the loss rises continuously, the coverage share does not move in one direction as availability falls — it jumps upward each time a tier boundary is crossed and declines between boundaries. The table below shows that shape across the whole range at your figures.

Worked example: 99.5% delivered against a 99.9% commitment

Take the defaults: you pay $20,000 a month, the SLA commits to 99.9%, the vendor delivered 99.5%, the credit schedule is 10% / 25% / 100%, your service carries $15,000 an hour of revenue, you lose 70% of it permanently, and the outage cost you $8,000 of your own response effort.

  1. Downtime incurred. 730 × (1 − 0.995) = 3.65 hours.
  2. Downtime allowed. 730 × (1 − 0.999) = 0.73 hours, or 43.8 minutes.
  3. Excess. 3.65 − 0.73 = 2.92 hours beyond the commitment.
  4. Credit tier. 99.5% is below the 99.9% target but at or above 99.0%, so the first tier applies: 10%.
  5. Credit earned. $20,000 × 10% = $2,000.
  6. Effective loss rate. $15,000 × 70% = $10,500 an hour.
  7. Revenue lost. 3.65 × $10,500 = $38,325.
  8. Total loss. $38,325 + $8,000 = $46,325.
  9. Coverage. $2,000 ÷ $46,325 = 4.32%, leaving $44,325 uncovered.
  10. Cost of full compliance. 0.73 × $10,500 = $7,665 — what the SLA's own allowance costs you in a month where the vendor performs perfectly.

The last two lines together are the argument. The credit for missing the target is $2,000; the downtime the target permits costs you $7,665. You are being compensated with less than a third of what compliance itself costs you, and with 4.32% of what this particular breach cost. Neither figure is unusual.

How to use the coverage figure

Read it as a negotiating input, not as a grievance. Vendors set credits to be a service-quality signal, not an indemnity, and no amount of arguing changes the structural cap. What the number does support is a specific ask: a higher committed target, a shorter measurement window, or an outage-based termination right that lets you leave after repeated breaches. Those are worth far more than a larger credit percentage.

Check the exclusive-remedy clause. If credits are the sole remedy, the coverage percentage is the entire recovery you will ever see for an outage, and the uncovered figure is the risk you are carrying yourself. That is the risk to price into your own architecture — the backup and DR cost calculator and the cost of additional nines calculator both price ways of buying it down, and either is more likely to pay off than a credit negotiation.

Watch the claim procedure. Most SLAs require you to request the credit within a defined window — often thirty days — with your own evidence of impact, and unclaimed credits are simply not paid. A credit worth 4.32% of your loss is still worth having, and the administrative cost of claiming it is small. Put the deadline in the incident process rather than relying on someone remembering.

Compare targets on allowed downtime, not on nines. The gap between 99.9% and 99.95% sounds trivial and halves your monthly allowance from 43.8 to 21.9 minutes. The uptime and downtime calculator converts any target into minutes for any window, which is the form in which SLA targets can actually be compared.

Downtime allowed by common SLA targets

Allowance from 730 hours per month, 2,190 per quarter and 8,760 per year, at (1 − target). The measurement window matters: a monthly SLA resets the allowance twelve times a year.
TargetPer monthPer quarterPer year
99.0%7 h 18 m21 h 54 m87 h 36 m
99.5%3 h 39 m10 h 57 m43 h 48 m
99.9%43.8 m2 h 11.4 m8 h 45.6 m
99.95%21.9 m65.7 m4 h 22.8 m
99.99%4.38 m13.14 m52.56 m
99.999%26.3 s78.8 s5.26 m

A monthly window is more forgiving to the vendor than an annual one at the same percentage, because a bad month cannot be offset by good ones and, more importantly, twelve separate allowances add up to the annual figure with no memory between them.

Clauses that change the arithmetic

  • Exclusive remedy. Credits are your only recourse. This is the default in most standard terms and it converts the coverage percentage into your total recovery.
  • Credit cap. Many schedules cap total monthly credits at a percentage of the fee even when several services breach at once. Check whether the top tier here is really reachable.
  • Claim window and evidence. A deadline of thirty days is common, along with a requirement to supply your own logs. Miss it and the credit is forfeited regardless of the outage.
  • Excluded downtime. Scheduled maintenance, force majeure, problems attributed to your own configuration, and anything on a beta or preview service are typically outside the measured availability. Your monitoring will show more downtime than the SLA counts.
  • Measurement definition. Availability may be measured per region, per service, per API call or as an aggregate, and the choice moves the number materially. An outage that takes down one region may not breach a global aggregate at all.
  • Credit form. Credits are usually applied against future invoices rather than refunded in cash, which means they are worth nothing if you leave the vendor — the exact circumstance a serious outage makes likely.

A credit is not a substitute for architecture

If the uncovered figure is large enough to matter, the answer is not a better contract but a design that survives the vendor's failure: a second provider, a degraded read-only mode, queueing that absorbs a short outage, or cached data that keeps the critical path alive. Those cost money and this calculation tells you how much they are worth. A vendor who offers a 99.99% target and a 25% credit is telling you plainly that they expect to be down sometimes and that they will not be paying for it.

Where this sits in vendor management

SLA credits are one of three levers in a reliability negotiation and the weakest of them. The strongest is the committed target itself, because it changes the vendor's own engineering priorities rather than compensating you afterwards. The second is a termination or price-review right triggered by repeated breach, which gives you an exit rather than a discount. Credits are the third, and they are best treated as a signal about how seriously a vendor takes availability rather than as a financial instrument.

When renewal comes around, the accumulated credit history is evidence rather than a bargaining chip — a year of breaches is a much better argument for a price concession than for a bigger credit percentage. The renewal uplift calculator covers the price side of that conversation.

Internally, the mirror image applies. If you sell an SLA to your own customers, the same arithmetic runs in reverse and your credits are a liability. Model your own exposure with your customers' fees in the fee field and your own reliability in the achieved field, and set your committed target against what the error budget calculator says you can actually deliver. Committing to a target your error budget does not support is how a reliability problem becomes a revenue problem.

Key terms

Service credit
A percentage of the fee for the affected service, applied against a future invoice when availability falls below the committed level.
Exclusive remedy
A contract term making the credit the only compensation available for a breach of the availability commitment.
Monthly uptime percentage
The vendor's measure of availability over a billing month, usually excluding scheduled maintenance and customer-caused problems.
Coverage share
Credit earned divided by actual loss. The single figure that shows how much of an outage a contract really pays for.

Frequently asked questions

Why is the credit so much smaller than the loss?

Because the two are anchored to different revenue bases. The credit is a percentage of what you pay the vendor; the loss is driven by what your customers pay you. A service costing $20,000 a month can easily sit under a revenue stream of millions, so even a full month's fee returned covers a small fraction of a serious outage. This is a structural feature of the contract model, not a negotiating failure, and it is the reason credits are best understood as a quality signal rather than as compensation.

Does the credit increase with the length of the outage?

Only when the outage is long enough to cross a tier boundary. Credit schedules are step functions of monthly availability, so within a tier a longer outage earns exactly the same credit as a shorter one. That is why a two-hour and a six-hour outage in the same month can produce identical credits while costing you three times as much, and it is worth checking where your contract's boundaries fall relative to a realistic bad month.

Do I get a credit automatically?

Usually not. Most SLAs require you to submit a claim within a set window, often thirty days from the incident, with your own evidence of the impact. Unclaimed credits are simply not paid, and vendors are under no obligation to volunteer them. Add the claim step and its deadline to your incident process so it does not depend on someone remembering during a difficult week.

Why does my monitoring show more downtime than the SLA counts?

Because SLAs exclude categories of downtime: scheduled maintenance windows, force majeure, anything attributed to your own configuration or code, and services in beta or preview. Measurement scope also differs — an SLA measured as a global aggregate can pass while a single region you depend on is down. Reconcile the two definitions before disputing a figure, and record availability the vendor's way as well as your own so you can make a claim in their terms.

Is a 100% credit ever paid?

It appears in most published schedules as the bottom tier, but it requires availability below roughly 95% for a whole billing month — around 36 hours of downtime — which is rare on a mature platform. Many contracts also cap total monthly credits across all affected services, so the top tier may not be reachable in practice. Read the cap before assuming the bottom tier is available.

Should I negotiate a bigger credit percentage or a higher target?

The target, almost always. Raising a target from 99.9% to 99.95% halves the downtime you absorb every month, which is worth more than doubling a credit that covers a few percent of your loss. Better still is a right to terminate or reprice after repeated breaches, because it aligns the vendor's incentives with your availability instead of paying you a token amount after the fact.

Should recovery cost include my own team's time?

Yes — the engineering hours your team spends diagnosing, mitigating and communicating during someone else's outage are a real cost you incur because of the breach. Value them at a fully loaded hourly rate rather than salary. If you want that broken out properly across responders, displaced work and credits owed to your own customers, run the incident through the incident response cost calculator and bring the total back here as the recovery figure.

What is a reasonable coverage percentage to expect?

For a service whose fee is small relative to the revenue depending on it, single digits is the ordinary result, and the worked example's 4.32% is typical of that shape. Coverage only approaches or exceeds 100% when the fee is large relative to the revenue at risk — an expensive tool supporting a modest revenue line, for instance. If your figure comes out high, check that the revenue-per-hour input really reflects what rides on this service rather than on the business as a whole.

References