Passing Credits Through: When an AWS Outage Means You Owe Your Customers
September 8, 2026
When the provider fails, two compensation systems activate: theirs and yours. AWS, Azure, Google, and DigitalOcean owe credits to the account holder, which is you. Your customers do not have contracts with your providers; they have contracts with you. If those contracts carry an uptime commitment, the same outage that earns you a 10% credit can cost you 100% of a customer's monthly fee, and the two flows are connected only by your own paperwork.
The two contracts, side by side
The asymmetry is structural. Provider SLAs cap their liability at service credits, a percentage of the affected service's regional bill. Your customer contracts, if you wrote them the way providers write theirs, cap your liability at a percentage of what that customer pays you. The difference is the base: you pay credits on your infrastructure bill, but you receive revenue per customer that is usually several multiples of that bill.
| Layer | Who owes whom | Base for the credit | Typical scale |
|---|---|---|---|
| Provider SLA | AWS to your account | Percentage of affected service charges in the affected region | 10% first tier, 25% and 100% above, per published schedules |
| Your service commitment | You to your customer | Percentage of that customer's monthly fee to you | Whatever your contract says: 5%, 10%, or the whole month |
| Your costs of the outage | Not covered anywhere | Staff time, churn, reputation | Real, uncapped, and unrecoverable |
The pass-through gap is easiest to see with numbers. A SaaS operator spends $2,000 a month on EC2 in us-east-1. A regional breach month earns a first-tier provider credit of $200. The same outage breached their contractual 99.9% commitment to a customer paying $3,000 a month, and that contract pays a 10% service credit: $300 out. The provider credit covered two-thirds of the customer credit, and the operator's margin ate the difference, before counting the support hours.
What your customers can actually claim from you
Only what your contract says, which makes the contract the most consequential document in this entire system. Common structures, from least to most dangerous for you:
No stated commitment. Nothing to claim; the customer's remedy is churn. Common in early-stage SaaS, and a sales obstacle exactly when the customer has been burned by your outage.
A commitment with a credit schedule. The standard shape: 99.9% or 99.95% monthly availability, with service credits of 5% or 10% at the first tier, sometimes escalating. This is the market norm because it is survivable. It converts your worst outage into a defined, bounded payment.
A full-month remedy. Some contracts escalate to 100% of the monthly fee for severe breaches. Under that structure, a provider outage you did not cause can cost you an entire customer month, and the provider credit recovers a fraction.
Uncapped or consequential liability. The dangerous one: contracts that let customers claim lost revenue or consequential damages from your downtime. Most providers disclaim consequential damages in their own agreements for the same reason you should.
The provider's credit is a discount on your bill. Your customer's credit is a discount on your revenue. The two are different sizes because the bases are different sizes, and the gap is your cost of their outage.
Making the pass-through work on purpose
Three practices turn this from a liability into a manageable process.
Mirror the provider's measurement, then tighten slightly. Define availability in your contract the way the provider defines theirs (connectivity per minute, per region, with scheduled maintenance excluded), so a provider breach maps cleanly onto your customer commitments. If your stack runs multi-region, you can honestly commit above any single provider's regional SLA, because your commitment is to your architecture, not theirs.
Wire the evidence to both claim flows. The probe logs and incident timeline that support your provider claim are the same documents your customer-facing credit calculation needs. One evidence file, two uses. The evidence checklist is the template for both, and the deadline mechanics apply on both sides: your provider windows are fixed, and your customer-facing commitments usually run on your own billing cycle.
Claim first, then pass through. File the provider claim as soon as the incident is captured, and apply the expected credit against the customer credit when it lands. The provider credit is applied to future bills; some operators net it against the customer's credit as a goodwill gesture rather than money, which costs less cash and reads better in the relationship.
The part that is not credits
The deepest cost of a customer-facing outage was never recoverable: the customer evaluating alternatives during the incident, the support queue, the renewal conversation that now starts with an apology. Credits, both directions, are money; retention is the real battle, and it is fought with incident communication, which the customer communication piece covers properly.
What a pass-through policy buys you is time and credibility during that conversation: a customer who sees an automatic credit appear on their next invoice without asking is a customer having a very different renewal conversation than one who had to negotiate compensation. UptimeAudit helps on the inbound side of that flow, monitoring the big four and drafting the provider claims that fund the credits you promise outward. The commitments themselves are yours to set, and setting them just below what your architecture can honestly deliver is the quiet discipline that keeps the whole system solvent.