Hanad KubatVisit Website →
← Back to blog

Two Week Builds: Service Level Objectives for Small Teams

September 11, 2026
Two Week Builds: Service Level Objectives for Small Teams

A service level objective (SLO) is a target value or range for a service level indicator, measured over a defined time window. Its job is to give engineering and business teams a shared, numeric line for "good enough," so that when reliability and shipping speed pull against each other, there's a rule instead of a debate. Percentiles, not averages, are the standard way to measure the indicator behind it.

TL;DR:

  • SLOs should be set based on realistic baselines, with short-term (weekly) windows for faster problem detection and longer (monthly) windows for stability.
  • Target SLIs, such as latency percentiles or availability percentages, must be aligned with user expectations, often requiring segmentation by customer tier or workflow.
  • Error budgets are crucial for operational decisions, with burn rate alerts enabling proactive responses before breaches turn into contractual violations.
  • Monitoring should focus on success/failure markers, latency histograms, and retry counts, integrated into automated pipelines for trustable, real-time SLO tracking.
  • Regular review and documentation of SLOs are essential to adapt to product changes, traffic growth, and evolving customer needs, maintaining their relevance and trustworthiness.
Hanad Kubat
Build Software That Holds Up
For a first real version or internal workflow app, Hanad Kubat builds working software in two to four weeks with fixed scope.
Explore software building

Table of Contents

What Is a Service Level Objective, and How Does It Relate to SLIs and SLAs?

An SLO is the middle piece of a three-part vocabulary that gets mixed up constantly, even by people who use it daily. Here's the clean version.

A service level indicator (SLI) is the raw measurement: the percentage of requests that succeeded, the 95th-percentile response time, the number of failed jobs per hour. Common SLIs cluster around latency, availability, error rate, and throughput, and almost every SLO you'll ever write is built on one of those four.

A service level objective (SLO) is the target you set for that indicator: "99.9% of requests succeed, measured over a rolling 30-day window." It's a target value or range for a service's performance, and it functions as an internal goalpost, not a legal document.

A service level agreement (SLA) is where things get contractual. An SLA is a binding contract between a provider and a customer that spells out what happens when targets are missed, usually service credits or termination rights. The SLO is the internal number that keeps you from breaching the SLA in the first place.

A few examples of how the three stack together:

  • SLI: percentage of API calls returning under 300ms
  • SLO: the majority of API calls return under 300ms, measured weekly
  • SLA clause: "Provider guarantees 95% of API calls complete under 500ms; failure to meet this for two consecutive months entitles the customer to a 10% credit."

Notice the SLA target (500ms) is looser than the internal SLO (300ms). That gap is deliberate. You want operating room between the number you hold yourself to and the number you've promised a customer, because the day you're exactly at your contractual limit is the day a bad deploy turns into a breach and a refund.

How Are SLOs Actually Measured?

Averages lie. That's why SRE guidance settled on percentiles instead of averages: an average smooths outliers into invisibility, and outliers are exactly what users notice.

Pro Tip: If you can only measure one thing, measure your p95 latency instead of your average. It's the single fastest way to catch the "works for me" complaints from users you'll never hear directly.

Here's a practical process for building a measurement you can trust:

  1. Define a valid request. Decide upfront whether synthetic health checks count. They shouldn't, unless tagged separately, because only user-visible traffic should count toward the SLI that represents real experience.
  2. Decide how to treat retries. A request that fails once and succeeds on retry is a different user experience than one that succeeds on the first try. Most teams count the final outcome but log the retry rate as a separate signal, because a rising retry rate often predicts an SLO breach before the SLO itself moves.
  3. Pick your percentile. P95 is the common default for latency; p99 matters more for services where tail latency has outsized business cost, like checkout flows.
  4. Choose your window. A 28-day or 30-day rolling window smooths weekly traffic patterns (weekend dips, Monday spikes) better than a fixed calendar month, and it avoids the "reset to zero on the 1st" problem where a bad week 1 gets forgotten by week 4.
  5. Set your aggregation rule. Decide whether you're aggregating per-request or per-minute-bucket before computing the percentile. This matters more than people expect; bucket-then-percentile and request-then-percentile can produce different numbers on the same data.

Weekly windows react faster to regressions, which is good for catching problems and bad for stability, since a single rough day can tank a week's number. Monthly windows are calmer but slower to flag a trend. Most teams that start with SLOs pick monthly, then tighten to rolling 28-day windows once they trust their data.

