Handling planned maintenance in SLOs and error budgets

WHAT THIS TESTS This probes whether you can reason honestly about what counts against reliability, balancing fairness to the team against fidelity to the user experience.

A GOOD ANSWER COVERS The central tension is that users experience an outage the same way whether it was planned or not, so the question is whether planned downtime should consume the error budget. The first approach charges maintenance to the error budget like any other unavailability. This is the most honest from the user's perspective and creates strong pressure to adopt zero-downtime techniques such as rolling deploys, draining connections, and live migrations, but it can unfairly penalize a team that must take necessary, well-communicated maintenance. The second approach formally excludes maintenance through pre-agreed, announced maintenance windows that are not counted against the SLI, often by serving a clear maintenance response or routing affected traffic out of the SLI. This is fairer to operators and matches contracts that exclude scheduled windows, but it risks masking genuine user pain if windows are frequent, long, or used to dodge accountability. A balanced practice is to design for zero-downtime so maintenance rarely affects users at all, and only fall back to excluded windows when unavoidable, with clear communication.

COMMON WRONG ANSWERS Silently exempting downtime with no documented policy or stakeholder agreement, which erodes trust. Or rigidly counting everything against the budget without offering teams a path to do safe maintenance, discouraging necessary upkeep.

LIKELY FOLLOW-UPS How do contracts typically treat maintenance windows? How do you measure whether maintenance actually hit users? How does this interact with the error budget policy and freezes? What is graceful degradation during maintenance?

ONE CONCRETE EXAMPLE A database upgrade requires a brief read-only period. Approach one counts the resulting failed writes against the error budget, motivating the team to invest in an online schema change tool next time. Approach two declares a pre-announced low-traffic maintenance window, excludes those minutes from the SLI per an agreed policy, and shows users a graceful read-only banner. The team documents which approach applies, so the dashboards and the error budget remain trustworthy rather than quietly fudged.