Most Site Reliability Engineering literature targets large organizations — Google, Netflix, enterprise platforms. Small teams often look at it and think “nice ideas, we don’t have capacity.” This article is about the SRE subset that a 10-engineer team can actually adopt, and which parts of the canon to skip.
What matters most
Prioritized for small teams:
- Service-level objectives — define what “healthy” means
- Monitoring on user-facing signals — know when users are affected
- Blameless incident review — learn from each outage
- Runbook per service — new on-call isn’t helpless
- Deploy safety — fast rollback, canary, feature flags
Each of these costs relatively little engineering time and prevents large amounts of pain. The rest of SRE (error budgets as product gates, toil reduction programs, dedicated SRE teams) can come later.
SLOs without ceremony
You don’t need a formal SLO document approved by three committees. A team channel post is enough:
Service: orders-api SLO: 99.5% of requests under 300ms p95 (weekly rolling) Error budget: 0.5% = ~3 hours of budget per week If budget burns, we pause feature work and fix reliability.
Track it on a dashboard. Use it as a decision tool. That’s the entire thing.
The hard part isn’t writing the SLO; it’s actually respecting it. When the budget runs out, feature work really does pause. That’s the social contract.
Monitoring that doesn’t waste on-call
Four types of alerts:
- Page-worthy — user-impacting issue, now. Response < 5 min.
- Ticket-worthy — concern, investigate in business hours.
- FYI — logged for context, no action.
- Garbage — delete these.
Most teams start with 80% garbage alerts. Tuning down (disabling, tuning thresholds, consolidating) is one of the highest-leverage activities.
For a small team: aim for fewer than 5 pages per week, total. More than that = alert fatigue.
The minimum viable alert set:
- Service is down (health check fails for N consecutive minutes)
- Error rate elevated (5xx rate > threshold for N minutes)
- Latency elevated (p99 > threshold for N minutes)
- Critical dependency errors (DB, Kafka, external APIs)
Four alerts per service cover 80% of the value.
On-call rotation
Even 3 engineers can rotate. One week each. Hand off on Mondays.
Rules:
- Pager works and is tested weekly
- Secondary on-call for if primary is unreachable
- Runbooks are in a known location
- Deploy window closes 2 hours before workday end
On-call pay or comp time matters more than people admit. Without it, on-call becomes a resentment source.
Runbooks that get used
Not “how to architect this service” — too generic. Not “run this specific command” — too brittle. Runbooks are decision trees:
If service is returning 503:
→ Check database connection pool metric
→ If saturated: follow 'pool saturated' playbook
→ If not: check downstream service health
→ If downstream unhealthy: ...Concrete dashboard links, concrete commands, concrete decision points. Written for 3 AM consumption — no context assumed.
Every incident updates the runbook with what was learned. Over time, the runbook becomes invaluable.
Deploy safety on a budget
Full canary with SLO-based automated rollback is expensive. A budget version:
- Deploy to staging, automated smoke tests run
- Deploy to production 1 node at a time
- Watch error rate dashboard during rollout
- Manual decision to proceed or roll back
- Feature flag any risky behavior for kill-switch
Not as sophisticated as a proper canary system, but captures 80% of the protection at 5% of the infrastructure cost.
The one investment worth making: one-click rollback. If your deploy pipeline can’t roll back in under a minute, build that first before anything else.
Error budget as a soft gate
In large orgs, error budgets are strict gates with automation. For small teams, they’re a prompt for a conversation:
“We’ve burned 80% of our weekly error budget. Do we keep shipping features or stabilize?”
The answer isn’t always “stabilize” — sometimes the feature is more important. But the question gets asked deliberately, and that’s the value.
Toil reduction
Big SRE orgs measure toil (manual, repetitive operational work) and have programs to eliminate it. Small teams don’t need programs; they need the habit.
Rule: if you did it twice manually this week, automate it by end of next week. Restarting a stuck consumer, cleaning up old logs, rotating credentials — automate away.
Over a year, this compounds into significant reclaimed time.
Capacity planning, simplified
Full capacity planning involves load testing at regular intervals, growth projections, and multi-month infrastructure plans. Small teams can get 80% of the value with:
- Quarterly load test at 2× current peak
- Monthly review of resource utilization trends
- 30-50% headroom on every critical service
- Plan infrastructure upgrades 2 months before you run out
Anything more sophisticated can wait until growth demands it.
What to skip (for now)
Things large-org SRE does that small teams probably shouldn’t:
- Dedicated SRE team. Small teams can’t spare the headcount; reliability is everyone’s job.
- Formal service maturity reviews. Heavy process for small portfolios.
- Multiple on-call tiers. One tier is enough until you have 24/7 follow-the-sun coverage.
- Custom observability stack. Use a managed provider (Grafana Cloud, Datadog) until volume forces a build.
- Complex deploy orchestration. Simpler is better until scale demands more.
The payoff curve
At team size 10:
- 4 hours per week on SRE practices (postmortems, runbook updates, alert tuning)
- Roughly prevents 1-2 outages per quarter
- Engineer sleep preserved
- Confidence to ship new features grows
Return on investment: significant, starting in the second month. The key is consistency — sporadic SRE investment underperforms.
Closing note
SRE is a mindset more than a toolkit. The big companies have the toolkit because they have the scale; small teams can run the mindset on much less. Define SLOs. Alert on user impact. Review incidents blamelessly. Keep runbooks current. Ship safely. Do those five things and most of the benefit of SRE is yours — without the 500-page book becoming a liability. The rest can wait until the team doubles in size.