How Do You Set SLO Targets and Run an Error Budget?

Setting a target isn't a math problem first. It's a business conversation that happens to end in a number. Skip the conversation and you'll set a number nobody agrees to defend when it matters.

The process, in order:

  • Define the service's purpose. What does this service do for the user, specifically? Not "the API," but "the API that lets a customer check out."
  • Pick a small number of SLIs. Three or four KPIs that answer "is this working?" beats a dashboard with twenty metrics nobody checks.
  • Get a baseline. Measure your current performance for two to four weeks before picking a target. Setting a target you're already missing by 3% is a different conversation than setting one you're already beating.
  • Set the target and window together. "99.9% over 30 days" and "99.9% over 7 days" are not the same commitment; the shorter window is strictly harder to hold.
  • Document the policy. Write down what happens when the error budget runs out, and who has authority to invoke it.

The error budget is just the inverse of your SLO, expressed as allowed failure. Once it's gone, the response is a business decision, not a technical one: freeze feature releases, pull engineers onto reliability work, or accept the risk and keep shipping, with sign-off from whoever owns that risk.

Burn rate policies make this concrete. A common pattern: if you're burning the monthly budget at a rate that would exhaust it in under 6 hours, page someone immediately. If the burn rate would exhaust it in 3 days, open a ticket for the next sprint. The speed of the burn tells you the speed of the response, and coding that into your alerting turns a philosophy into an automated policy.

Getting stakeholders to actually believe in the number is its own skill. Following How to Stabilize SaaS: A Technical Leader's Guide can help frame that conversation around what actually breaks in production, not what looks good in a slide.

How Do You Set SLO Targets and Run an Error Budget? — overview diagram

How Do You Operationalize SLOs in Production?

An SLO that lives in a spreadsheet is a wish, not a system. Getting it into production means instrumenting the right events, automating the math, and wiring alerts to the number that actually matters: how fast you're burning the budget.

What to instrument:

  • Success/failure markers on every user-facing request, tagged with enough context to filter by endpoint or customer tier
  • Latency histograms, not just averages, so percentile math is possible after the fact
  • A count of retries and timeouts, kept separate from the primary success metric

The automation pipeline, step by step:

  1. Collect raw events (success, failure, latency) into a time-series store.
  2. Run a rolling evaluation, nightly at minimum, that recomputes the SLI over your chosen window.
  3. Push that number into a dashboard that shows current status against target, not just historical trend.
  4. Calculate burn rate: how fast the error budget is depleting relative to the time left in the window.
  5. Trigger alerts based on burn rate thresholds, not raw metric breaches, since a single bad minute shouldn't page anyone.

Alerting tied to burn rate rather than the raw SLI cuts down on noise dramatically. Paging someone because latency spiked for 90 seconds during a deploy is how on-call engineers start ignoring pages. Paging someone because the budget will be gone in six hours if the current trend holds is how you catch a real problem before it becomes a customer complaint.

Runbooks matter here more than most teams expect. When an alert fires, whoever's on call needs a documented first step, not a Slack thread reconstructing tribal knowledge at 2 a.m. And SLO status belongs in your release process directly: a release gate that checks "is the error budget healthy" before a deploy ships is a small addition that prevents a lot of "why did we ship on top of an active incident" postmortems. The pattern shows up across production monitoring practices for LLM-backed features just as much as it does for traditional APIs.

What Do Real SLO Examples and Templates Look Like?

Copy these, adjust the numbers to your baseline, and don't skip the baseline step just to hit a round number.

  • Availability SLO: most requests return a successful response, measured over a rolling 30-day window, excluding scheduled maintenance windows communicated in advance.
  • Latency SLO: the majority of requests complete in under 400ms, measured over a rolling 28-day window, calculated per-request before aggregation.
  • Error rate SLO: a small portion of requests return a 5xx error, measured weekly, counting only valid user-initiated requests.
  • Success-rate SLO for async jobs: the vast majority of background jobs complete successfully within their expected runtime, measured monthly.
  • Time-to-first-byte SLO: most page loads receive their first byte within 200ms, measured over 30 days.

Enterprise customers with higher volume can support tighter windows because the sample size smooths out one-off blips. The framing in SaaS Metrics to Track: A Stage-by-Stage Guide covers how the right metric shifts as a product scales past its earliest customers.

Sample SLA clause built from an internal SLO: "Provider will maintain high monthly uptime, measured as the percentage of five-minute intervals with no reported service interruption. If uptime falls below this threshold in a calendar month, Customer is entitled to a service credit." Note the SLA number sits looser than a plausible internal SLO, which is the buffer discussed earlier.

