Part 4: Breaking Free from the 24/365 Constraint — Maintenance Windows as a Management Decision
“Web services are supposed to run continuously, 24 hours a day, 365 days a year.” When did we start taking this for granted? The theme of this series is whether the value gained from 24/365 uptime is worth the security
“Web services are supposed to run continuously, 24 hours a day, 365 days a year.” When did we start taking this for granted?
The theme of this series is whether the value gained from 24/365 uptime is worth the security risk. Rather than rejecting continuous operation outright, we will examine its benefits and trade-offs from the perspectives of security, operations, and business.
Technically, planned downtime can be a useful option. Routinely verifying recovery procedures also has value. Neither the burden placed on operators nor the complexity required to avoid interruptions can be ignored. ——
Even so, the operations team alone cannot simply decide, “This service will stop on a regular schedule.” Downtime may interrupt users’ work or affect revenue and business operations. Ultimately, the required level of service availability must be decided in light of business value and risk.
1. Is Higher Availability Always Better?
Setting a more ambitious availability target can come with costs: additional infrastructure, operational automation, test environments, complicated switchover procedures, and extra maintenance work. Whether those costs are worthwhile depends on the service.
For example, the acceptable downtime for a service whose unavailability could affect human life or safety during an emergency is not the same as for an internal service whose users can wait until the next morning. For an online store, too, the loss caused by being unable to accept orders must be weighed against the damage that could result from a serious compromise.
Using a simple time-based calculation, 99.9% annual availability corresponds to about 8 hours and 46 minutes of downtime, while 99.99% corresponds to about 53 minutes. These are approximate figures that assume planned downtime is included in the total. Some SLAs exclude scheduled maintenance from their availability calculations. Without tracking both the contractual figure and the time users actually could not access the service, the true user experience can be obscured.
Google’s SRE approach likewise treats availability as something to set according to a service’s purpose and the level of risk the business is willing to accept, rather than something to maximize without limit. As targets rise, the money and time available for other improvements may shrink.
Therefore, neither “set every service to 99.9%” nor “set every service to at least 99.99%” is an appropriate universal answer. The question is what level each service actually needs.
2. Five Questions for Defining a Maintenance Window
Executives, service owners, and operations teams should consider at least the following questions together.
First, who will be affected by downtime, and how?
Determine whether users can avoid the maintenance period, whether alternatives are available, and how much business may be lost if work is interrupted. If the impact would be significant, consider options other than taking the entire service offline.
Second, how quickly must updates or fixes be applied?
When a serious vulnerability is disclosed, it may not be safe to wait for the next scheduled maintenance window. Establish criteria and authority for emergency updates in advance, so the organization can act without waiting for the normal maintenance schedule when necessary.
Third, are there alternatives to stopping the service?
Compare options such as phased updates, redundant environments, and temporarily disabling only selected functions. The best approach depends on the system’s architecture and service requirements.
Fourth, how do the total costs compare?
Compare not only infrastructure costs, but also the time spent on development, testing, and operations; work required outside normal hours; losses caused by downtime; and the cost of recovering from outages or security incidents. Planned downtime is not always cheaper, but making the costs of uninterrupted operation visible is valuable.
Fifth, has the ability to recover been verified?
Test that startup procedures work, that an environment can be rebuilt from a trusted state, that backups can be restored, and that data can be checked after recovery. Record problems found during testing and track corrective actions.
3. Customer Commitments Must Be More Than Numbers
If maintenance windows are incorporated into operations, users need clear information about when the service will be unavailable and what they will be unable to do. The treatment of maintenance periods in an SLA or terms of service should also be defined in accordance with the nature of the service and the relevant contract.
However, excluding scheduled maintenance from an availability calculation does not automatically increase customer trust. Transparency matters: explain the actual impact on users, how they will be notified, how long the service is expected to be unavailable, and what will be communicated if an unplanned interruption occurs.
The message to customers should be more than “We are stopping the service for security reasons.” Explain why maintenance time is needed, how users will be affected, and how the recovery will be verified—in language they can understand.
Management also needs to do more than demand that the system “never stop.” It must provide decision criteria and authority for necessary maintenance and emergency response. At the same time, operations teams should explain why downtime may be necessary not only in technical terms, but also in terms of business impact, risk, cost, and alternatives.
The purpose of a maintenance window is not to justify downtime. It is to create an operating model that can reliably perform updates and recovery while protecting the level of availability the business actually needs.
Conclusion: The Availability Number Is Not the Only Thing to Protect
24/365 operation is not excessive for every service. When downtime would have an extremely serious impact and high availability is a business requirement, investing in the mechanisms needed to achieve it can be rational.
On the other hand, if an organization pursues high availability without a clear need, narrowing the room for maintenance and updates while accumulating complexity and operational burden, that policy is worth reviewing. Planned downtime is not a universal security solution. But designing a system so that it can be stopped safely when necessary, verified, and recovered expands the organization’s options.
The question throughout this series has not been whether systems should always stop or never stop. It has been whether the value gained from a particular level of availability truly justifies the additional costs, complexity, security constraints, and burden placed on operators.
When decisions account not only for the availability figure but also for timely updates, recovery to a trusted environment, and sustainable operations by the people responsible, 24/365 becomes a deliberate choice aligned with a purpose rather than an unquestioned convention.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.