“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.
1. “Available Whenever Needed” Is Not the Same as “Nothing Ever Stops”
Let us begin by separating three things that are often confused:
- Service availability: Whether users can access a service when they need it.
- The lifetime of an individual process or server: How long each individual execution environment continues running.
- Maintenance windows: Periods during which all or part of a service is stopped so that updates, inspections, and other work can be performed safely.
A service can remain available around the clock while individual servers behind it are replaced one at a time. It is also possible to prepare multiple environments, update one, and then switch over to it. In other words, continuing to provide a service to users and never stopping an individual execution environment are separate design decisions.
Likewise, a service running 24 hours a day does not mean that people must sit in front of monitors around the clock and manually review every alert. Operations can use automated detection and response while allowing people to focus on judgment and exceptional cases.
The problem is not the number “24/365” itself. The question is whether it reflects the service’s actual needs or is being maintained because of longstanding custom or the assumption that “stopping is bad.”
2. “Never Stopping” Also Has Costs and Risks
Updating a service without affecting users may require careful design, testing, automation, redundancy, and switching procedures. These mechanisms can be valuable, but they also create work: they must be designed, tested, and maintained so that they behave correctly when something goes wrong.
Advanced architectures are not inherently bad. They may be necessary for services that cannot be stopped. But if every system is required to operate without interruption at the same level, without first checking whether that level is necessary, costs and complexity may increase while the additional benefit remains small.
Updates also require time to review changes, apply them, and verify that everything works as expected. If the assumption that a system must never stop is too rigid, the available update options can narrow, and coordinating changes or switching environments can become more difficult. When a serious vulnerability is discovered, the priority should not be preserving uninterrupted operation for its own sake, but applying a fix at a speed and with a level of safety appropriate to the risk.
A long-running process may also retain malicious state that exists only in memory. However, long uptime alone does not necessarily make a system easier to compromise, and a restart does not automatically remove an attacker. If an attacker has left a foothold in configuration, credentials, or external management systems, the problem may persist after a simple restart.
What we should reconsider, therefore, is not merely whether a system stops, but whether its operating model leaves room to update, verify, and recover.
3. The Speed of Attacks and an Organization’s Ability to Respond
Systems exposed to the internet may be targeted by automated scanning and attacks before or after a vulnerability is publicly disclosed. Attackers can use automation to examine systems at scale, while defenders may still need people to determine which systems are affected, which services are at risk, and whether applying an update will interrupt business operations.
There is no need to exaggerate by claiming that AI can complete every stage of every attack in seconds. The important reality is that delayed responses to serious vulnerabilities can increase risk.
Organizations need to prepare for more than continuous alert monitoring. They need to know what technologies they use, be able to prioritize updates, have procedures for assessing impact, be able to plan a stop or switchover when necessary, and be able to recover when something goes wrong.
Conclusion: What Are We Trying to Protect by “Never Stopping”?
24/365 operation has real value. However, requiring the same level of availability from every service is not always rational.
“Never stopping” is not an end in itself; it is one means of protecting a business and its users. The starting point should be to determine the required availability according to the importance of each service, then achieve that target in a safe and sustainable way.
In the next article, we will ask, “Does a restart make a system safe?” and consider recovery to a trusted environment and the value of routinely verifying that recovery is possible.
References