Most early-stage teams think SLOs are a luxury they’ll get to after Series B. They’re not. They’re the cheapest reliability decision you can make, and skipping them is why your team argues about whether an incident was “actually a big deal” instead of knowing.
An SLO is not a ceremony. It’s a number that ends an argument. Without one, every outage becomes a debate about whether it mattered — and those debates are won by whoever is loudest or most senior, not by whoever is right.
SLIs, SLOs and Error Budgets Without the Jargon
Three terms, plainly:
- SLI (Service Level Indicator): a metric that measures something a user actually feels. Request latency. Error rate. Availability of your checkout endpoint. Not CPU. Not memory. Things a customer would notice.
- SLO (Service Level Objective): the target you commit to for that SLI. “99.5% of API requests succeed” or “95% of requests return in under 400ms over a rolling 28 days.”
- Error budget: the inverse of your SLO. If your target is 99.5% success, your budget is 0.5% failure. That budget is a resource. You get to spend it — on risky deploys, on experiments, on moving fast — until it runs out.
The error budget is the part that changes behaviour. An SLO on its own is a wish. An error budget is a bank account. When it’s full, ship fast. When it’s empty, stop shipping features and fix reliability. The number decides, not the loudest person in the standup.
Why Early-Stage Teams Get This Wrong
The two failure modes are opposite, and teams manage to hit both at once.
Setting no SLOs at all. Reliability becomes vibes. “The site felt slow last week.” “Was that outage bad?” Nobody knows, because nobody defined “bad” in advance. You react to whoever complains loudest — usually your biggest customer, which means your reliability priorities are set by your sales pipeline instead of your users.
Setting SLOs at 99.99%. The other trap: copying a target from a hyperscaler’s blog post. Four nines means roughly 52 minutes of downtime per year. At five engineers with no on-call maturity, you cannot hold that, and pretending you can just means you’re always “failing” your SLO, which trains everyone to ignore it. An SLO you constantly breach is worse than no SLO — it’s a broken smoke alarm.
The right early-stage target is usually 99.5% to 99.9%. That is honest. It gives you room to move fast, and it’s a number you can actually defend to a customer.
Pick Three SLIs. That’s It.
Do not instrument everything. For most early-stage products, three indicators cover the reality:
- Availability — the percentage of requests to your core endpoint that don’t fail. This is your “is the product up” number.
- Latency — the percentage of requests served under a threshold users notice. Measure a percentile (p95 or p99), never an average. Averages hide the pain; a p99 of two seconds means one in a hundred users is having a bad time, and that user is on Twitter about it.
- Correctness of one critical flow — the thing that makes you money or keeps you compliant. Checkout. Sign-up. The webhook that has to fire. Pick the one flow where a silent failure costs you the most, and measure whether it completes.
Three SLIs you watch and act on beat thirty dashboards nobody reads. Telemetry without judgment is just expensive noise — the goal is decisions, not graphs.
The SLO Only Works If Something Happens When You Breach It
This is where SLOs die in most companies. The number gets set in a Notion doc, and then nothing is ever wired to it. No alert. No review. No consequence. It becomes documentation of an intention, not a control on behaviour.
A working SLO has three things attached:
- An alert on burn rate, not on the raw metric. You don’t want a page every time a single request fails. You want a page when you’re consuming your error budget fast enough to blow through it before the window resets. Burn-rate alerting is the difference between an actionable page and 2,000 alerts a week where only 3% matter.
- A monthly review of budget spend. Did you have budget left, or did you overspend? If you’re always at zero, either your target is wrong or your reliability work is underfunded. If you’re always at 100%, your SLO is too loose and you could be moving faster.
- A rule for what happens when the budget is gone. The classic version: freeze feature work, redirect to reliability, until you’re back in budget. You don’t have to be dogmatic about it. But you do need a default that isn’t “argue about it each time.”
What This Looks Like When You Don’t Have an SRE
Here’s the honest problem. Everything above assumes someone owns the SLO — someone who tunes the burn-rate alerts as the system changes, runs the monthly review, and has the standing to say “the budget’s gone, we’re not shipping the feature this week.” At five or fifteen engineers, that person doesn’t exist. The founder does it until they don’t, and then the SLO quietly rots.
SLOs are not a one-time setup. They drift the moment your architecture changes — a new service, a new dependency, a traffic pattern shift, and last month’s thresholds are noise. Maintaining them is a continuous function, which is exactly the kind of work that falls through the cracks on a small team because it’s nobody’s job in particular.
Start Small, But Start
You do not need a reliability platform or a dedicated team to begin. Pick your one most important endpoint. Set an availability SLO of 99.5% and a latency SLO on p95. Wire one burn-rate alert. Review it once a month. That’s a complete, working SLO practice, and it’s more than most Series A companies have.
The point of an SLO isn’t to hit a number. It’s to make reliability a decision you make on purpose, with a budget, instead of a thing that happens to you at 3 AM.
Vigil by IOanyT owns the SLO loop for you — we define the indicators that map to your users, wire burn-rate alerting that pages on signal not noise, and run the budget review so reliability stays a decision instead of a debate.
Your engineers ship. We own the number.
