Uptime SLA Questions: What Buyers Ask and How to Answer

Amazon's published SLA for EC2 promises a Monthly Uptime Percentage of at least 99.99% per region for workloads spread across multiple availability zones (Amazon Compute SLA). It doesn't promise a service that never goes down, and that gap is what buyers are really probing when they bring up uptime SLA questions.

Buyers ask "what's your uptime?" expecting a single figure. What their IT or procurement team will eventually read is a document with definitions, exclusions, a credit table and a claims process. If the number you say on the call doesn't match that document, procurement will notice, and it's an awkward conversation to have at the end of a cycle.

Translate the percentage into minutes

Percentages hide how much downtime they allow. Over a 30-day month (43,200 minutes), the arithmetic works out like this:

Do this sum for your own product before a buyer asks. A rep who says "our SLA is 99.9%, which allows roughly 43 minutes of downtime a month" sounds like someone who has read the contract. A rep who says "we're basically always up" sounds like someone who hasn't.

The minutes also tell you which buyers will push. An operations team running something customer-facing on your product will do this same arithmetic, and a monthly allowance of three and a half hours might be fine for an internal reporting tool and unacceptable for a checkout flow. Ask what the product will sit behind before you defend the number.

What counts as down

Every SLA defines unavailability, and the definition does a lot of work. Some count the whole service as down only when no user can reach it. Others measure per region or per component. Many measure in whole minutes or five-minute intervals, so a short blip may not register at all.

Then there are exclusions. Scheduled maintenance is the one buyers ask about most, usually because a past vendor took their system offline at an inconvenient hour and called it planned. Find out whether your SLA excludes scheduled maintenance, how much notice your company gives, and what time zone the maintenance windows are set in. A European buyer who learns that "off-peak" means a US East Coast evening, the middle of their night, may be fine with it; one who learns it means a US East Coast morning, their working afternoon, will raise it every renewal.

Outages caused by the customer's own systems are commonly excluded, as are events outside the vendor's reasonable control. Beta and preview features are often left out too. You don't need to recite them. You do need to know whether the feature the buyer cares most about is covered at all, because a feature labelled beta often isn't.

If the conversation turns to how your product handles being down from the buyer's side, such as retries on your API or queued webhooks, that's integration territory, and the vocabulary is in how to explain APIs to buyers.

What the buyer gets when you miss

In many SaaS contracts, the remedy for a missed SLA is a service credit: a percentage of the monthly fee knocked off a future invoice, usually on a sliding scale as uptime falls further. AWS's EC2 terms are a useful public example to look at. Credits apply only against future payments, they don't entitle the customer to a refund, and the customer has to submit a claim to receive them.

That last point surprises buyers. Many SLAs require the customer to request the credit within a set period after the incident, with details of the outage. If nobody on their side files the claim, no credit arrives. Check whether yours works that way and say so; it's a small thing that makes you look straightforward.

Also find out whether credits are capped. A buyer's lawyer will often ask for a termination right if the SLA is missed repeatedly, since a capped credit on a modest subscription rarely compensates for the business impact of a long outage. State what the standard terms say, accurately. Anything beyond the standard credit table goes to deal desk.

Recovery is a separate question

Sometimes the buyer isn't asking about uptime at all. "What happens if you lose our data?" or "How fast can you recover from a disaster?" are questions about recovery objectives, and they use different terms.

NIST defines the recovery time objective (RTO) as how long a system's components can be in the recovery phase before the organisation's mission is harmed (NIST glossary: RTO). The recovery point objective (RPO) is the point in time to which data must be recovered after an outage (NIST glossary: RPO). In plain terms, RTO is how long you're down, and RPO is how much recent data you could lose.

Most SaaS uptime SLAs say nothing about RTO or RPO, and many vendors don't publish targets for them. If yours are documented, know where. If they aren't, don't make numbers up on the call. Security reviewers often ask about backups and disaster recovery in their questionnaires, and anything you say early tends to get compared against what security writes later.

The status page and the incident history

The quickest way to answer "how reliable are you really?" is your public status page, if your company has one. Buyers can subscribe to it, see past incidents and judge for themselves how your team communicates during an outage. Send the link before they find it.

Look at it yourself first. If there was a significant incident in the last few months, assume the buyer's technical evaluator has seen it, and raise it before they do: what happened, what changed afterwards, and where the public write-up is. Reps who wait to be asked about a visible outage spend the rest of the call recovering trust.