SLA Credits Explained: How to Calculate, Claim, and Negotiate Service Credits

A service credit is the financial compensation a vendor owes you when they fail to meet their committed SLA. It is usually expressed as a percentage of the monthly fee for the affected service: for example, if uptime falls below 99.9%, you receive 10% of that month's fees as a credit; below 99%, 25%; below 95%, 50%. The exact tiers vary by vendor.

The uncomfortable truth: most organizations never claim the credits they are entitled to. A 2024 survey of mid-market SaaS buyers found that more than 70% of companies with multi-vendor SaaS stacks had experienced SLA breaches in the prior 12 months — and fewer than 25% had filed credit claims. The money is there; the process of claiming it is just friction-heavy enough that it gets deprioritized.

That friction is where monitoring pays for itself. If you already have minute-resolution uptime data from an independent source, filing a credit claim takes minutes and the vendor cannot dispute the numbers. Without that data, claims become negotiations about measurement methodology, which vendors win by default because they control their own measurements.

Step 1: Determine the measurement period. Most vendor SLAs use calendar months. Some use rolling 30-day windows. The contract will specify; if ambiguous, the default is calendar month.

Step 2: Determine the committed uptime target and breach tiers. For a representative cloud vendor: 99.95% uptime = no credit; below 99.95% and above 99.9% = 10% credit; below 99.9% and above 99% = 25% credit; below 99% = 50% credit. Different vendors have different tiers — read the Service Level Agreement document specifically, not the marketing page.

Step 3: Calculate observed uptime during the measurement period. Use independently measured data (PulsAPI or your own probes), not vendor-reported data — vendor-reported uptime is almost always higher than real observed uptime because of how they define 'downtime' (see our post on how to calculate uptime percentage).

Step 4: Apply the credit tier. For a month in which you were billed $8,000 for a service and observed uptime was 99.62%, the credit is 25% × $8,000 = $2,000.

Step 5: Apply any contract-level caps. Most SLAs cap total monthly credits at 25–50% of the month's fees regardless of severity. Some cap annual credits as a percentage of annual contract value. These caps usually don't bite for isolated incidents but matter for unusually bad months.

Most vendors require you to initiate the claim — they do not proactively apply credits, even when they publish incidents acknowledging breach. The claim process is typically a support ticket or a designated SLA claims email address, and usually has a time limit (often 30 days from the end of the affected month).

The ideal claim includes: the measurement period, the observed uptime percentage with the calculation methodology, the independent monitoring source (PulsAPI, Pingdom, StatusGator, or your own synthetic probes), references to the vendor's own acknowledged incidents during the period, and the requested credit amount with the specific SLA tier applied.

Vendors push back on about a third of claims. The typical pushback: 'our internal measurement shows X% uptime' (higher than yours), or 'the incident affected a different region than you were using' (sometimes true, sometimes a stretch), or 'this was a scheduled maintenance window' (check the contract language — increasingly, maintenance windows have to be pre-announced N days ahead to qualify for exclusion). Pushing back on the pushback resolves most claims in your favor within two rounds of email.

Credits from past breaches are leverage at contract renewal. If a vendor breached SLA three times in the past year and you've documented each, ask for one or more of the following at renewal: higher committed uptime target (99.95% instead of 99.9%), larger credit percentages at each tier, shorter response-time commitments, or a dedicated named technical account manager.

Another often-overlooked negotiation lever: the definition of 'downtime.' Standard vendor SLAs count only complete service unavailability. Real customer experience is frequently harmed by latency degradation, elevated error rates below 100%, and regional-only outages — none of which count as downtime under standard definitions. For mission-critical vendors, negotiate a customized downtime definition that includes latency > 2x baseline or error rate > 5% as qualifying degradation.

Finally, set the monitoring source in the contract. Spell out that independent third-party monitoring (PulsAPI by name, or a similar service) is the authoritative measurement source for SLA purposes. This pre-empts the most common vendor dispute during claim filing and converts a discretionary claim process into a near-automatic one.