High availability is often described as an infrastructure feature.
Add redundant servers. Put data on RAID. Use more than one Internet connection. Add a load balancer. Keep backups. Put a content delivery network (CDN) in front of the application.
All of those things can matter.
But after operating technology that had to remain available around the clock, I came to think of high availability much more broadly.
A system is only as available as the collection of dependencies required to keep it useful: power, cooling, connectivity, storage, application behavior, data synchronization, monitoring, maintenance procedures, vendors and the people who respond when something fails.
The distinction becomes obvious when something goes wrong at the least convenient possible time—which is usually when the system is busiest.
High availability is a chain of dependencies
A web application may be deployed across redundant servers and still be unavailable because the office lost power, the network path failed, the server room overheated, a database became overloaded, a third-party service stopped responding or nobody noticed the problem quickly enough.
That is why I separate component redundancy from operational availability.
Component redundancy asks whether a particular device or service has a backup.
Operational availability asks whether the business can continue functioning when something in the chain fails.
The second question is much harder.
A practical availability model has to consider at least:
- electrical power
- cooling and environmental conditions
- Internet and WAN connectivity
- switching, routing and firewall infrastructure
- compute and storage
- databases and file synchronization
- application behavior under load
- backups and recovery paths
- monitoring and alerting
- maintenance and change management
- staffing and incident response
The exact architecture varies by organization, but the failure domains are remarkably consistent.
Power redundancy has to bridge the gap
Commercial buildings often have generators. That does not necessarily mean the transition to generator power is instantaneous.
In environments I operated in Metro Manila, utility outages were common enough that backup power could not be treated as an edge case. A generator might start quickly, but equipment that cannot tolerate even a short interruption still needs battery-backed power to bridge the gap.
Servers and core networking equipment are usually the first things placed behind UPS systems. The problem is that a business depends on much more than the rack.
Workstations, access switches, phone systems, wireless infrastructure and other floor equipment may still go dark until generator power is available. A server that remains online is not particularly useful if the people and systems that need to reach it are offline.
For critical environments, the question therefore becomes:
Which parts of the business must survive the transition, and for how long?
A generator is a baseline. Battery-backed continuity for the right equipment is what closes the gap.
Cooling is infrastructure too
Cooling failures are easy to underestimate because they do not always look like outages at first.
The servers are still running. Network links are still up. Users may not notice anything immediately.
Meanwhile, temperature inside the server room is climbing.
By the time hardware begins throttling, shutting down or failing, the incident has already progressed much further than it should have.
That experience made environmental monitoring feel just as legitimate as monitoring CPU load or HTTP response codes.
Useful controls can include:
- redundant or appropriately sized cooling
- network-connected temperature and humidity sensors
- threshold alerts
- regular inspection and maintenance
- clear escalation procedures when temperatures begin trending upward
A server room should not depend on somebody happening to walk past and notice that it feels unusually warm.
Multiple Internet connections are not automatically independent
Using two Internet service providers sounds redundant.
Sometimes it is.
Sometimes both providers ultimately depend on the same physical route, cable system, upstream carrier or regional infrastructure.
That difference matters in countries where international connectivity can be affected by damaged undersea cables, severe storms or other regional events.
For systems that genuinely require resilience, I prefer to think about path diversity, not just provider count.
Where practical, that can mean:
- multiple ISPs
- providers using different upstream paths
- automatic failover
- satellite connectivity as an additional path
- infrastructure in more than one geographic region
Even then, there are limits. A sufficiently large regional event can affect several supposedly independent services at once.
The goal is not to claim that failure has been eliminated. It is to reduce the number of single failures that can take the business offline.
Server redundancy is only part of application redundancy
Redundant hardware does not automatically create a highly available application.
The application also has to tolerate distribution.
Depending on the system, that may involve:
- multiple application servers
- load balancing
- database replication or managed redundant database services
- synchronized file storage
- off-site backups
- CDN caching
- session handling that does not depend on a single server
- repeatable deployment and configuration
I have operated environments where files were synchronized between servers, databases had to remain consistent and Cloudflare was used at the DNS/CDN layer to distribute traffic across infrastructure.
The difficult part is not adding another server. It is identifying state: the data that cannot simply exist independently on each node.
Once state is understood, the architecture becomes much easier to reason about.
RAID is not a backup, and a backup is not recovery
RAID can keep a server operating after certain disk failures. It does not protect against every storage problem, accidental deletion, corruption, malware or loss of the entire server.
Backups therefore need their own architecture.
Depending on the environment, I have used combinations of:
- local backups for fast recovery
- backups stored elsewhere on the network
- off-site backups
- cloud storage
- replicated data on other infrastructure
But the more important lesson is that having backups is not the same as knowing the system can be recovered.
Recovery procedures need to be understood and periodically validated. A backup that nobody has tested is still an assumption.
Busy periods expose weaknesses that quiet periods hide
One of the most useful lessons I learned was that systems often fail at the worst possible time for a reason.
Busy periods create more of almost everything:
- customer requests
- database activity
- application logging
- call-center activity
- synchronization traffic
- concurrent sessions
- background processing
Infrastructure that looks perfectly healthy during a quiet afternoon can behave very differently under peak concurrency.
That is why load and stress testing became important to me—not only at the application layer, but across the hosting environment as a whole.
The useful question is not simply whether the application works.
It is:
What happens when everything that normally happens starts happening at the same time?
That is when hidden bottlenecks, worker limits, database contention, storage pressure and network dependencies become visible.
Maintenance has to be designed around continuous service
A 24/7 operation does not eliminate maintenance windows. It makes maintenance more disciplined.
The basics matter:
- scheduled maintenance
- current operating systems and application software
- hardware lifecycle planning
- retiring equipment before it becomes an emergency
- documented changes
- backups before risky work
- rollback plans
- clear communication between shifts
If maintenance is continually postponed because the system is “too important to take down,” technical debt eventually creates a much larger outage than the maintenance would have caused.
High availability therefore includes the ability to maintain the system safely.
Around-the-clock coverage is a team architecture problem
Technology does not operate itself.
As teams I managed expanded to provide better 24/7 coverage, scheduling became part of the reliability design.
I found shift overlap especially valuable. Instead of treating one shift ending and another beginning as a hard boundary, overlapping staff for an hour or two created space for:
- incident handover
- knowledge transfer
- joint troubleshooting
- training
- maintenance coordination
- explaining unusual conditions before the previous team left
That overlap reduces one of the least technical but most common risks in operations: information disappearing between people.
A monitoring platform can tell the next shift that a service is degraded. It cannot replace the context of someone saying, “Here is what we already tried, here is what changed, and here is what I would check next.”
Monitoring changed how I thought about reliability
Before building my own monitoring systems, I used whatever tools were available and often learned about failures indirectly.
A server could suddenly stop synchronizing with another server. An application would start producing errors because something it depended on was unavailable. A user would report that a site could not be reached.
Those are all signals—but they arrive after the dependency has already failed.
That frustration became one of the reasons I eventually built Slacron and later CrashSignal.
The objective was simple: ask the systems directly, continuously and from more than one location whether they were healthy.
Monitoring did not make infrastructure highly available by itself. It shortened the time between failure and awareness, which is one of the most important intervals in any incident.
High availability includes the people watching it
If I had to reduce the lesson to one sentence, it would be this:
True high availability is an operational capability, not a hardware feature.
It includes the obvious technical layers—power, connectivity, networking, servers, storage, databases and application architecture—but it also includes environmental monitoring, maintenance, testing, documentation, staffing, handovers and real-time alerting.
A redundant server is useful.
A resilient system is better.
And a resilient organization is the thing that keeps the system useful when several assumptions fail at once.
