A 99.9% enterprise customer uptime SLA lets you be down about 43 minutes in a 30-day month. Sign it only if six to twelve months of your own monitoring data supports it, run an internal target tighter than the contract, and negotiate the window, exclusions and credits before the number. Then decide who answers the pager at night before you sign, not after the first 3 a.m. page.
What does 99.9% let us be down?
pingping's uptime guide puts 99.9% at 43 minutes 48 seconds a month and 8 hours 46 minutes a year. In a plain 30-day month it's 43.2 minutes. One bad deploy and a slow rollback can eat that in a single evening.
The measurement window changes what a breach means. GitHub's Online Services SLA measures 99.9% per calendar quarter, which gives you 129.6 minutes across 90 days and lets one ugly night be absorbed by quiet weeks. A monthly window gives you a third of that and resets sooner. Ask which one the customer's paper uses.
Your dependencies set a ceiling too. If your product needs three services that each promise 99.9%, the stack delivers 0.999 x 0.999 x 0.999, about 99.7%, or roughly 26 hours of downtime a year. You'd be promising more than your own stack delivers. Check each vendor's own SLA before you accept a number.
Vadim Kravcenko argues that higher targets cost disproportionately more, which is why the number is the last thing to settle.
Can a team our size keep it?
Start with your own data. Sprintlaw's guidance for SaaS vendors is to use six to twelve months of monitoring data if you have it, and to be cautious about committing to a number you haven't tested. Count the minutes you were actually unavailable in each month and compare them with 43. If you were over in two of the last six, don't sign it.
Then look at who can answer a page. Google's SRE book says a single-site on-call team needs at least 8 engineers, and a dual-site team at least 6 per site, so nobody is on call more than 25% of the time. A company of five to fifteen may well have only four or five people who can fix production at night. That's the real gap, and the number in the contract doesn't close it.
| Your situation | What to commit to |
|---|---|
| No monitoring history yet | Business-hours response, no uptime figure |
| History near 99.5%, rota under 8 | 99.5%, response targets only |
| History above the target, cover in place | The full SLA with the terms below |
The middle row is where most seed-to-A teams sit, and in our view it's an honest place to start. Customers accept a lower number with a clear support promise more readily than a figure you then miss.
What do we negotiate before the number?
Terms decide whether the number is survivable. Check them in this order.
Measurement window and who measures
Settle monthly or quarterly, and whether the customer's monitoring or yours is the record. Sprintlaw recommends defining "unavailability" precisely, for example a named set of endpoints returning errors for a set period, so a slow report page doesn't count as an outage.
Exclusions
Planned maintenance with advance notice is the usual one. pingping says most SLAs exclude it provided notice is adequate, typically 24 to 72 hours. GitHub's SLA also excludes scheduled downtime, third-party services and anything outside its reasonable control. Copy that structure, and push for your cloud provider's outages to sit in the same list.
Credits and sole remedy
GitHub gives 5% of the fees for the quarter for 99.5% to under 99.9%, 10% for 99.0% to under 99.5%, and 25% below 99.0%. It caps credits at 90 days of paid service per quarter, requires a claim within 30 days, and calls credits the sole and exclusive remedy. Typical credits elsewhere run 10% to 30% of the monthly fee, which is small against the contract (the worked example below shows how small). Sole-remedy wording is what stops a missed SLA turning into a damages claim, so have a lawyer review it together with your liability cap.
Chronic failure and termination
Customers will ask for an exit if you miss repeatedly. Offer a termination right tied to repeated misses in consecutive quarters, defined in the contract, and keep it narrower than the customer's first draft. How many misses count is yours to negotiate.
Response versus resolution, and support hours
Vadim says to check whether support is business hours or round the clock, and to read the exclusions in the fine print. Promise response times, not fix times: you control when someone looks, not how long the bug takes. For the customer's side of a support contract, see what a software maintenance contract should say.
Start this talk weeks before go-live. Terms are cheap to move before the order form is drafted and expensive afterwards.
What internal target gives us margin?
Set an internal service level objective tighter than the one in the contract. Google's SRE book says a tighter internal SLO gives you room to respond to chronic problems before they become breaches. Treat the gap as your error budget: when it's spent, you stop shipping risky changes until the month recovers.
Don't overshoot the other way. The same chapter warns that users come to rely on whatever performance you actually deliver, so running far above the contract for a year quietly raises the bar.
The minimum to run this: an external monitor that checks your main user journey every minute from outside your own cloud, a public status page, and one dashboard that shows minutes of downtime used this month. Without those you can't prove compliance, and the customer's monitoring will become the record.
Who covers nights and weekends?
You have three honest options, and the table is the choice rule.
| Option | Pick it when |
|---|---|
| Core team on a paid rota | You have 8 or more who can fix production |
| Bought-in cover for monitoring and incidents | Fewer than 8, and you want the full SLA |
| Narrow the SLA to business hours | Nobody can be paged at night |
Google's SRE book also caps a shift at two incidents per 12 hours, so a rota that gets paged more than that needs more people, not more patience. Rota mechanics, handover and pay are covered in setting up an on-call rotation for a small team.
Bought-in cover can be an engineer on a contract who owns monitoring, runbooks and first response, so your product engineers sleep.
What does it cost, in one worked example?
Say the customer pays EUR 15,000 a quarter, a contract worth EUR 60,000 a year. On GitHub's tiers, missing by a little earns the customer EUR 750, missing by more EUR 1,500, and a bad quarter EUR 3,750. The credit is still small against the annual contract.
The bigger exposure is outside the credit schedule. pingping notes that credits don't restore trust, and that severe or repeated breaches can give an enterprise customer the right to terminate early without penalty, so a customer who has had two bad months can leave.
Staffing is the other half, and the rota gap from earlier applies: four people who can answer pages is half of the 8-engineer minimum. Neither a small-team rota nor going from three nines to four has a published price. Get a quote for bought-in on-call cover for your hours, and compare it with stand-by pay for your own rota and the contract's annual value.
What this means for the SLA you sign
You're deciding one thing before signature: accept, narrow or decline the number. Accept it if your last six to twelve months of data clears it and a named person is awake for every night hour. Narrow it to a lower figure or business-hours response if the data or the rota doesn't. Walk away if the customer wants you liable, with no cap, for outages caused by someone else's infrastructure.
Fund the cover in the same meeting. If you need a rota of 8 and have four, the gap is a budget line, not a promise to work harder. Put the credits and the termination clause in front of whoever signs, with the quarterly arithmetic above as the exposure. For the neighbouring decisions at this stage, our startup scaling guides for engineering leaders are the next stop.
Hiring DevOps help for monitoring and incident cover
If the honest answer to who covers nights is nobody, hire for that gap alone and keep your product engineers off the pager. DevOps engineers through HighCircl come with no minimum hour commitment, so you can buy a bounded block to set up monitoring, runbooks and first-response cover, then stop when it's running. Matching takes 72 hours, so the cover can be in place before the customer goes live.
FAQ
What does a 99.9% uptime SLA mean?
It means your service is available 99.9% of the measured period. That's about 43 minutes of downtime in a 30-day month, or 8 hours 46 minutes a year. The contract's window, exclusions and credit terms decide what counts.
Is 99.9% good for a startup?
It's fine if your own history supports it and someone is on call at night. Many teams under 8 engineers do better committing to 99.5% or to business-hours response, then raising the number once the data and cover exist.
What are service credits?
Credits are a discount on the next invoice when you miss the SLA. GitHub's tiers are 5%, 10% and 25% of the quarter's fees, and typical credits run 10% to 30% of the monthly fee. They're usually the sole remedy, which is why the wording needs a lawyer.
Can a small team offer 24/7 support?
Only with a rota big enough that nobody is on call more than a quarter of the time, which Google's SRE book puts at 8 engineers at one site. Below that, buy in cover or limit the SLA to business hours.