The SRE Launch Checklist: SLOs, Error Budgets, and On-Call from Day One

The day you launch a real service, you become an SRE — whether you have the title or not. Things will break at 3am, users will notice before you do, and "we'll figure out monitoring later" stops being acceptable.

The good news: you don't need a 50-person platform team to run production responsibly. You need three things, set up on day one: SLOs, error budgets, and an on-call rotation (even if it's a rotation of one).

Here's the pragmatic version.

1. Define one SLO (not ten)

An SLO (Service Level Objective) is a promise to your users about reliability, expressed as a measurable target. The classic example: "99.9% of requests succeed within 500ms, measured over a 30-day window."

That single sentence does more for your reliability than any monitoring tool. It forces you to decide what "good" means, measure it, and act when you're falling short.

How to pick your first SLO

Start with one. Don't define ten SLOs on day one — you won't have the observability to measure them, and you'll ignore all ten. Pick the one that, if broken, would make users leave:

• For an API: availability (success rate of non-4xx requests) or latency (p99 under Xms).
• For a web app: page load time (LCP under 2.5s) or error rate (no more than 0.1% of sessions hit a 500).
• For a job processor: freshness (most recent job completed within X minutes).

99.9% (about 43 minutes of downtime per month) is a reasonable starting point for most small services. Don't promise 99.99% (4.5 min/month) unless you have the engineering capacity to honor it.

The 30-day rolling window

Measure your SLO over a 30-day rolling window, not a calendar month. A rolling window means your reliability score always reflects recent reality, not a stale number that resets on the 1st. Most observability tools (Prometheus, Datadog, Vercel Analytics) support this natively.

2. Track your error budget

This is the part that makes SLOs actually useful. Your error budget is the slack implied by your SLO:

SLO: 99.9% available over 30 days
30 days = 43,200 minutes
Error budget = 0.1% × 43,200 = 43.2 minutes of allowed downtime per month

You "spend" your error budget when things break. A 10-minute outage spends 10 minutes of budget. A slow rollout that causes 500ms latency spikes for 20 minutes spends budget too (if your SLO includes latency).

What the error budget tells you

• Budget remaining → ship fast. If you've burned only 5 of your 43 minutes this month, you have headroom. Ship the risky refactor, do the migration, take a little risk.
• Budget depleted → freeze. If you've burned 40 of 43 minutes, stop shipping new features. Focus on reliability. A team that ignores a depleted budget is a team that will miss next month's SLO too.
• Budget consistently over-spent → your SLO is wrong. If you blow through 43 minutes every week, either your reliability is genuinely bad (fix it) or your SLO is too aggressive (renegotiate it with users).

The error budget turns reliability from a vibe ("things feel stable") into a number you can act on.

3. Set up on-call (even solo)

On-call means someone is responsible for responding when things break. For a solo founder, that's you — but you can still do it responsibly:

The minimum viable on-call setup

1. A paging channel. One place where alerts go: PagerDuty (free tier), Opsgenie (free tier), or even a dedicated Slack channel with a webhook that texts you. Don't rely on email — you won't see it at 3am.
2. A small number of real alerts. Not "CPU > 80%." Only alerts that mean "users are being affected right now": 5xx error rate spike, SLO burn rate exceeding 2x normal, a critical health check failing for >2 minutes. Ten good alerts beat a hundred noisy ones.
3. A runbook for each alert. When the alert fires at 3am, the person paged should open a doc that says: what this alert means, how to check if it's real, the first three things to try, and who to escalate to. A runbook you haven't written yet is a 3am panic waiting to happen.
4. A postmortem process. Every page that turned out to be real gets a blameless postmortem within a week: what happened, why, what we'll change to prevent it. Without postmortems, you page the same alert at 3am every month.

The solo-founder reality

If you're solo, you can't do 24/7 on-call sustainably. Be honest with users: define your support hours (e.g., "we respond to critical issues within 4 hours during business hours, next-day otherwise"), set your paging rules to match, and put it in your status page. Users respect honesty more than fake 24/7 promises that don't get honored.

4. Build a status page

A status page — even a simple one — does three things:

1. It tells users when you're down. Before they open a support ticket or tweet angrily.
2. It forces you to communicate during incidents. Writing "investigating elevated 5xx errors" at 3:15am is painful but reduces user anger by 80%.
3. It creates a public history. Over time, your status page becomes evidence of your reliability (or lack of it).

Free options: Atlassian Statuspage (free tier), Cachet (self-hosted), or a static page on your own site updated manually. The manual approach is fine early on — you won't have enough incidents to justify automation.

5. Instrument before you need it

The worst time to add monitoring is during an incident. Add it before launch:

• Metrics: request rate, error rate, latency (p50, p95, p99) for every endpoint.
• Logs: structured JSON, with a request ID on every log line so you can trace a single request end-to-end.
• Traces: distributed tracing (OpenTelemetry, Honeycomb, Datadog APM) so you can see where time goes across services.
• Error tracking: Sentry or similar, so uncaught exceptions get reported with stack traces automatically.

You don't need all of these on day one. But you need at least metrics + error tracking before you have real users. Logs and traces come when you have the complexity to justify them.

What you don't need (yet)

• A dedicated SRE hire. You need this when reliability becomes a full-time job — usually around 20-50 engineers.
• A formal incident command process (IC, comms, ops roles). Needed at ~50+ engineers; before that, "the person paged fixes it and writes a postmortem" is fine.
• Chaos engineering. Fun and valuable at scale, but premature when you don't even have an SLO yet.
• A 24/7 NOC. If anyone suggests this for a small team, say no.

The day-one checklist

Before you launch anything real users will touch:

1. One SLO defined (availability or latency, 99.9%, 30-day window).
2. Error budget being tracked (even as a dashboard widget).
3. Paging set up for critical alerts (PagerDuty/Opsgenie free tier).
4. Runbook written for each alert.
5. Status page live (even if it just says "all systems operational").
6. Error tracking installed (Sentry free tier).
7. Basic metrics dashboard (request rate, error rate, latency).

That's the SRE launch checklist. It's not a 200-person platform org — it's the minimum to ship responsibly and sleep through most nights.

Run the ShipReady Observability & Operations checklist to make sure you haven't missed anything stack-specific.