Sales loves four nines. Operations remembers the month a dependency took you offline for an afternoon. An uptime SLA is a promise with a calculator attached. Write the calculator first.
Decide what "down" means
Before any percentage:
- Which services are in scope (API, app, billing, not every microservice)?
- Is slow-but-200 downtime, or only hard failures?
- Do planned maintenance windows count if announced in advance?
- Who measures: your monitors, theirs, or a public status page?
If two lawyers would disagree, customers will too. Write one paragraph customers can understand.
Pick a number from evidence
Look at the last three to six months of real incidents. Add a buffer for the unknown. If you have been at ~99.7% with messy detection, do not sell 99.99%. You are signing up for credits and distrust.
Nines are just downtime budgets. Use them as a translation layer, not as ambition cosplay.
Tie the SLA to detection you trust
If your monitors page on single-probe flakes, your "downtime" record will be fiction. If they under-detect, your SLA will look perfect while customers churn. The measurement system has to be the same one you believe at 3am, ideally multi-region confirmation, not a spreadsheet filled in after the fact.
Credits without theater
Say what customers get when you miss (credit, extension, nothing but honesty). Cap it. Explain how to claim. Ambiguous remedies turn every incident into a negotiation.
A starter shape
- Scope: production app + API
- Down: confirmed unavailability from our external monitors
- Target: 99.9% monthly
- Exclusions: announced maintenance within the window; customer-side network issues
- Source of truth: status.yourdomain.com
- Remedy: service credit up to X% of monthly fee
Ship that only when on-call, status updates, and monitors already exist. An SLA without a pager is a brochure.
