Calculating downtime for a 99.9% SLO

WHAT THIS TESTS: Whether you can both do the math and translate it into operational behavior. Many candidates can recite SLO definitions but cannot connect a number to a deployment decision, which is the point.

A GOOD ANSWER COVERS: The calculation first. A 30-day window contains 30 times 24 times 60, which is 43,200 minutes. A 99.9% availability SLO allows 0.1% unavailability, so the error budget is 0.001 times 43,200, which is about 43 minutes of permitted downtime over those 30 days. (For reference, 99.99% would allow roughly 4.3 minutes and 99% would allow about 432 minutes.) Then the application: the error budget is a quantified, shared allowance for unreliability spent by incidents, bad deploys, and risky changes. When most of the budget remains, the team can deploy frequently and try riskier changes because there is room to absorb mistakes. As the budget drains, the team should slow deploys, add more canarying and review, and prioritize reliability work; if it is exhausted, an error budget policy may freeze feature launches. This reframes reliability versus velocity from a debate into a data-driven decision.

COMMON WRONG ANSWERS: Confusing 99.9% with 99% or 99.99% and quoting the wrong minutes. Computing the number correctly but failing to explain how it changes deployment cadence, treating the budget as a vanity metric.

LIKELY FOLLOW-UPS: How would the answer change for a 99.99% SLO? Should you spend a healthy budget deliberately, for example with chaos testing? How do you measure availability for a service with no clean up/down signal?

ONE CONCRETE EXAMPLE: Mid-month a bad deploy causes a 30-minute outage, consuming most of the 43-minute budget. The team responds by halting further risky launches, switching to canary-only deploys, and focusing on the rollback gap that let the outage run so long, rather than continuing to ship features.