Any project eventually hits the question: "How reliably does everything actually work?" Development shows charts, the business demands guarantees, and contracts keep surfacing three eerily similar IT metrics: SLI, SLO, and SLA.
Let's break down how they differ and how they relate to each other.

SLI
A pure fact on a chart — no emotions, no judgments, no blame. It's simply an objective sensor of the system's state at a given moment.
Example: "95% of requests over the last hour were served within 180 ms." It helps instantly shut down pointless arguments like "everything's slow for us" and lets you lean on a rock‑solid number.

SLO
Our internal quality bar, which the team sets for itself (not something promised to the client). It's a benchmark that helps you notice system degradation in time.
Example: "We want 99.9% of requests to complete in under 200 ms." If metrics fall below these standards, developers deliberately slow down the release of new features and go fix things in the code.

SLA
An official contract with the business or client, which specifies real financial liability for outages.
Example: "We guarantee 99.5% availability, otherwise we refund the subscription fee." A wise rule: always make the SLA softer than the internal SLO. This small safety margin saves the team from penalties during local incidents.