<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Slo on F. Latini - IT Engineer</title><link>https://latini.dev/tags/slo/</link><description>Recent content in Slo on F. Latini - IT Engineer</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 23 Jul 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://latini.dev/tags/slo/index.xml" rel="self" type="application/rss+xml"/><item><title>The Error Budget Nobody Spends</title><link>https://latini.dev/posts/the-error-budget-nobody-spends/</link><pubDate>Thu, 23 Jul 2026 08:00:00 +0000</pubDate><guid>https://latini.dev/posts/the-error-budget-nobody-spends/</guid><description>&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; - An SLO without an error budget you actually spend is a number on a wiki, not a reliability practice. The error budget is the whole point: it is a pre-agreed trade between reliability and velocity, decided while everyone is calm, so that when the budget runs out the answer - stop shipping features, fix reliability - is already made. Almost nobody spends it. Teams set a target from ambition instead of user need (often a heroic 100%), measure the wrong thing (host uptime, not the user&amp;rsquo;s journey), page themselves at 3am on the raw threshold, and then blow through the budget without changing a single plan. This is the four moves that turn an SLO from decoration back into a decision, and the honest cases where you don&amp;rsquo;t need one at all.&lt;/p&gt;</description></item></channel></rss>