SLO

A Service Level Objective (SLO) is an internal reliability target for a user-visible behavior, expressed as a percentage or threshold over a rolling window. It is measured with Service Level Indicators (SLIs)—metrics that proxy user experience.

| Example SLI | SLO target | |-------------|------------| | Successful HTTP requests / total | 99.9% over 30 days | | Checkout completions / attempts | 99.5% over 7 days | | p95 API latency < 300ms | 99% of hours |

					error budget = 1 - SLO  →  0.1% downtime/month for 99.9%
				

Alert on **burn rate**—how fast you consume error budget—not on every blip. Multi-window alerts catch fast burns and slow leaks.

On interviews: picking SLIs for a BFF, window length trade-offs, and difference between infrastructure uptime and user-perceived availability.

Common pitfalls: SLO on CPU instead of user outcomes; too many SLOs nobody owns; alerting on SLI noise without `for` windows.

The trade-off is ambitious targets (tight budgets) versus shipping velocity and on-call load.

Checklist:

• Choose SLIs users feel.
• Write SLOs with explicit windows.
• Alert on budget burn, not raw spikes.
• Review SLOs quarterly with product.