Skip to content
ToolSimu

SaaS, AI & Cloud · Interactive simulator

SLA Breach and Downtime Loss Simulator: What an Outage Costs Beyond the Credits

The SLA credit is the smallest part of an outage. See how downtime minutes, your promised allowance, credit terms and churn after incidents decide the real monthly cost.

Control tower

Recurring revenue billed per month, which SLA credits and churn are measured against.

$120,000

Total minutes the service was unavailable or degraded below the SLA definition.

25

Minutes of downtime per month your contract allows before credits are owed. About 44 minutes equals 99.9% uptime.

44

Share of the monthly fee credited to customers when the SLA is breached. It doubles in a severe breach.

10%

Share of MRR that cancels or downgrades for each hour of downtime, over the following months.

0.6%

Share of revenue earned per hour of use or per transaction, which is simply not earned while the service is down.

30%

Runs a reverse stress test and a 1,000-run Monte Carlo on the current scenario.

Net result per month

$75,923

Cascading domino flow

Each stage feeds the next. Green is safe, amber is a warning and red is critical.

  1. 1

    Downtime

    0.4

    hours of outage in the month

    Safe

  2. 2

    SLA credits owed

    $0

    paid or credited to customers

    Safe

  3. 3

    Revenue at risk of churn

    0.3%

    of MRR lost after the incident

    Safe

  4. 4

    Share of profit lost

    2.7%

    of normal monthly profit

    Safe

  5. 5

    Profit

    $76K

    net per month after incidents

    Safe

Money is shown in USD at an illustrative scale, not a live exchange rate.

Deep-dive guide

SLA Breach and Downtime Loss Simulator: What an Outage Costs Beyond the Credits

Executive industry analysis

Service level agreements promise availability, and customers who sign them expect it. When the promise is broken, the most visible consequence is the credit: a percentage of the monthly fee returned to the customer. Companies often budget for credits and consider the risk covered. In reality, credits are usually the smallest part of what an outage costs. The larger costs arrive afterwards, as customers who cancel, deals that stall and an engineering team that spends days on repair instead of building.

The structure of the problem has two clocks. The first is the contract: the SLA allows a certain number of minutes of downtime, and anything beyond that triggers credits, often in tiers. The second is the customer relationship, which has no threshold. Every hour of downtime erodes trust a little, whether or not the contract was breached. A company can stay inside its SLA and still lose customers, and can breach it by a few minutes and lose none. The model keeps both clocks separate.

The domino model follows an outage through the business. Downtime minutes are compared with the allowance and produce credits when exceeded. Longer outages cause more churn, measured as a share of recurring revenue that leaves in the months after. That loss, together with lost usage revenue and incident work, takes a share of normal profit, and the last box shows what is left. The effect is nonlinear, since a long outage can cross the severe-breach tier, double the credits and trigger more churn at once.

The iceberg shows where the money goes. Visible are the usage revenue that was not earned during the outage and the credits that were paid. Below the waterline are the future revenue lost to customers who leave, the labour of people pulled into the incident and the post-mortem, and the new sales that slow down while prospects hear about problems. Each of these tends to exceed the credit. Use the simulator to see how long an outage your business can absorb, and what reliability work is worth at your revenue.

Formula and methodology blueprint

The model is a single month. Downtime is entered in minutes and compared with the SLA allowance. If downtime is within the allowance there is no credit. If it exceeds the allowance the credit is the credit percentage of MRR, and it doubles when downtime exceeds three times the allowance. Lost usage revenue is the usage-billed share of MRR earned per hour, times downtime hours. Churn applies a revenue-at-risk share per hour of downtime, over a six-month horizon at the operating margin.

Credit tier
tier = 0 if D ≤ A, 1 if D ≤ 3A, otherwise 2
Whether the SLA was met, breached or severely breached.
SLA credits
Credits = MRR × credit % × tier
Money returned to customers for the breach.
Lost usage
U = MRR × usage share ÷ 730 h × downtime hours
Usage-billed revenue that is not earned while the service is down.
Churn loss
C = MRR × min(1, hours × churn per hour) × 6 months × 65% margin
Future profit lost to customers who leave or downgrade after the incident.
Net profit
Net = 65% × MRR − U − credits − labour − C − sales drag
The monthly result. The breaking point is where it reaches zero.

Cascading elasticity

Downtime is the most elastic input, since every hour increases usage loss, labour, churn and sales drag, and can cross a credit tier. Churn per hour is the next most powerful because it multiplies MRR over months. Credit percentage matters only once the allowance is breached.

