SLA service credits: why uptime promises rarely cover real outages

Most SaaS vendors lead with an uptime number like 99.9 percent and a promise of service credits if they miss it. Founders often treat that SLA service credits line as a safety net. In practice the net has holes large enough to drive a truck through. The credit is usually a percentage of the monthly fee, capped at a low amount, and only triggered after you jump through procedural hoops. Meanwhile your business loses revenue, customers churn, and your team burns hours on workarounds. This article breaks down the common clauses that make credits meaningless and shows what to ask for before you sign.

Key takeaways

• SLA service credits often cap far below real outage costs
• Availability definitions and measurement methods can exclude real downtime
• Sole remedy language blocks other legal options
• Credits may expire or be unusable before contract end
• Negotiate operational terms to reduce outage risk and impact

The math behind the credit

A typical clause reads: "If availability falls below 99.9 percent in a calendar month, customer receives a credit equal to 10 percent of the monthly fee for each full hour of downtime beyond the threshold, not to exceed 50 percent of the monthly fee in any month." On a $2,000 per month plan that caps the credit at $1,000. If an outage lasts eight hours during a product launch you might lose $50,000 in sales. The contract pays $1,000. The gap is not a rounding error. It is the difference between a nuisance and a crisis.

Ask the vendor to tie the credit to a multiple of the average daily revenue impact or at least remove the monthly cap. If they refuse, ask for a higher percentage per hour of downtime. A 25 percent per hour credit with no monthly cap changes the economics fast.

Availability definitions that hide downtime

Vendors define availability in ways that exclude the outages you actually feel. Common exclusions:
- Scheduled maintenance windows that run four hours every Sunday night
- "Force majeure" language that covers any third party cloud provider failure
- Customer equipment or network issues even when the vendor API returns 500 errors
- Beta features or preview releases that your team depends on

One contract said: "Availability is measured from our monitoring system at the edge of our network. Customer side network latency or DNS resolution is excluded." When the vendor DNS provider went down for two hours the SLA showed 100 percent availability. The founder got zero credit.

Ask for a definition that measures from the customer endpoint, includes all production features, and limits scheduled maintenance to a published calendar with a hard cap on total hours per quarter.

Measurement and reporting traps

Even when the definition looks fair, the measurement method can kill a claim. Watch for:
- Monitoring only from one region while your users are global
- Averaging uptime across all customers so a single tenant outage is diluted
- Requiring you to open a ticket within 30 minutes of the outage start
- Requiring you to provide logs in a specific format that your stack does not produce

A real clause: "Customer must notify vendor within 15 minutes of discovering the outage and provide timestamped error logs in JSON format." The founder discovered the outage at 2 am, woke an engineer at 2:15, and the engineer spent 40 minutes formatting logs. The claim was denied for late notice.

Ask for a 24 hour notice window, acceptance of standard log formats, and vendor monitoring that covers every region where you have users.

Credit as sole remedy language

Many contracts say: "The service credits described above are customer's sole and exclusive remedy for any availability failure." That sentence blocks you from claiming breach of contract, seeking damages, or terminating for cause. If the vendor has a week long outage you are stuck with the capped credit and cannot walk away without paying the early termination fee.

Ask to delete the sole remedy language or at least carve out an exception for material breaches and extended outages beyond a defined threshold such as 24 continuous hours.

Accrual and redemption restrictions

Credits often expire if not used in 30 or 60 days. Some apply only to future invoices and cannot be cashed out. If you are on an annual prepaid plan the credit may sit on the account until renewal, effectively an interest free loan to the vendor.

One founder saw: "Credits expire 30 days after issuance and may only be applied to future monthly invoices." The credit arrived in month 11 of a 12 month term. The founder could not use it before the contract ended.

Ask for credits that never expire, that can be applied to any open or future invoice, and that are refundable if the contract ends with a credit balance.

Tiered credits that reward the vendor for partial failure

Some SLAs use a step function: 99.9 to 99.5 gets 10 percent, 99.5 to 99.0 gets 25 percent, below 99.0 gets 50 percent. The vendor only feels pain in the deepest tier. A vendor hovering at 99.6 percent pays a trivial credit while your users see daily errors.

Ask for a linear credit that scales with every tenth of a percent below the target, or a flat credit per minute of downtime. Simpler math creates better incentives.

The "good faith" escape hatch

Phrases like "vendor will use commercially reasonable efforts to meet the SLA" or "vendor will act in good faith to restore service" sound harmless. In a dispute they become a shield. The vendor argues they tried hard, so the credit does not apply or the outage is excused.

Ask to replace effort language with objective metrics. The only thing that should matter is whether the measured availability fell below the number in the contract.

What to negotiate instead of relying on credits

Service credits are a backup plan. The primary plan is reducing the chance and impact of outages. Negotiate these operational terms:
- A published incident response SLA with response time by severity level
- A dedicated status page with API access for your monitoring
- Runbook access or a shared Slack channel for critical incidents
- The right to run synthetic transactions from your own monitoring tool
- A termination for convenience clause with a short notice period if uptime stays below target for three consecutive months

These terms give you visibility and leverage while the service runs. Credits only matter after the damage is done.

A quick checklist before you sign

• Credit percentage per hour of downtime
• Monthly and aggregate caps
• Availability definition and exclusions
• Measurement points and frequency
• Notice and evidence requirements
• Sole remedy language
• Credit expiration and redemption rules
• Tiered versus linear structure
• Effort versus outcome language
• Operational commitments beyond the credit

Run through the list with your engineering lead and your finance lead. The engineering lead spots the technical traps. The finance lead quantifies the real cost of an outage.

AxiomRisk can surface the exact sentences that create these traps in your uploaded agreement. You see the risky wording, why it matters, and what to ask the other side.

Final thought

An SLA without teeth is a marketing bullet point. Treat the credit formula as a negotiation lever, not a guarantee. If the vendor will not move on the cap, the definition, or the sole remedy clause, you have learned how much they value your uptime. That signal is worth more than any credit they might pay.

Next step

Check your contract free and see the clauses that limit your recovery before the next outage hits.