Service Level Objectives are the contract between reliability and velocity.
A Service Level Objective (SLO) is an internal reliability target — 'the checkout API will return a successful response within 500ms for 99.9% of requests over a 28-day window.' An SLI is the measurement that feeds it. An error budget is the amount of unreliability the SLO permits, spent on feature velocity and repaid with reliability work when depleted. Together they are the most useful reliability framework Google ever exported, and most startups implement them badly by copying targets that do not fit their business.
A good SLI measures what a user actually experiences. Bad SLI: CPU utilization, error rate on internal endpoints, backend latency. Good SLI: percentage of user-visible requests that returned a correct response within a threshold. For request/response services: availability (fraction of requests without 5xx or timeout) and latency (fraction of requests faster than a threshold). For pipelines: freshness (fraction of records processed within N minutes of arrival) and correctness (fraction passing downstream validation). For batch jobs: coverage (fraction of expected inputs processed) and skew (fraction completed within the SLA window). Two to four SLIs per critical service; more becomes unmanageable.
Do not start with 99.99%. Start with the current measured performance over the last quarter and pick a target that is achievable AND slightly stretching. If checkout is currently at 99.7%, set the SLO at 99.9% — meaningful improvement, not an unreachable goal that will be ignored. Each 'nine' costs roughly 10x more than the previous one; four nines requires multi-region active-active, tested failover, and 24/7 SRE — usually only justified for revenue-critical paths at scale. Common targets: 99.9% for a Series A SaaS checkout, 99.5% for internal admin tools, 99.95%+ only where you have proven customer demand and margin to fund it.
A 99.9% availability SLO over 28 days = 40.3 minutes of allowed unavailability. That is the error budget. Track budget burn in real time (Datadog, Grafana, Nobl9, or a homegrown Prometheus recording rule). Alerting: fast-burn (2% of budget consumed in 1 hour → page) and slow-burn (10% in 3 days → ticket). Budget policy: when >50% remains, ship features aggressively; when <20% remains, freeze non-reliability work until budget refills; when exhausted, no non-reliability launches until a post-incident review. This policy has to be respected by leadership or the whole system is theater.
Review SLOs quarterly. Questions: was the target consistently met or missed? Did users actually complain when the SLI dropped, or is the SLI measuring the wrong thing? Did we spend budget on planned risk (a big migration) or on unplanned incidents? Adjust — raise targets that are trivially met, lower targets that are chronically missed while investigating the root cause, retire SLIs that do not correlate with user experience. SLOs are living documents; setting them once and never revisiting is a common failure mode.
SLO = internal target. SLA = external contract with financial penalty. SLA should always be looser than SLO — if your SLO is 99.9%, your SLA should be 99.5%, so that hitting SLO gives you an insurance margin against SLA-triggering months. Enterprise contracts often demand SLA credits (10% of monthly fee back for each 0.1% below target); model this into pricing. Never publish an SLA you cannot measure with the same rigor you would apply to a financial number — refund disputes are unpleasant and losing them publicly worse.
Investor directory · Fundraising library · Articles A–Z · Company funding database