Glossary

What Is an SLO (Service Level Objective)?

An internal reliability target you set for a metric like uptime — usually stricter than your public SLA.

Definition

A Service Level Objective (SLO) is a specific, measurable reliability target your team commits to internally — for example, "99.95% uptime over a rolling 30 days." It sits between the raw measurement (the SLI) and the customer-facing promise (the SLA).

SLOs are typically set tighter than SLAs to give a safety buffer: if your public SLA is 99.9%, you might run an internal SLO of 99.95% so you have warning before you risk breaching the contract.

Why It Matters

SLOs turn reliability from a vague aspiration into a concrete goal that drives decisions. They define how much risk you can take (your error budget), when to slow down and focus on stability, and when you have room to ship faster. Without an SLO, "reliable enough" is just an opinion.

How It Works

You pick an SLI (such as uptime or success rate), set a target over a window (e.g., 99.95% over 30 days), and measure continuously. The gap between 100% and your SLO is your error budget — the amount of failure you can absorb. Burn through it and you prioritize reliability work; stay under it and you have slack to take risks.

Real-World Example

A team sets an SLO of 99.95% uptime over 30 days, giving an error budget of about 22 minutes per month. Halfway through the month a 15-minute outage uses most of the budget, so the team freezes risky deploys and focuses on stability until the window resets.

Best Practices

  • Set SLOs slightly stricter than your public SLA for a safety buffer
  • Base SLOs on metrics users care about, like uptime and success rate
  • Use the error budget to balance shipping speed against stability
  • Measure SLOs over a rolling window, not a calendar month only
  • Review and adjust SLOs as the product and expectations evolve

Common Mistakes

  • Setting an SLO of 100%, which leaves no room to operate
  • Choosing SLOs that don't reflect real user experience
  • Defining an SLO but never measuring against it
  • Ignoring the error budget when deciding what to ship
  • Confusing the internal SLO with the contractual SLA

In Monitoristic

Monitoristic gives you the measured uptime an SLO needs — regular checks, an uptime percentage, and incident history. Track your monitor's uptime against your chosen target to see whether you're inside your error budget.

Frequently Asked Questions

What is the difference between an SLO and an SLA?
An SLO is an internal reliability target; an SLA is the external, contractual promise (usually looser) with consequences if missed.
What is an error budget?
The error budget is the allowed amount of unreliability — the gap between 100% and your SLO. It tells you how much failure you can absorb before prioritizing stability.
How strict should an SLO be?
Strict enough to protect your SLA but realistic enough to operate. A common pattern is an SLO one step tighter than the SLA, e.g. 99.95% SLO behind a 99.9% SLA.
Do small teams need SLOs?
Even a simple SLO helps. A single uptime target with an error budget gives a small team a clear, shared definition of "reliable enough."

Get started today

Your Sites Deserve Better Monitoring.

Create monitors, connect alerts, and share status pages with your customers. Plans from $5/month.