T

It is not standard. Four nines is four minutes and twenty-three seconds of downtime per month, total, including the deploy that went wrong on a Tuesday and the twenty minutes somebody spent working out which service was throwing the errors.

The first SaaS SLA uptime commitment a startup signs is usually chosen by somebody who has never seen the on-call rota, and the number gets picked because it sounds credible rather than because anyone costed it. Sign 99.9% and you have 43 minutes a month, which a competent single-region setup often already delivers. Sign 99.99% and you have committed to an architecture where humans are not in the recovery path at all, because four minutes is less time than it takes to read a page and open a laptop. That distinction, rather than the extra decimal, is what you are agreeing to.

What does each nine actually cost to deliver?

The budget arithmetic is fixed and worth having in front of you during the call, not after it.

The row that changes the company is 99.95 to 99.99. Below that line, a person can be part of the recovery: they get paged, they look, they act, and the clock is survivable. Above it, the entire budget is consumed before anyone has finished reading the alert, so recovery has to be automatic for every failure mode you have thought of, and the ones you have not thought of will each cost you a year of budget in a single incident.

That means health checks that fail fast and correctly, a load balancer that ejects instances without human input, a database with automated failover you have tested under load, and deploys that roll back on their own error signal. What each of those costs architecturally is the same conversation as scaling the backend, because availability and scale are built out of the same components.

There is also a payroll consequence nobody puts in the contract summary. A sustainable on-call rota needs at least four or five engineers to avoid burning out the two people who understand production, and if your engineering team is five people total, you are describing a different company from the one you have.

Can I promise more uptime than my own vendors do?

No, and this is the calculation almost nobody runs before signing.

Availability of serial dependencies multiplies. If a request has to pass through your database, your compute, and an external auth provider, and any one of them being down means you are down, your theoretical ceiling is the product of the three. AWS publishes a 99.95% monthly SLA for RDS Multi-AZ deployments and 99.99% for regional EC2. Put a third-party identity or payments provider committing 99.9% in the same request path and the composed ceiling is 0.9995 × 0.9999 × 0.999, which is 99.84%.

That is below a 99.9% promise before a single line of your own code has failed.

The honest caveat: real availability usually comes out better than the composed floor, because vendor SLAs are conservative and failures do not correlate perfectly. This is not a prediction. It is a way of finding which dependency is capping you, and the answer is nearly always one specific vendor sitting in the synchronous path of every request. Once you know which, you have three options that are all cheaper than an extra nine everywhere: make that call asynchronous, cache aggressively enough to survive its absence, or add a second provider behind an interface.

The version of this exercise your own buyers should be running on you is covered from the other side in what to demand from a vendor's SLA, and reading it as the seller is uncomfortable in a useful way.

How do I use an error budget on my own sales team?

Bring it to the internal conversation before the customer one, which is where it does the real work.

The error budget idea comes from Google's Site Reliability Engineering book, published in 2016, and the mechanic is simple. The gap between your target and 100% is a budget you get to spend. At 99.9%, that is 43 minutes a month to be shared between deploy failures, dependency outages, migrations and everything you have not imagined.

Make that concrete with your own history rather than in the abstract. Pull the last six months of incidents, add up actual customer-facing downtime, and divide by six. Should that come out at 55 minutes a month, 99.9% is a commitment to be materially better than you currently are, and somebody needs to say so out loud before signature. A result of nine minutes means you have been delivering better than three nines without trying, and the negotiation is easier than anyone feared.

You cannot run this without measurement, which is the point where a lot of teams discover they do not actually know their historical uptime. Getting to a defensible number is a subset of logs, metrics and traces, and it needs to exist before the contract, not after the first breach.

We sell reliability engineering, and the first thing I tell people asking for it is to spend nothing for ninety days and just measure. A large share of teams asking for a high availability project are already at three nines and are buying an architecture to solve a reporting problem. The measurement costs an afternoon. If the number comes back at 99.5%, then the conversation is real and worth having.

What should the SLA exclude, and how do I word it?

A short list of exclusions is standard and defensible. The drafting of them matters considerably more than which ones you pick.

