High availability and SLA: understanding 99.9%

What an SLA is

The SLA (Service Level Agreement) is a contractual commitment on service quality, including availability. It sets a guaranteed uptime percentage and often compensation if the commitment is not met.

But an SLA is more than a figure: its scope, exclusions and calculation method matter just as much. A high percentage hedged with many exclusions can be worth less than a more modest figure with no asterisk.

Translating percentages into hours

Here is the heart of the matter, often misunderstood. 99% availability allows about 3.65 days of downtime per year. 99.9% drops to about 8.8 hours. 99.99% to under an hour (about 52 minutes). Each extra nine divides downtime by ten.

Put this way, the gap becomes telling. An SLA at 99% may seem high, but nearly four days of annual downtime would be unacceptable for an online store. The right level depends on your activity.

The rising cost of each nine

Going from 99.9% to 99.99% does not cost a little more: it costs a lot more. Each extra nine requires more redundancy, multi-site architectures, automatic failover and reinforced monitoring. The cost rises far faster than the gain in minutes.

The wise approach is to aim for the level suited to real criticality, not the maximum on principle. Overpaying for useless nines wastes a budget better spent elsewhere, for example on security.

How high availability is achieved

Technically, availability rests on redundancy: duplicated power, network and storage, so no single component can stop everything. Add automatic failover to a standby system and continuous monitoring that detects anomalies before the outage.

Our managed hosting integrates these mechanisms to the required level. You do not deploy the same architecture for a blog as for a critical application: you calibrate.

Availability and recovery: two different things

People often confuse high availability and a recovery plan. The first aims to avoid common outages; the second to recover from a major disaster. An application can be highly available yet vulnerable to a disaster if it has no recovery plan.

The two are complementary. High availability handles the everyday (a disk that fails, a server that reboots); the DRP handles the exceptional (fire, ransomware). A serious strategy covers both.

Measured vs perceived availability

An SLA measures infrastructure availability, but your users experience the perceived availability of the application. A service can be technically online yet unusable: extreme slowness, a key feature down, a failing external dependency.

That is why you must monitor the real experience, not just server status. Probes that simulate a user journey detect problems a simple ping misses, and alert before clients complain.

A good partner thinks in terms of useful availability: what matters is that your clients can do what they came to do, not that a technical indicator shows green while they fume at a frozen screen.

The real causes of downtime

Contrary to intuition, hardware failures are not the leading cause of outages. Human errors (mishandling, failed deployment), software problems and configuration incidents often weigh more. Hardware redundancy alone therefore does not protect against everything.

Hence the importance of rigorous practices: testing before production, staging environments, controlled and reversible deployments. Availability is played out in processes as much as in hardware.

Attacks (ransomware, denial of service) are a fast-rising cause of downtime. High availability must therefore be thought of together with cybersecurity, not in isolation, because a perfectly redundant system stays vulnerable if it is encrypted by an attack.

Penalties, service credits and recourse

An SLA with no counterpart for a breach does not really commit the provider. Most provide service credits: a partial refund if the promised availability is not met. Read the conditions carefully, as these credits are often capped and subject to specific steps.

Above all, keep in mind that these compensations rarely cover the real cost of an interruption for your business. A few percent credit on the monthly bill does not make up for a lost day of sales. The SLA is a commitment of means and a sign of seriousness, not insurance against your operating losses.

What matters, then, is less the penalty than the provider's real ability to keep its commitment. Better a partner whose architecture and processes make outages rare than one generous with credit promises but unreliable in practice.

Maintenance windows and the fine print

A detail often overlooked in SLAs: planned maintenance is usually excluded from the availability calculation. Updates, patches and upgrades sometimes require interruptions, which do not count as outages if they are announced. Reading this fine print tells you what the headline percentage really covers.

The aim is to shrink these windows and place them in off-peak hours. Modern architectures increasingly allow updates with no interruption, by shifting load during the operation. Whether your provider can do this is worth checking against your criticality.

Transparency matters most: a predictable maintenance calendar, communicated in advance, is far better accepted than a surprise interruption. A good partner plans and warns, rather than imposing its windows without consultation, and a clear SLA spells out exactly how and when maintenance happens.

Monitoring and alerting in practice

An SLA is only as good as your ability to know when it is breached. Real monitoring watches not just whether servers are up, but whether the service actually works for users, and alerts the right people the moment it does not.

Effective alerting is calibrated: enough to catch real problems early, not so much that teams drown in noise and start ignoring it. Synthetic checks that mimic a user journey are especially valuable, catching issues a simple ping would miss.

For an SMB, outsourcing this monitoring to a managed provider means a human actually watches and responds around the clock. Detection without response is pointless; the value lies in catching and fixing issues before they become outages users notice.

Building resilience beyond the contract

An SLA describes a commitment, but real resilience is built through architecture and practice. Well-designed redundancy, proactive monitoring, regular testing and disciplined change management are what actually keep a service running, not the wording of a clause.

Resilience also means accepting that incidents are inevitable and preparing for them. The question is not only how to avoid every outage, but how to limit its impact and recover fast when one occurs. This is where high availability meets the recovery plan.

Choosing a partner who thinks in terms of overall resilience, rather than a headline percentage, changes everything. You get not a reassuring promise on paper, but a genuinely robust service, sized to your activity and backed by rigorous daily operations.

Communicating availability to stakeholders

Availability is not only a technical metric, it is a conversation with the business. Leadership, client-facing teams and sometimes customers need to understand what level of service is guaranteed, what it costs, and what happens during planned maintenance.

Clear communication sets realistic expectations. Stating, in plain terms, the target uptime, the maintenance windows and the recovery commitments avoids the disappointment and finger-pointing that follow vague or unspoken assumptions.

A status page and proactive notifications turn availability into something visible and trusted. Stakeholders accept the occasional, well-communicated interruption far more readily than a silent one, and transparency itself becomes part of the perceived reliability of the service.

Align the SLA with business value

The right availability level is not decided by IT alone: it is decided with the business. An hour of downtime does not have the same cost for a showcase site, an online store in full campaign or an industrial production system. It is this cost that should guide the SLA.

This alignment avoids two pitfalls: under-protecting a critical system to save money, or over-investing in a secondary service out of excess caution. You put the right level of effort in the right place, according to the real stake.

Backed by managed IT that ensures commitments are met and measurements are transparent, a well-calibrated SLA becomes a genuine steering tool, not just a reassuring but hollow contractual line.

FAQ