Your customer SLA is only as strong as the weakest provider underneath it, and for most software companies that provider is a cloud region you’ve never seen. If your contract promises 99.9 percent and your whole service sits in one region of one cloud, you haven’t made a promise. You’ve resold somebody else’s, with your name on it.
The AWS outage on October 20 made that concrete for a lot of support teams at once. According to Amazon’s own post-event summary, the trouble began at 11:48pm Pacific on October 19 in the N. Virginia region, us-east-1, when a latent race condition in DynamoDB’s automated DNS management left the service’s regional endpoint with an empty DNS record. Anything that needed to reach DynamoDB in that region through its public endpoint started failing. Engineers had traced it to the DNS state by 12:38am. DynamoDB itself recovered by 2:40am, but the knock-on effects ran on: new EC2 instance launches failed until 1:50pm, and Network Load Balancers saw connection errors from 5:30am to 2:09pm. Amazon put the end of the event at 2:20pm on October 20, more than fourteen hours after it started.
What does a cloud outage do to your customer SLA?
It breaks it, and your customer doesn’t care whose fault it was. Their contract is with you. When their users couldn’t log in that Monday morning, they opened a ticket with you, not with Amazon. If your SLA counted those hours as downtime, you owe the credit. If your SLA quietly excluded “third-party infrastructure failures,” you’re about to find out how well that clause reads to a customer who lost a working day.
Earlier this year I made the case for never selling a customer SLA nobody can back, and the argument was about internal teams: every group behind the promise has to agree to something faster first. A cloud provider is the same problem one step further down. It’s a team behind your promise, it has its own SLA, and you almost certainly didn’t negotiate it.
Why can’t you just pass the provider’s SLA through?
Because the numbers don’t line up. A provider’s SLA usually compensates you with service credits against your bill for that service, a small fraction of what you pay them. Your customer SLA compensates your customer against what they pay you. If a region outage costs you a credit to every customer at once, the credit you get back from the provider won’t come close to covering it.
There’s also the clock. Your customer SLA might promise an update within thirty minutes and a resolution target for a Priority 1. You can’t resolve an outage in someone else’s data centre. All you control is how fast you notice, how fast you tell people, and whether you had a way to keep running somewhere else.
That’s the honest framing for your next contract review: you’re not promising the infrastructure won’t fail. You’re promising how you’ll behave when it does.
What should a customer SLA say about third-party failures?
Something specific and fair, not a blanket exclusion. Customers’ procurement teams have read a lot of SLAs this autumn, and “we’re not responsible for our suppliers” won’t survive the next renewal. A better shape:
- Availability is measured from the customer’s side, whatever the cause, so the number means what the customer thinks it means.
- The availability target matches your architecture. If you run in one region, don’t promise what only a multi-region design can deliver. Promise less, or invest in the second region first.
- Communication commitments apply regardless of cause. First update within a fixed time, then updates at a fixed interval until resolved. You can always keep these, even when you can’t fix anything.
- A post-incident report within a set number of days for any customer-visible outage, including ones caused by a provider.
The communication terms matter most, because they’re the ones fully in your hands. In my post on internal and external SLAs, the rule was that your internal target must be tighter than your external one. Apply it here: if you promise customers a first update in thirty minutes, your internal target for posting a holding message should be ten.
How should support run a day like October 20?
The same way as any incident, with one difference: you’ll have almost no technical information of your own. The first job is to confirm quickly whether the problem is yours or the provider’s, and to say so in plain words once you know.
For a support team that morning, the practical sequence looks like this:
- Check the provider’s status page and your own monitoring together, and assign one person to watch the provider’s updates so agents don’t all do it.
- Post a holding message early, naming the provider only once you’re confident it’s theirs. “We’re seeing errors linked to an outage at our cloud provider. Our team is working on it. Next update by 9am.”
- Give agents the same words and stop them guessing at causes or recovery times.
- Track every affected customer as the incident runs, because the SLA conversation starts the moment it ends.
Expect the day to be long. The core database problem was fixed within three hours, but the effects on other services lasted most of the working day on the US east coast. Plan your rota for that: the first shift handles the outage, and a fresh shift handles the recovery, the backlog and the customers asking whether it’s really over. An exhausted team giving the all-clear too early creates a second wave of contacts.
Then, when the provider publishes its summary, read it and translate the parts that matter for your customers. Amazon’s summary for this event is long and technical. Your customers need two paragraphs: what happened, in plain terms, and what you’re changing.
What happens at the renewal conversation?
The customers hit hardest will raise it, and the ones who don’t raise it will remember it anyway. Support leaders should be in that conversation, or at least brief whoever is, because the questions will be operational, not commercial.
Expect three. First, what exactly happened to us, and for how long? Answer from your own records, not the provider’s summary, because their timeline isn’t your customer’s experience. Some of your customers may have been down for two hours and others for twelve, depending on which features they used.
Second, what’s changing? This is where a vague answer loses the account. “We’re reviewing our architecture” sounds like nothing will change. “We’re moving login and billing to run from two regions by the end of the second quarter, and we’ll tell you when it’s done” sounds like a plan, provided it’s true.
Third, will the SLA change? If the honest answer is that your current target can’t be met on your current build, say so and offer the choice: a lower target now, or the same target with a dated plan to support it. Customers will forgive a smaller promise far more readily than a broken large one. What they won’t forgive is finding out at the next outage that nothing changed after this one.
Keep a record of every customer conversation. Patterns in what customers ask for are the best input you’ll get for deciding which resilience work to fund first.
What should you change before the next one?
Start with the dependency map. Most teams can name their cloud provider. Fewer can say which of their features depend on which region and which managed service. The October outage started in one database service’s DNS and spread through instance launches and load balancers. If you’d been asked on October 19 which of your features would fail if DynamoDB in us-east-1 disappeared, could you have answered?
Then look at the gap between what you sell and what you’ve built. If the honest answer is that a regional failure takes you down completely, either change the promise at renewal or put a second region on the roadmap with a date. Both are respectable answers. Selling 99.95 percent on a single-region build isn’t.
Finally, rehearse it. Run a drill that starts with “our cloud provider has a regional outage” and time how long it takes to get a holding message to customers. The provider will fix its own systems in its own time. The thirty minutes before your first update are yours.
The cloud is still the right place for most support platforms. October 20 didn’t change that. It did make one thing clear: a customer SLA is a promise about your behaviour on the worst day, and the worst day may start in somebody else’s system at midnight.