Scheduled maintenance needs a defined window, a notice period of about five business days, and a cap on total hours per quarter. Writing unlimited maintenance windows is the fastest way to have the clause redlined back at you, because it makes the guarantee meaningless and procurement teams read that immediately.

Customer-caused unavailability covers misconfiguration on their side, and load they generate outside agreed limits, which sounds theoretical until a customer runs a load test against your production environment on a Thursday afternoon.

Third-party failure is the contentious one. Buyers push back on it, reasonably, because you chose the vendor. The compromise that usually survives is narrower: exclude failures of named infrastructure providers where the failure exceeds that provider's own published SLA, and accept responsibility below that line. It reads as fair because it is.

Beta or preview features should be excluded explicitly and by name, since otherwise every experiment you ship inherits the contractual commitment of your core product.

Resist the urge to add more. A modest number with three clean exclusions gets signed faster than an impressive number with a page of carve-outs, and the second one signals to a security reviewer that you know you cannot deliver it. Procurement teams read exclusion lists as confessions.

Measured from where, and what counts as down?

Define this in the contract or you will be defining it during an incident, opposite a customer who is already unhappy.

Measuring 5xx rates at your load balancer and having the customer measure with a synthetic check from Frankfurt produces two different numbers, and the gap contains your DNS, your TLS termination, your CDN and their corporate network. Both parties will be honestly reporting and the numbers will not match, during exactly the incident that decides the renewal.

Name the measurement source in the document, ideally an independent synthetic monitor both sides can see, from named locations. Then define what constitutes an outage in terms of consecutive failed checks, such as three failures at one-minute intervals from at least two locations, which stops a single flapping check from becoming a contractual event. Partial degradation needs a definition too, because most first SLAs are binary while reality is not. A 40% error rate on your primary endpoint is an outage in every way that matters to the customer, and a contract recognising only total unavailability guarantees you that argument at the worst possible time.

Name the critical endpoints explicitly. A health check returning 200 while checkout fails is a passing SLA and a furious customer.

The gotcha in all of this is that the service credits barely matter. A typical clause returns 10% of the monthly fee for missing the target, which on a €5,000 monthly contract is €500, and finance will not notice it. The real cost of a breach is the incident review, the written root cause analysis with dates, the remediation plan somebody has to own, reliability becoming a standing item in every quarterly business review, and roughly six weeks of unplanned engineering nobody budgeted. One breach on a mid-sized contract has cost teams I have worked with more engineering time than building the availability properly would have taken.

There is a cheaper thing most buyers actually want and rarely get offered. Commit to communication rather than to an extra nine: a public status page, notification inside 30 minutes of a confirmed incident, a named human who calls their named human, and a written summary within two business days. That package satisfies more procurement teams than 99.99% does, and it costs a status page subscription and a rule about who picks up the phone.

If the SLA turns out to be one item on a longer questionnaire, it usually arrives alongside the rest of the enterprise requirements that stall deals, and they are cheaper to handle together than one at a time.

Questions CTOs ask with a redline open

What uptime should a startup offer in its first SLA? 99.9% for most B2B SaaS, which is 43 minutes a month and often close to what you already deliver. Offer 99.5% without embarrassment if you have measured and cannot yet support more.

Can we offer 99.99% uptime? Only with fully automated recovery, because four minutes a month excludes a human from the response path entirely.

What happens if we breach our SLA? Service credits, typically 10% of the monthly fee, which finance will barely notice. The expensive part arrives afterwards as a formal root cause analysis, a remediation plan somebody has to own with dates against it, and reliability becoming a standing item at every quarterly review. Budget roughly six weeks of unplanned engineering for a single breach on a contract of any size.

How is SLA uptime measured? However the contract says, which is why the contract should say. Name the monitoring source, the locations, and how many consecutive failed checks constitute downtime, or the two parties will measure differently during the incident.

Should we exclude third-party outages from our SLA? Partially. Excluding all of them reads as evasive, so exclude failures that exceed a named provider's own published SLA and accept responsibility below that threshold.

Six months of your own incident history, divided by six, is the only figure in this negotiation that nobody on either side can argue with. Teams who walk into the contract conversation without it end up agreeing to whatever sounded confident on the call, which is how four nines ended up in that MSA in the first place.