Service Reliability Template for Agile Teams

Start with your users, not an arbitrary number. Look at current performance baselines, contractual obligations (SLAs), and the cost of each additional nine. Going from 99.9% to 99.99% typically requires redundant infrastructure, automated failover, and a dedicated on-call rotation. If your users are internal teams with tolerance for brief outages, 99.9% may be sufficient. If you process payments or health data, 99.99% or higher is the starting point.

An SLO is an internal target your team sets and measures against. An SLA is an external contract with customers that carries financial penalties when breached. Your SLOs should always be stricter than your SLAs, giving you a buffer before you are in contractual violation. The [Technical PM Handbook](/technical-pm-guide) explains how PMs negotiate SLAs with customers and translate them into engineering SLOs.

Monthly for new services, quarterly for mature ones. Review the error budget burn rate, any incidents that occurred, and whether the targets still match user expectations. If you are consistently using less than 10% of your error budget, your SLOs may be too loose. If you are burning through the budget every month, either tighten your reliability practices or relax the target.

The standard practice is a feature freeze. All engineering effort shifts from new features to reliability work: fixing the root causes that burned through the budget. This only works if leadership supports it. The PM and engineering lead must agree upfront that error budget exhaustion triggers a freeze. Without that agreement, the policy is meaningless.

Frame reliability in business terms, not engineering terms. Calculate the revenue impact of downtime, the customer churn risk from repeated incidents, and the engineering time spent on firefighting versus building features. Use the [RICE calculator](/tools/rice-calculator) to score reliability improvements alongside feature work so leadership can compare them on equal terms. ---