A service level objective (SLO) is an internal reliability target tied to a measurable service level indicator (SLI). For a small cloud application, SLOs turn vague goals such as "keep it reliable" into explicit decisions about availability, latency, errors, and recovery.
Raff Technologies infrastructure can provide the compute, networking, storage, database, and recovery primitives behind a service, but the application team still defines what users experience and which failures matter.
A practical SLO system has four parts:
user expectation → SLI → target → error budget / action
This guide is the LC13 reliability-target connector. It focuses on the smallest useful SLO model for small teams rather than enterprise SRE ceremony.
Start with the user-visible outcome
Do not begin with every metric you can collect.
Start with a question such as:
- Can users reach the service?
- Are requests fast enough?
- Are critical actions succeeding?
- Is data fresh enough?
- Are scheduled jobs completing on time?
Then choose an SLI that measures that outcome.
Examples:
| User expectation | SLI |
|---|---|
| API is reachable | successful eligible requests / total eligible requests |
| API is fast enough | percentage of requests below latency threshold |
| Jobs complete | successful jobs / attempted jobs |
| Data is fresh | percentage of records within freshness threshold |
SLI, SLO, SLA, and error budget are different
SLI is the measured indicator.
SLO is the target for that indicator over a defined window.
SLA is a formal service commitment that may include remedies or commercial terms.
Error budget is the amount of unreliability permitted by the SLO.
Example:
SLI: successful HTTP requests SLO: 99.9% success over 30 days Error budget: 0.1% failed eligible requests
Do not treat Raff's provider SLA as the same thing as your application's SLO. Your application can fail even when the VM is available, and provider infrastructure can be only one dependency in the user path.
Choose one or two critical SLIs first
Small teams should resist building a large reliability program before they can maintain it.
A useful starting set is often:
- availability or success rate;
- latency for a critical user path.
Add data freshness, job completion, queue age, or another workload-specific SLI only when it represents a meaningful user outcome.
Avoid vanity metrics such as CPU utilization as an SLO. CPU can explain a failure, but users do not directly consume CPU percentage.
Define the measurement population
Every SLO needs a denominator.
For an HTTP success-rate SLO, decide:
- which endpoints count;
- whether health checks are excluded;
- whether 4xx responses count as failures;
- whether maintenance windows are excluded;
- which regions or customer cohorts are included.
Without a defined population, two dashboards can calculate "availability" differently and both look correct.
Define the measurement window
Common windows include 7, 28, or 30 days.
The right window depends on how quickly the team needs to react and how the service is used.
A 30-day window is easy to communicate, while shorter rolling windows expose deterioration sooner.
Do not reset the measurement window whenever a release goes badly. The point is to preserve a consistent reliability signal.
Turn the target into an error budget
If an SLO permits 0.1% failure, that permitted unreliability is the error budget.
For a request-based SLO:
error budget = total eligible requests × allowed failure fraction
For an availability-time approximation, 99.9% availability over a 30-day month corresponds to roughly 43 minutes of unavailable time. Actual request-based SLO calculations can differ because user traffic is not uniform.
The error budget helps answer:
Are we consuming reliability faster than we intended?
Use burn rate instead of waiting for the month to end
A team should not discover on day 30 that the entire error budget was exhausted on day 3.
Burn rate compares actual error consumption with the rate that would use the budget evenly.
A high burn rate means the service is consuming reliability much faster than planned.
Use burn-rate alerts when enough data exists to make them meaningful.
Connect SLOs to deployment decisions
An SLO is useful only when it changes behavior.
Examples:
- pause risky releases when error budget is nearly exhausted;
- prioritize a recurring reliability defect;
- increase capacity after latency SLO breaches;
- improve rollback or recovery after repeated deployment-related failures;
- reduce alert noise if pages do not correspond to SLO risk.
Do not use SLOs as a performance score for individuals.
When an error-budget threshold requires a rollback or other operational action, define the responsible owner, decision trigger, and verification steps in a Cloud Runbook.
Synthetic monitoring and internal metrics answer different questions
Internal metrics can show:
- CPU pressure;
- application errors;
- queue backlog;
- database latency.
Synthetic monitoring can show whether a user-facing path works from outside the application.
Both are valuable.
The Application Observability for Small Teams guide explains how to collect and correlate the metrics, logs, and traces needed to evaluate those reliability signals.
For availability, an external synthetic check can be closer to user truth than a process-level "service running" check.
Use Server Health Checks Explained for the health-check boundary.
SLOs do not replace incident response
An SLO tells you whether reliability is within target.
It does not tell you how to contain or recover from an incident.
When a serious incident occurs, use the Incident Response Plan for Small Teams.
After the incident, use SLO/error-budget behavior to decide whether the event requires architectural or process changes.
Keep the first SLO review lightweight
A small team can review reliability weekly or biweekly.
Review:
- current SLI;
- SLO target;
- error-budget remaining;
- major incidents;
- recurring failure modes;
- changes in latency/error distribution;
- whether alerts still map to user impact.
If the review produces no decisions for months, the SLO may be poorly chosen or unnecessary.
Example: small SaaS API
Suppose a SaaS API defines:
SLI: successful requests / eligible requests SLO: 99.9% over rolling 30 days Latency SLI: requests completed under 500 ms Latency SLO: 99% under 500 ms over rolling 30 days
The team then monitors:
- request success;
- latency distribution;
- synthetic availability;
- dependency health;
- error-budget burn.
If a deployment causes a sustained error spike, the release can be rolled back before the full monthly budget is consumed.
A Raff Cloud VM can host an application's runtime and monitoring agents, but the application team remains responsible for defining, measuring, and acting on its SLOs; a VM purchase is not an application reliability guarantee.
SLO checklist
Before adopting an SLO:
- user outcome is explicit;
- SLI is measurable;
- eligible traffic is defined;
- target is achievable but meaningful;
- measurement window is fixed;
- data source is trustworthy;
- maintenance/exclusions are documented;
- error budget is visible;
- the team knows what action follows a breach;
- the SLO is reviewed on a defined cadence.
Frequently asked questions
What is an SLO?
An SLO is a measurable reliability target for a service, such as a request success rate or latency target over a defined period.
What is an SLI?
An SLI is the actual measurement used to evaluate reliability, such as successful requests divided by eligible requests.
What is an error budget?
An error budget is the amount of unreliability permitted by the SLO over its measurement window.
Is an SLO the same as an SLA?
No. An SLO is an internal reliability target. An SLA is a service commitment that may include contractual or commercial terms.
Do small teams need SLOs?
Not every service needs a formal SLO. They are useful when reliability trade-offs, release risk, or recurring incidents require a shared measurable target.
Should CPU or memory be an SLO?
Usually no. CPU and memory are diagnostic infrastructure metrics, while SLOs should normally represent user-visible outcomes.
