TechImpact.online

What is an SLA penalty? (simple explanation)

An SLA is a Service Level Agreement. It is a promise about how available a service should be. For example, a vendor may promise 99.95% uptime.

If the service is down more than the allowed time, the vendor may owe you a service credit. A service credit usually reduces a future invoice. It is often not cash.

This calculator helps you estimate that credit. It uses your contract value, your promised uptime, your real downtime, and your penalty tiers.

The basic idea in three steps

1. Find how much downtime your SLA allows.
2. Compare that to your real downtime.
3. If you are over the limit, apply the matching penalty percent to the contract value.

Worked example (easy numbers)

Common mistakes

• Using a 30-day month when your SLA uses a calendar month (28–31 days).
• Counting maintenance windows that the contract excludes.
• Forgetting that credits often need a claim with logs and a deadline.
• Treating estimates as a legal claim. This tool is for planning and negotiation support.

Useful links

See the full downtime tables: SLA uptime → downtime reference. Or convert any SLA with the Allowed Downtime Calculator.

Words you will see in contracts

• Uptime — the percent of time the service should work.
• Downtime — the time the service does not work.
• Service credit — money off a future bill, not always cash back.
• Measurement period — usually one month. Some contracts use 28–31 calendar days.
• Exclusion — events that do not count as downtime (for example planned maintenance).

How to use this calculator well

1. Open your SLA PDF and copy the uptime promise (for example 99.9%).
2. Copy the credit table (for example 10% credit below 99.0%).
3. Enter your monthly fee as contract value.
4. Enter real downtime from monitoring tools (minutes).
5. Adjust the penalty tiers so they match your contract.
6. Export the PNG summary and share it with your team before you open a claim.

Who this helps

CTOs, DevOps engineers, SRE teams, procurement, and founders who buy cloud or SaaS services. You do not need to be a lawyer. You only need clear numbers for a discussion.

If English is not your first language, keep the example simple: one contract value, one uptime target, one downtime number. Then change one input at a time.

Second worked example (EUR)

Here is the same idea with euros. Many European contracts use EUR and calendar months. The math does not change. Only the currency symbol changes.

Try the calculator with €40,000, 99.9%, and 120 minutes. Then change only one input. For example, try 90 minutes instead of 120. You will see how credits move when downtime changes.

What “shortfall” means (tiny table)

Shortfall means how far you missed the uptime promise. It is not the same as total downtime minutes. First you convert downtime into an uptime percent. Then you compare that percent to the promise.

Simple idea:

• Promised uptime — what the vendor said (example: 99.95%).
• Actual uptime — what really happened (example: 99.79%).
• Shortfall — the gap between them (example: 0.16 percentage points).

Vendors often map shortfall bands to credit percents. Example: 0–0.1 pp shortfall → 10% credit; larger shortfall → 25% credit. Always copy the bands from your PDF. Do not invent them.

How monitoring proves downtime

A claim needs evidence. “We felt the site was slow” is not enough. Good proof comes from systems that watch the service from the outside and from the inside.

External monitoring checks your URL or API from the public internet. It records when the check fails. Many teams use tools that ping every 1 or 5 minutes.

Internal monitoring watches servers, queues, and error rates inside your stack. It helps explain why something failed. Vendors still care a lot about customer-visible downtime.

To support an SLA claim, collect:

• Start time and end time of each outage (with time zone, usually UTC).
• Which endpoints or regions failed.
• HTTP status codes or timeout errors from the monitor.
• A short timeline: detect → diagnose → recover.
• Links or exports from the monitoring dashboard (CSV, PDF, or screenshots with timestamps).

Be careful with false alarms. A monitor in one city can fail while users in other cities are fine. Your contract may define downtime as “unavailable for all users” or “failed health checks from two regions.” Read that line. Then match your proof to that definition.

Also separate degraded service from down service. Slow pages may hurt revenue, but they may not count as SLA downtime unless the contract says so. Write that difference in your notes before you open a claim.

Claim checklist (before you email the vendor)

1. Find the SLA section in the signed contract (not only the marketing page).
2. Confirm the measurement period (calendar month vs fixed 30 days).
3. List exclusions: planned maintenance, your own code bugs, third-party DNS, force majeure, and similar.
4. Remove excluded minutes from your downtime total.
5. Calculate actual uptime and shortfall with the same method the contract uses.
6. Match the shortfall to the correct credit tier.
7. Attach monitoring exports with clear timestamps.
8. Note the claim deadline (often 15–30 days after the month ends).
9. Send the claim through the channel the contract names (support ticket, account manager, or portal form).
10. Keep a copy of what you sent and when you sent it.

This calculator helps with steps 5 and 6. It does not replace your contract text or your evidence pack.

SLA credit vs insurance (important difference)

People sometimes mix these two ideas. They are not the same.

• SLA service credit — usually a discount on a future bill from the same vendor. Cap is often a percent of that month’s fees. It rarely pays your full business loss.
• Cyber / business interruption insurance — a separate policy. It may cover larger losses after a deductible and claim process. It is not automatic when uptime drops.

Example: your outage costs the business €50,000 in lost sales. The SLA credit might be only €6,000. Insurance might cover more, but only if the event matches the policy and you filed correctly.

Use this calculator for vendor credit estimates. Use a downtime cost calculator for business loss estimates. Talk to your insurer (or broker) for insurance questions. Do not treat an SLA credit as full insurance.

When NOT to use this calculator

• You do not have the real credit tiers from the contract (guessing tiers creates fake confidence).
• The outage is still open and minutes are still growing.
• You only have “user complaints” and no monitoring timestamps.
• The dispute is mainly legal (termination rights, liability caps, negligence). Those need counsel, not a web form.
• Your “downtime” is only a partial feature failure and the SLA defines availability differently.
• You need exact invoice wording for finance. Export the estimate, then confirm with procurement or legal.

In those cases, pause. Gather facts first. Or use a simpler tool to convert uptime into allowed minutes, then come back.

More guides and related tools

Full minute tables by uptime target: SLA uptime → downtime reference.

Tables for 28-, 29-, 30-, and 31-day months: Calendar-month SLA downtime tables.

Convert any percent into allowed minutes yourself: Allowed Downtime Calculator.

Longer reading on credits and negotiation: Ultimate guide to SLA penalties.

Remember: unique numbers beat generic averages. Your contract, your monitors, and your month length are the three inputs that matter most.