Uday defines SRE SLIs and MTTR
- Uday’s X explainer walked through core SRE terms — SLI, SLO, toil, and MTTR — as a practical system for running production services. - The key move was narrowing measurement to a few user-facing SLIs, then using SLOs and MTTR to decide what deserves attention. - That matters because Google’s SRE guidance treats noisy alerts and manual toil as anti-patterns, not proof of rigor.
Site reliability engineering is basically the practice of deciding what “reliable” means before production makes that decision for you. Uday’s post is useful because it strips the jargon down to four terms teams actually use — SLI, SLO, toil, and MTTR. That sounds basic, but turns out this is where a lot of teams get lost. They collect dashboards, page on every wobble, and still can’t say whether users are actually having a bad day. ### What’s an SLI, really? An SLI is just a measurement of user experience. Not “CPU is high.” Not “pods restarted.” More like successful request rate, latency seen by users, or data freshness in a pipeline. Google’s SRE material makes the point pretty clearly — the indicator should describe the thing users care about, not every internal signal engineers can collect. ### Then what does the SLO do? The SLO is the target for that measurement. If the SLI is “99.95% of requests succeed,” the SLO says how good is good enough over a defined window — say four weeks. That matters because SLOs turn reliability from vibes into a policy. They give teams a line for deciding whether to ship faster, slow down, or spend time fixing the system. ### Why not measure everything? Because more metrics usually means more noise, not more clarity. Google’s workbook pushes teams to start with a small number of meaningful indicators and refine them over time. If you alert on every internal symptom, you train people to ignore alerts. If you alert on SLO-relevant symptoms, you’re much closer. That’s the practical heart of Uday’s framing. ### Where does toil fit in? Toil is the repetitive, manual, operational work that keeps a service running but creates no lasting improvement. Think recurring restarts, copy-paste mitigations, hand-run cleanup jobs, or the same incident triage every week. Google’s SRE book is blunt here — toil scales linearly with service growth, which means it eats teams alive if nobody automates it away. ### Why is toil such a big deal? Because toil steals engineering time from the work that would prevent the next incident. A team buried in repetitive ops can look busy and still be getting less reliable. That’s the trap. Reliability maturity is not “humans heroically touching production all day.” It’s building systems, automation, and guardrails so humans intervene less often. ### And MTTR — why do people care so much? MTTR is mean time to resolution or recovery — the average time it takes to get from incident to restored service. It matters because even if failures are inevitable, long recoveries are optional. A lower MTTR usually means detection is faster, ownership is clearer, and recovery steps are better. Don’t average blindly — MTTR is useful when it drives better response design, not when it becomes a vanity KPI. ### So how do these pieces connect? They form a loop. Pick a few user-facing SLIs. Set SLOs that reflect acceptable performance. Alert when those objectives are genuinely at risk. Track MTTR when incidents happen. Then look for toil in the response and automate it away. That is a much cleaner operating model than drowning in dashboards and calling it observability. ### What’s the bottom line? Uday’s explainer lands because it treats SRE as a decision system, not a glossary. Measure what users feel. Set targets you can defend. Cut repetitive work. Recover faster when things break. Everything else is secondary.
