SLO / Error Budget Burn Rate Simulator

Reliability is not free and it is not binary. An SLO declares the success rate a service promises its users (say 99.9%), and the error budget is the small slice of allowed failure left over (0.1%). As long as errors stay inside that budget, teams can keep shipping; when the budget burns too fast, new deployments pause until the system recovers.

Mental Model

Reliability is not a binary state, and a system does not need to be 100% perfect to satisfy users.

• SLI (Service Level Indicator): The raw metric showing what percentage of queries succeeded (e.g., Good Requests / Total Requests).
• SLO (Service Level Objective): The target reliability target (e.g., 99.9% success rate).
• Error Budget: The allowed margin of failure over a rolling window, calculated as 100% - SLO. For a 99.9% SLO, your budget is 0.1% of all requests.

The error budget acts as a token system. When errors occur, you “spend” tokens. Uptime burns the budget when the actual error rate exceeds the allowed rate, and you reclaim budget tokens as old errors roll out of the 30-day window. SREs monitor the Burn Rate—the speed at which the budget is depleted—to determine whether to page on-call engineers or pause code deployments.

Components and Why They Exist

Users

This component exists to generate request traffic profiles, feeding telemetry monitoring pipelines. It generates varying volumes of query traffic, including successful operations and error events. In the demo, observe request particle colors (green for successes, red for errors) flowing to the application.

App Service

This component exists to run queries and emit raw Service Level Indicator (SLI) telemetry logs. It processes client operations and reports success-to-failure counts to the monitoring agent. In the demo, watch node color changes reflecting service state and error outputs.

SRE Monitor

This component exists to calculate rolling budget values, track burn rates, and page engineers when outages occur. It aggregates SLI data, manages the rolling 30-day budget battery, and fires alerts. In the demo, watch the live budget battery gauge draining as burn rates spike, and check alert badges.

Edge Cases and Misconceptions

• 100% is the wrong target: Setting an SLO of 100% means you have an error budget of 0%. Under this rule, a single network packet drop or hardware tick would trigger an immediate deployment block, stalling feature development indefinitely for no user benefit.
• Rolling window lag: Error budgets are calculated over a rolling window (typically 30 days). If you have a severe outage that burns 90% of your budget in 1 hour, that outage will continue to deplete your error budget for the next 29 days, even if your service is perfectly healthy after the first hour. It only disappears once the day of the outage rolls out of the window.
• Burn rate vs error rate: A service can have a low error rate (e.g., 0.5% errors) that looks safe, but if the SLO is 99.9% (allowed error rate of 0.1%), a 0.5% error rate is a 5x burn rate. If sustained, it will exhaust the entire budget in just 6 days, making it a critical slow burn that requires alert paging.
• Noisy traffic inflation: Uptime budgets are based on request count, not time. If your request rate drops (e.g., during off-hours), a low number of errors will represent a high percentage of total requests, inflating the SLI error rate and triggering false alarms if alerts ignore traffic volume.