SLO (service level objective)
A reliability target you commit to, like '99.9% of requests succeed this month', so system health is a number instead of a vibe.
See it
What it is
An SLO is a target you pick and write down: '99.9% of checkout requests succeed over a rolling 28 days', or '95% of page loads finish under 800ms'. It turns 'the site feels flaky' into a number that either holds or does not. Three terms travel together and get mixed up constantly: the SLI is the measurement (percentage of good requests), the SLO is your internal target on that measurement, and the SLA is the contract with a customer that has refunds attached. Miss an SLO and you change priorities. Miss an SLA and finance gets involved.
Reach for one when alerting has become vibes: everything pages, nothing is clearly broken, and no two people agree on whether last Tuesday was bad. Pick a handful of user-visible journeys (sign in, checkout, load the dashboard), define good versus bad for each, then set the target just above the point where users start complaining. The nines are brutally concrete per 30 days: 99% is about 7 hours of failure, 99.9% is about 43 minutes, 99.99% is about 4 minutes.
Gotcha: 100% is the wrong target, always. It costs infinite money, freezes shipping, and ignores that your users already sit behind flaky networks and third-party dependencies you do not control. Also measure the SLI as close to the user as you can, since a server-side average response time can look perfect while every mobile client times out.
Ask AI for it
Define SLOs for this service. Pick the three most user-visible journeys, and for each write an SLI as a good-events over valid-events ratio (availability from HTTP status, latency from a p95 threshold), measured at the edge rather than inside the app. Set targets of 99.9% availability and 95% of requests under 500ms over a rolling 28-day window. Output the definitions as config for the monitoring stack, plus a dashboard showing current SLI, target line, and remaining error budget, and multi-window burn-rate alerts instead of static thresholds.