An SLA credit isn’t a remedy. It’s a price list for failure, and it tells your customer what you think a bad month is worth. Amazon’s S3 storage service showed this clearly in February 2008, when an outage of a couple of hours triggered a credit most customers would have struggled to find on their bill.
If you’re designing service tiers, as I described in the tiered SLA matrix, the S3 terms are a useful, public example of what a tier really commits you to. They’re also a reminder that the number in the contract is the part customers remember least.
What did the S3 SLA actually promise?
Amazon publishes the Amazon S3 service level agreement on its own site, and according to InfoQ’s report on the outage, the 2008 version guaranteed 99.9 percent monthly uptime. If Amazon missed that, it credited 10 percent of the month’s charges against the next bill. If availability fell below 99.0 percent, the credit rose to 25 percent.
That’s two tiers, with a threshold and a consequence each. It’s a clean design. It’s also worth translating into minutes, because percentages hide how little room they leave.
- 99.9 percent in a 30-day month is 43,200 minutes, of which 0.1 percent, about 43 minutes, can be down.
- 99.0 percent allows 1 percent, about 432 minutes, or 7.2 hours.
The outage lasted a little over two hours, according to InfoQ. Call it 120 minutes in a month of 43,200. That’s about 0.28 percent downtime, so availability for the month was roughly 99.72 percent: well below the 99.9 percent promise, well above the 99.0 percent line. Customers were owed the 10 percent credit, not the 25 percent one.
For a customer paying a few hundred dollars a month, 10 percent is a few tens of dollars. For a business whose site had stopped serving images for two hours, the credit was a rounding error. That’s not a criticism of Amazon. It’s what a credit is.
Why is a credit not the same as a remedy?
Because the customer’s loss and the supplier’s payment are measured in different things. The customer lost orders, support calls and reputation. The supplier pays back a share of the fee. The two numbers have no relationship, and most SLAs are written that way on purpose: the credit caps your exposure, it doesn’t match the customer’s.
It’s tempting to read the credit as the point of the SLA. It’s the floor. It sets the least you’ll do when things go wrong, and nobody chooses a supplier because of the least it will do.
The InfoQ article makes the same point from the customer’s side. It argues that Amazon’s reputation and track record mattered more than the SLA when deciding whether S3 was appropriate, and it notes that Salesforce.com, a leader in software as a service, deliberately offered no SLA at all, preferring to show customers its service health in real time. Customers also criticised the communication during the incident. One complained about the lack of status updates and about the forum being unavailable at the same moment.
So even in a case with a precise, published SLA, the thing people remembered was how well they were kept informed. The percentage was in the contract. The silence was in the inbox.
What should a tier commit you to?
Three things, and the credit is the least important of them.
- A target you can measure. “99.9 percent monthly” works because anyone can check it. “Prompt response” doesn’t.
- A communication promise. How soon customers will hear about an incident, how often they’ll get updates, and where. This is cheap to deliver and it’s what customers actually judge you on.
- A remedy that fits the customer’s loss, within limits you can afford. A credit is the usual form. For your top tier, it may need to be something more, such as a named person and a review meeting.
Write each one down as a single sentence, along with the measurement window. If you can’t get any of them into a sentence, the tier is still vague, and a vague tier gets interpreted by whoever is angriest on the day.
The rule I’d apply to every tier is that the promise must be tighter internally than externally. I covered that in the post on internal and external SLAs: if your customer tier says four hours, your own internal target should say two. Amazon’s published terms are an external promise. What matters for a team like yours is the internal target underneath one, because that’s the number your team will actually manage to.
What went wrong the second time?
On Sunday, July 20, S3 had another outage, and this one is instructive for a different reason. Amazon’s post-incident write-up, summarised on Simon Willison’s weblog a week later, said a handful of messages had a single bit corrupted. The messages were still readable, but the system state information inside them was wrong, and the system hadn’t been built to detect it. The corruption spread, and Amazon had to shut down communication between servers, clear the system’s state and restart request processing.
I’m not going to guess at how many customers it affected or how long each one was down, because I don’t have verified figures for that. What the write-up does show is the quality of the response. Amazon explained the cause, explained the fix, and said what it would change. That kind of explanation is what turns an SLA breach into something customers can forgive.
Compare that with February. Same company, same service, same SLA. The difference customers noticed wasn’t the credit, which worked the same way both times. It was whether somebody told them what had happened and what would stop it happening again.
The commitment hidden in any tier is that you’ll tell the truth about what happened. That’s harder to write into a contract than a percentage, and it matters more.
How do you design tiers that survive a bad month?
Start with the incident you fear, not the average. Ask what happens to each tier when the worst plausible thing occurs, such as a two-hour outage, and check that three things hold.
- The tier’s promise is still true, or you know exactly how much of it you broke.
- The credit or remedy is affordable if every customer in the tier claims it at once.
- Someone owns the communication and has a template ready. If you’ve built an escalation matrix, that person’s name should already be on it.
Run the arithmetic the way I did above, in minutes, before you publish a number. If a promise of 99.9 percent means 43 minutes, ask your team whether that’s one bad incident or three. If it’s one, you have almost no room, and the tier should probably say 99.5 until you’ve built the resilience to back it. A promise you can’t keep isn’t ambitious. It’s a scheduled apology.
Then keep the tiers few. Two or three is plenty. Every extra tier is another set of numbers your agents have to remember at 2am, and the agent at 2am is the one who decides whether your SLA was real.
How does this change what you tell a customer when you sell a tier?
It makes the conversation more honest. A salesperson who quotes “99.9 percent uptime” without translating it is selling a number the customer can’t picture. Translate it every time: “that allows about 43 minutes of downtime in a month, and here’s what we do and what we credit if we go past it.” Customers who hear that either relax or ask better questions. Both outcomes are better than a surprise later.
It also keeps your own team honest. Agents who know that the top tier means 43 minutes treat a ten-minute blip differently from agents who only know “premium.” The number sets the urgency, and you want the urgency to be consistent across shifts. A tier name tells an agent how important the customer is. A tier number tells them how much time they have left.
What is the cheapest way to improve a tier without raising the number?
Improve the communication, not the uptime. Raising 99.9 to 99.95 means halving your allowed downtime, from about 43 minutes a month to about 22. That costs engineering time and probably money. Promising an acknowledgement within 15 minutes and an update every 30 costs a rota, a template and some discipline.
The S3 reports suggest that when things went wrong, the missing piece for customers was information: status updates and a working forum. Fixing that is cheap and it’s visible. A status page that stays up when your product is down is worth more than another nine in the contract.
If you have to choose between a stricter percentage and a firmer communication promise, choose the communication promise first. You can keep it every time, which is more than you can say for the percentage.
What would I do on Monday?
Pick your top tier. Write down its target, its measurement window, its remedy and its communication promise on one page. Convert the target into minutes per month. Then ask the uncomfortable question: if we had a two-hour outage this month, what would we owe, what would we say, and who would say it?
If the answer is vague, the tier isn’t finished. An SLA that only works in a good month is a marketing line. A good one still reads sensibly after the worst afternoon you’ve had.
Do it once a quarter. Tiers drift as products, volumes and teams change, and the number you wrote a year ago may no longer be one you can keep. The credit will look after itself. The promise needs maintenance.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