Three real-world case studies

Bootstrapped starter

A young SaaS with a generous allowance

A small product has a modest MRR and a loose SLA allowing several hours a month. One hour of downtime stays inside the allowance. Loading it shows that a generous contract protects against credits but not against lost trust.

Scaling mid-market

A large platform with tight reliability

A platform with high MRR keeps downtime to a few minutes against a strict allowance. A brief incident costs little in credits, though revenue is large. Loading it shows why reliability investment pays off at scale.

Black-swan crisis

A long outage against a strict SLA

A business with a strict SLA suffers a day-long outage. The credit tier doubles, usage revenue stops, the on-call team works for days and customers cancel. Loading it shows credits being only a fraction of the loss.

Industry benchmark matrix

MetricDanger zoneIndustry averageTop 10% elite
Monthly downtime for a 99.9% SLAAbove 44 min10–30 minUnder 5 min
Mean time to recoveryAbove 2 hours30–60 minUnder 15 min
Credit on breach (share of monthly fee)50% or more without caps10–25%Capped, tiered 5–25%
Cost of an outage vs credits owedCredits seen as the full costTotal 3–5 times the creditsFull cost tracked per incident
Customer communication during incidentsNone or delayedStatus page, hourly updatesProactive notices and a post-mortem

Variables and levers

Monthly recurring revenue

Recurring revenue billed per month, which SLA credits and churn are measured against.

Lever: Large MRR makes every outage more expensive, so scale reliability work with revenue rather than behind it.

Downtime this month (minutes)

Total minutes the service was unavailable or degraded below the SLA definition.

Lever: Fix the biggest cause of downtime first, usually deploys and dependencies, and add automatic failover and rollback.

Downtime allowed by the SLA (minutes)

Minutes of downtime per month your contract allows before credits are owed. About 44 minutes equals 99.9% uptime.

Lever: Promise only what you have measured: a stricter allowance than your history supports turns normal incidents into credits.

Credit on breach

Share of the monthly fee credited to customers when the SLA is breached. It doubles in a severe breach.

Lever: Cap credits at a defined share of the monthly fee and make claims a documented process, within what your contracts and local rules allow.

Revenue churn per hour of downtime

Share of MRR that cancels or downgrades for each hour of downtime, over the following months.

Lever: Communicate fast during incidents with a status page and honest updates, because trust loss drives churn more than the outage itself.

Usage-billed share of revenue

Share of revenue earned per hour of use or per transaction, which is simply not earned while the service is down.

Lever: Where possible, bill for committed capacity or subscriptions, so that downtime does not zero out the revenue during the outage.

How to use this simulator

  1. 1Start from the realistic preset or enter your MRR, last month's downtime and your SLA allowance.
  2. 2Read the five domino boxes to see whether credits or churn turn red first.
  3. 3Press Find my breaking point to see the outage length that wipes out the month.
  4. 4Compare the current plan with the reliability plan on the 24-month chart.
  5. 5Log every incident with its real cost and revisit your SLA terms before the next renewal.

Mistakes to avoid

  • Treating the SLA credit as the cost of an outage and ignoring churn, labour and delayed sales.
  • Promising an availability level without measuring what the service really delivers today.
  • Counting only full outages, when degraded performance also frustrates customers and may breach the SLA definition.
  • Skipping the post-mortem and customer communication, which are the cheapest ways to reduce churn after an incident.

Frequently asked questions

How many minutes of downtime does 99.9% allow?

About 43 to 44 minutes in an average month, and about 8.8 hours a year. 99.99% allows roughly four minutes a month. Check how your contract defines and measures availability.

Are SLA credits the main cost of an outage?

Usually not. Credits are visible and capped, while churn, delayed sales and engineering time are larger and harder to see. The model counts them separately so you can compare.

How should I set the churn per hour?

Look at cancellations and downgrades in the months after past incidents and divide by the downtime hours. If you have no history, start low and test sensitivity.

Should I promise a stricter SLA?

Only if your measured availability supports it and the price pays for the reliability work needed. A promise you cannot keep is a liability.

How do I find the outage length that makes a month lose money?

Press Find my breaking point. The tool moves each input towards its worse end and reports the value where monthly profit reaches zero.

How accurate is this?

It is an educational model with stated assumptions, not legal, contractual or financial advice. Check the terms of your own agreements and replace the inputs with your own data.

This is an educational planning model with stated assumptions. It is not financial, tax or legal advice. Replace the inputs with your own figures and verify important decisions with a qualified professional.