What Mistakes Should You Avoid, and What Actually Works?

The most common failure is aiming for 100%. It's not just unrealistic, it's actively harmful, because 100% removes any room for the trade-offs error budgets exist to enable and quietly pressures teams to stop shipping altogether.

Mistakes that show up repeatedly:

  • Setting a target before establishing a baseline, so the number is a guess dressed up as a commitment
  • Running fifteen SLOs when three would drive every decision that matters
  • Measuring what's easy to collect instead of what the user actually experiences
  • Ignoring sample size, so a low-traffic endpoint's SLO swings wildly on a handful of bad requests

What holds up over time:

  • Keep the number of SLOs small and defend that smallness against feature creep
  • Get product, support, and engineering to agree on targets before automating anything
  • Automate the evaluation so nobody's manually pulling numbers before a leadership meeting
  • Review targets on a set cadence (quarterly is common) rather than only after an incident

Pro Tip: When a target no longer matches reality, deprecate it in the open. Announce the change, state why, and keep the old target's history visible. A quietly changed SLO destroys the trust that made the original one useful.

Notes From Short Builds and Rescue Projects

For the two- to four-week window I work in, I don't try to build a full SLO program. I pick one availability SLO (simple success ratio) and one latency SLO (p95), instrument success/failure markers plus a latency histogram, and compute burn rate daily instead of weekly, since short projects don't have months to notice a slow drift.

Two-week SLO setup and handover sequence

Before handover, I document who owns each SLO, where the dashboard lives, and which alerts are automated versus manual. That handover checklist matters more than the SLOs themselves; an SLO nobody owns after I leave is just a number that decays into noise within a month.

Why Does Customer Experience Shape Which SLOs You Choose?

The SLO that matters is rarely the one that's easiest to measure. Database query time is trivial to log; whether a customer's checkout completed without a retry is what they actually feel, and it's a much messier thing to instrument.

Start from what a user notices, not what your monitoring stack already exposes. A user doesn't experience "average server response time." They experience "the page took forever" or "it just worked." That's why percentile-based measurement matters so much here: it's the statistical technique that actually maps to individual user experience, rather than smoothing it away.

This is also where SLOs diverge by user segment. A free-tier user tolerating a 2-second page load and a paying enterprise customer expecting sub-500ms are both real, and a single blended SLO across both hides the complaint that's actually costing you revenue. Splitting SLOs by customer tier, or at minimum by the specific workflow a tier depends on, catches problems a blended number buries.

Support tickets are an underused input here. If a metric is green but tickets about slowness keep coming in, the metric is measuring the wrong thing, or measuring the right thing at the wrong percentile. Treat a mismatch between "the dashboard is green" and "the inbox is not" as a signal to redefine the SLI, not to ignore the inbox.

How Do SLOs Fit Into Incident Management and Postmortems?

An SLO breach is one of the cleanest incident triggers available, better than most alerting rules built from raw thresholds, because it's already calibrated to what actually matters to users rather than an arbitrary CPU percentage.

During an incident, error budget burn rate answers a question that raw severity labels can't: how much runway is left before this becomes a contractual problem. A "sev-2" label doesn't tell you that. A burn rate that says "budget exhausted in four hours at this rate" does, and it tells the on-call engineer exactly how urgently to escalate.

Postmortems get sharper when they're anchored to budget impact instead of just duration. It also makes the postmortem's recommendations easier to prioritize: an incident that ate half a budget in minutes deserves a different urgency than one that barely dented it.

The other habit worth building: track how many incidents were caught by burn-rate alerts versus customer complaints. If customers are catching regressions before your alerting does, your SLOs are measuring the wrong thing, or your thresholds are too loose. That ratio, tracked over a few quarters, is one of the more honest signals of whether your SLO program is actually working or just decorative.

What Tools Do Teams Use to Monitor and Visualize SLOs?

Most SLO tooling falls into two categories: general-purpose observability platforms that added SLO tracking as a feature, and time-series databases paired with a dashboarding layer you configure yourself.

The general-purpose category covers full observability suites that combine metrics, logs, and traces with a built-in error-budget view, useful when a team wants one system for everything and doesn't want to hand-build burn rate math. The self-assembled category covers metrics stores paired with visualization layers, where a team writes its own aggregation queries and burn rate alerts on top of raw time-series data. It costs more engineering time upfront but gives full control over exactly how percentiles and windows are calculated, which matters if your definition of a valid request is unusual.

