English 
Português
Keeping a system available requires a combination of architecture without single points of failure, monitored service-level objectives (SLOs), reversible changes, and a team prepared to fix the root cause of incidents. None of these fronts works alone, and all of them depend on routine, not on a one-off project.
In short
- Availability is the percentage of time an application is reachable and working as expected; even 99.9% allows about 43.8 minutes of downtime per month.
- The cost of a system outage goes beyond lost revenue: it includes support load, reputation and, in some industries, fines.
- The most effective practices are easy to describe and hard to sustain: eliminate single points of failure, measure what users feel, change in small steps and treat incidents as a process.
- When the in-house team cannot sustain that routine, a continuous application support model (AMS) becomes a concrete option.
What is system availability?
System availability is the percentage of time, over a given period (usually a month or a year), that an application is reachable and working as expected. It is not the same as reliability, which measures a system’s ability to perform its function without failure over a defined interval (Atlassian).
The market usually expresses availability in “nines.” The table shows how much downtime each level allows (based on a 365-day year):
| Availability | Downtime allowed per year | Downtime allowed per month |
|---|---|---|
| 99% | 3.65 days | about 7.3 hours |
| 99.9% (“three nines”) | 8.76 hours | about 43.8 minutes |
| 99.99% (“four nines”) | about 52.6 minutes | about 4.3 minutes |
| 99.999% (“five nines”) | about 5.3 minutes | about 26 seconds |
Sources: Pulsetic and HomeHost.
Each additional “nine” cuts the allowed downtime by roughly a factor of ten, and the engineering cost grows in the same direction. There is also a detail that often goes unnoticed: dependencies add up risk. Three services at 99.9% in sequence deliver, together, 99.7%, which means more than a day of downtime per year. AWS shows the same logic: a system designed for 99.99% with two hard dependencies, each also at 99.99%, has a theoretical availability of 99.97%.
How much does a system outage cost
According to The Hidden Costs of Downtime, a study by Splunk with Oxford Economics, unplanned downtime costs Global 2000 companies US$600 billion a year, up 50% in two years. The average cost reached about US$15,000 per minute, and the average revenue loss is US$95 million per company per year (eeNews Europe; TI Inside). For Latin American companies, the reported average is US$197 million a year. These are figures for large corporations; for mid-sized companies the scale is smaller, but the logic is the same.
In industry, ABB’s Value of Reliability survey points to a median of about US$125,000 per hour of downtime, and Siemens estimates up to US$2.3 million per hour in automotive manufacturing (Acronis).
To estimate the impact on your business, use a simple formula: revenue per hour × hours of downtime, plus emergency repair costs, idle labor and contractual penalties. Hidden costs come next: more support tickets, lost customer trust and brand damage.
That cost grows with every hour, and a failure rarely stays inside IT: it reaches operations, finance and the end customer. That is why critical systems call for continuous application management, not just a ticket opened when something breaks.
10 practices to keep a system available, according to the people who build it
1. Eliminate single points of failure
A single point of failure is any component whose failure takes down the entire system (Red Hat). To eliminate it, map the architecture, identify what has no backup (server, database, network link, third-party service) and add redundancy, load balancing and distribution across more than one availability zone. AWS also recommends reducing dependencies and choosing ones whose availability targets are equal to or higher than your system’s.
In practice: “Most of the time, the single point of failure is where nobody looks: an external integration, a certificate, a scheduled job. When we map the architecture, the question is always the same: if this stops, what stops with it?”
Matheus, full-stack developer
Common mistake: investing in redundant servers and leaving the database or an external integration as a single point.
2. Define SLIs, SLOs and an error budget
The SLI is the measured indicator (for example, the share of successful requests), the SLO is the target for that indicator, and the error budget is what remains: 1 minus the SLO. With a 99.9% SLO over 30 days, the budget is about 43 minutes of failure. The practice comes from Google SRE: 100% availability is unrealistic and grows exponentially more expensive with each marginal improvement, and when the budget runs out, non-urgent changes are frozen until reliability is restored (Google Cloud; isDown).
In practice: “An availability target has to be a conversation with the business, not a decision made by IT alone. When everyone understands how many minutes of downtime the process can tolerate, it is easier to prioritize what goes into the next release and what can wait.”
Pedro, back-end developer
Common mistake: adopting a “five nines” target without funding the architecture it requires.
3. Monitor what users feel
Monitoring only CPU and memory does not show whether a customer can complete a purchase or issue an invoice. Measure response time, error rate and availability of critical user journeys, and set alerts based on the SLO, not on isolated infrastructure thresholds. AWS recommends granular health checks, which enable fast failover when a component degrades (AWS).
In practice: “A good alert is one that makes someone act. If the team receives dozens of notifications a day, they learn to ignore all of them. I prefer few alerts, tied to what users feel, such as errors in the checkout journey or slow logins.”
Felipe, tech lead
Common mistake: creating so many alerts that the team starts ignoring them.
4. Make small, reversible changes
Changes are one of the main sources of incidents. Frequent, low-risk releases, with continuous integration and delivery (CI/CD), feature flags, gradual rollouts and a rollback plan, reduce the impact of each mistake. DORA metrics track exactly this: the change failure rate and the recovery time, now called “failed deployment recovery time” (Pulse). In the 2025 DORA report, 21.3% of top-performing teams restore service in under an hour and 56.5% in under a day, according to Axify.
In practice: “A big change is an incident waiting to happen. Small releases with a rollback plan ready let you go back in minutes and investigate calmly. No change should go to production without answering: how do we undo this if it goes wrong?”
Felipe, tech lead
Common mistake: piling up many changes into a single end-of-quarter release.
5. Test before and after reaching production
Automated tests, a staging environment faithful to production and load tests catch failures before customers do. For critical systems, AWS recommends going further, with chaos engineering and fault injection, which trigger problems in a controlled way to validate that the system recovers as expected (AWS).
In practice: “The most valuable test is the one that looks like real usage. Many failures only show up with volume, with real data or with a slow integration. The more faithful the staging environment, the less the customer becomes the first tester.”
Matheus, QA tester
Common mistake: testing the new feature well and forgetting to check regressions in what already worked.
6. Have tested backups and a recovery plan
Two numbers guide the plan: the RTO (the maximum acceptable time to bring the system back) and the RPO (how much data the company accepts losing). Red Hat gives a clear example: if backups are daily, there can be up to 24 hours of lost data in the recovered system. Define RTO and RPO per system, automate backups and rehearse the restore; a backup that has never been restored is just a hypothesis.
In practice: “A backup is only worth something once someone can restore it. I treat restoration as part of the routine, with a scheduled date and an owner. That rehearsal is where you find the problems nobody wanted to discover during an emergency.”
Pedro, back-end developer
Common mistake: measuring success by the completed backup, not by the validated restore.
7. Treat incidents as a process
A well-handled incident has a defined on-call rotation, runbooks, clear communication and, afterward, a root cause analysis in a blameless post-mortem format. The goal is to fix the problem that caused the failure, not just to restore the service. Without this cycle, the same incident comes back under a different name.
In practice: “Fixing the symptom solves the day; finding the root cause solves the quarter. After every incident, we record what failed, why we did not detect it earlier and which action prevents a repeat, without looking for someone to blame.”
Felipe, tech lead
Common mistake: closing the ticket when the system comes back, without investigating why it went down.
8. Pay down technical debt and keep everything updated
Versions of languages, databases, application servers and libraries that are out of support accumulate vulnerabilities and incompatibilities. Adaptive maintenance, which updates these layers, is a recognized part of software support, including in public regulations such as Brazil’s federal Ordinance SGD/ME No. 5,651/2022 (in Portuguese). When availability is critical, AWS recommends favoring stability over shipping new features (AWS).
In practice: “A postponed update tends to charge interest. An unsupported version, an outdated library, an old database: each item seems small until it becomes part of an incident. Setting aside recurring time to keep everything current costs less than firefighting.”
Felipe, tech lead
Common mistake: treating updates as a “task for when there is spare time.”
9. Plan for capacity
Usage peaks (month-end close, campaigns, draws, payroll) take down systems that work fine day to day. Track consumption trends, size database and integration limits, and use autoscaling where it makes sense: scaling servers up or down according to load is one way to sustain availability (Kaseya).
Common mistake: discovering the system’s limit during the peak.
10. Document and preserve knowledge of the system
If only one person knows how the system works, availability depends on that person’s calendar. Keep living documentation (architecture, integrations, recovery procedures, past decisions) and spread the knowledge across the team. In legacy or heavily customized systems, this is often the least visible risk.
In practice: “The quietest risk is knowledge concentrated in one person. If only one developer understands how the system works, availability depends on their schedule. Living documentation and shared knowledge are part of the infrastructure.”
Juliano, CEO of NextAge
Common mistake: leaving documentation for the end of the project, when nobody writes it anymore.
From knowledge to routine. Practices 7, 8 and 10 are not solved by a project: they are recurring work. In NextAge’s Application Managed Services (AMS), one third of the hour package is reserved for monitoring, technical governance and tracking of operational indicators.
Is availability a project or a routine? Reactive support versus continuous management
Many companies still treat availability as a byproduct of support: the system goes down, a ticket is opened and someone fixes it. That model is reactive and leaves the company with no visibility into what is at risk. Continuous application management, known as AMS (Application Managed Services), proposes a different logic: managing the application as a strategic asset, with permanent follow-up.
| Aspect | Reactive support | Application Managed Services |
|---|---|---|
| Approach | Waits for the problem to happen | Monitors, anticipates and evolves |
| Focus of the fix | Restoring the service | Root cause |
| Contract | One-off tickets | Hour package, defined SLA and scope |
| Evolution | Out of scope | Planned, within the contract |
| Governance | Little visibility | Periodic reports and meetings |
At NextAge, Application Managed Services are organized around four pillars: corrective (bug fixing), adaptive (adjustments and updates), evolutionary (improvements) and governance (technical management and executive oversight). The service works across several technologies (Java, Node.js, .NET, React, Angular, REST APIs, relational and NoSQL databases) and in cloud environments such as Azure, AWS and GCP, and it can act as an extension of the in-house IT team, not necessarily a replacement.
One example comes from one of the largest dairy cattle associations in Brazil (APCBRH). Its system suffered from cloud instability, manual billing and limitations in data collection. NextAge took over support, migrated the environment to a more stable infrastructure, integrated billing with the banking system through an API and created a new way to collect production data. The result was fewer outages and 100% of billing automated.
The decision between keeping a system supported and modernizing it is also part of the routine. Modernization is worth evaluating when the cost and risk of maintaining exceed those of evolving; typical signs are high technical debt, languages with a shortage of professionals and an architecture that limits scale. The safest path is usually incremental modernization, which replaces parts of the system and validates each step, without the exposure of a full rewrite.
Is your team keeping up? A 7-question self-assessment
Answer yes or no:
- Do we know, in minutes, how long our critical systems were down last quarter?
- Do we have availability targets (SLOs) defined and tracked per system?
- Do alerts warn the team before the customer notices the problem?
- Does every production change have a rollback plan?
- Have backups been successfully restored in the last six months?
- Do incidents go through root cause analysis, and are the resulting actions completed?
- Does more than one person master each critical system?
Three or more “no” answers indicate a relevant risk. In that case, a diagnostic conversation, at no cost and with no commitment, maps the risks in your systems and proposes an action plan: talk to NextAge.
A note of honesty: if your system is simple and low-risk, practices 1 through 6 may be enough with the in-house team. Continuous management makes more sense when operations depend on proprietary or highly customized applications and the IT team is too lean to cover every front.
Frequently asked questions
What is system availability?
It is the percentage of time an application is reachable and working as expected over a period, usually a month or a year. The higher the percentage, the less downtime is allowed. It differs from reliability, which measures whether the system performs its function without failure over an interval.
How much downtime does 99.9% availability allow?
About 8.76 hours per year, or 43.8 minutes per month. At 99.99%, the limit drops to about 52.6 minutes per year; at 99%, it rises to 3.65 days. Each additional “nine” reduces the allowed downtime by roughly ten times.
What is the difference between SLI, SLO and SLA?
The SLI is the measured indicator, such as the share of successful requests. The SLO is the internal target for that indicator. The SLA is the contractual commitment to the customer, with consequences if it is not met. In general, the SLA is looser than the internal SLO, to leave a safety margin.
What is an error budget?
It is the amount of failure the SLO allows in a period: 1 minus the SLO. With a 99.9% SLO over 30 days, about 43 minutes remain. When the budget runs out, many teams freeze non-urgent changes and focus on reliability until it is replenished.
What is the difference between traditional technical support and Application Managed Services?
Traditional support is reactive: it waits for the problem to happen before fixing it. Application Managed Services monitor, anticipate and evolve the application proactively, with governance, a defined SLA and planned evolution within a recurring contract, covering corrective, adaptive and evolutionary maintenance plus governance.
When does it make sense to modernize a legacy system instead of continuing to support it?
When the cost and risk of maintaining exceed those of evolving. Common signs: high technical debt, few professionals available in the technology and an architecture that limits scale. The safest path is usually incremental modernization, replacing parts of the system and validating each step.
Conclusion
Keeping a system available is an ongoing discipline: architecture without single points of failure, measured targets, reversible changes, incidents handled down to the root cause and shared knowledge. No extra “nine” makes up for the lack of routine. If your team cannot sustain that routine with the depth required, it is worth getting to know NextAge’s Application Managed Services and requesting a no-cost diagnostic.