For a small team or a short fixed-price build, the self-assembled route is often the practical choice, not because it's cheaper in absolute terms, but because it avoids locking a two-week project into a platform contract that outlives the build itself. A single dashboard showing current SLO status against target, with a burn rate line, is enough to run on for most early-stage services. Compliance requirements can also shape the choice here: logging and retention requirements under frameworks like SOC 2 affect how long raw event data needs to be retained for audit purposes, which is worth checking before picking a tool with short default retention.

Whatever the tool, the non-negotiable is that the dashboard shows status against target, not just a historical graph. A graph tells you what happened. A status view tells you whether to act.

How Often Should You Review and Refine SLOs?

An SLO set once and never revisited eventually measures the wrong thing for a product that's since changed shape. What made sense at launch, when traffic was light and every user was a design partner, often stops fitting once a product has thousands of users and different customer tiers pulling in different directions.

A quarterly review cadence is common and reasonable for most services: check whether the target still matches user expectations, whether the sample size is large enough to trust the number, and whether the error budget has been consistently underused (a sign the target may be too loose) or consistently exhausted (a sign it's too tight or something structural changed).

Traffic growth is the most common reason a target needs revisiting. The target itself might stay the same number while the confidence behind it changes completely.

Product changes matter just as much. A new checkout flow, a new integration, a new customer segment with different usage patterns, any of these can shift what "good" looks like without anyone deciding to change the SLO on purpose. The review is where that drift gets caught before it becomes a permanently wrong number nobody questions.

Deprecating an SLO deserves the same visibility as creating one. Announce it, state the reason, and keep a record of what the old target was and how long it held, so the history isn't lost the next time someone asks why a target changed.

How Do SLOs Change Culture and Cross-Team Collaboration?

The biggest shift SLOs cause isn't technical. It's that they give engineering and product a shared number to argue about instead of a shared feeling.

Before SLOs, a debate about whether to ship a risky feature or fix a nagging bug usually comes down to whoever argues loudest in the room. After SLOs, it comes down to whether there's error budget left. That reframing takes a lot of the politics out of a decision that used to run entirely on opinion, and it gives quieter voices on a team an actual number to point to instead of a hunch.

It also forces a conversation between departments that often don't talk much: support sees the tickets, engineering sees the metrics, and product sees the roadmap. An SLO breach that consumed half the monthly budget in one incident is a fact all three groups can look at together, rather than three separate narratives about the same outage. That shared language is worth more than the specific percentage chosen for any individual target.

The risk on the other side is treating the SLO as a scoreboard for blame instead of a tool for decisions. A team that gets punished every time the budget runs low will start gaming the metric: narrowing the definition of a valid request, moving traffic to unmeasured endpoints, or quietly loosening targets without review. The whole point of the exercise collapses if the number becomes something to hide from rather than something to act on.

Why Practitioner-First SLOs Beat Textbook SLOs for Small Teams

The standard SRE material is written for organizations with dedicated reliability teams and years of traffic history to baseline against. Most of the founders and technical leads I work with have neither. They have a working prototype, a handful of real users, and a deadline measured in weeks, not quarters.

That's where the conventional advice thins out. Percentiles and error budgets are the right concepts, but the standard rollout, dozens of SLOs across every service boundary, a dedicated review board, a quarterly cadence with formal sign-off, assumes a headcount that doesn't exist yet. Applied to a two-person team, it becomes overhead nobody maintains after the first month.

What actually holds up: one availability number, one latency number, both tied to a burn rate someone actually checks. That's the version I build into every handover, whether it's a rescue rebuild or a first real version shipped from a Figma file. The prototype is the spec, and the SLO is the promise that spec keeps working after I'm gone. Everything more elaborate than that is worth adding later, once there's a team big enough to own it.

— Hanad Kubat

Sources

FAQ

What Are the Objectives of Service Level Management?

Service level management aims to align what a service actually delivers with what the business and its customers expect, using measurable targets to guide trade-offs between reliability work and new feature development.

What Is the Main Objective of a Service Level Agreement?

An SLA's main objective is to formalize a binding commitment between provider and customer about service quality, with defined consequences, like service credits, if that commitment isn't met.

What Do SLA, SLO, and SLI Mean?

An SLI is the raw measurement (like latency or error rate), an SLO is the internal target set for that measurement, and an SLA is the binding contract with a customer that often includes SLOs as clauses.