The cost of downtime is a figure you calculate from your own data, because published industry averages describe other companies. Add the revenue, refunds, wasted campaign spend, staff time and renewal risk of one hour offline, at an average hour and at your busiest hour. Then buy resilience one rung at a time. Stop when the next rung costs more per year than the outage losses it is expected to prevent.
This article is for an owner, a chief financial officer or an operations lead whose site is fine most of the time. It gives you a worksheet to justify infrastructure spending, or to refuse it with a reason.
How do you calculate what an hour of downtime costs your business?
You calculate the cost of an hour of downtime by adding five lines, each taken from records your business already keeps. A widely quoted cost per minute describes companies of a different size and business model.
| Cost line | Where the number comes from | Who holds the data |
|---|---|---|
| Lost or deferred revenue | Orders, sign-ups or leads per hour, multiplied by their average value | Sales or eCommerce reports, web analytics |
| Refunds and credits you owe | Service credits, refund clauses and penalties in your own customer or advertiser contracts | Contracts, finance |
| Wasted campaign spend | Paid advertising that keeps sending visitors to a site that is down | Marketing, advertising platforms |
| Staff time | Hours spent on the incident by developers, support and managers, at their loaded hourly cost | Payroll, time records |
| Renewal and reputation risk | Revenue from customers who are in a renewal cycle or a trial when the outage happens | Customer relationship records, account managers |
Three notes make the estimate honest.
Some revenue is deferred, not lost. A customer who cannot order at noon may return later. If you have had an outage before, compare the orders in the hours after it with a normal day.
A subscription business loses little revenue per hour and a lot per incident. A software as a service (SaaS) company bills monthly, so the first line is small. Its real exposure sits in the second and fifth lines. In one example scenario with a Canadian business-to-business SaaS company, the work began after the client’s own failed release had kept customers from logging in for thirty-eight hours. The example scenario reports that two customers filed credit requests, and one questioned the vendor’s future during its renewal call.
Contract clauses can outweigh everything else. In one example scenario with a national publisher, the client had three booked advertising campaigns with refund clauses that an outage during a campaign window would trigger.
Why does an outage cost more at some hours than at others?
An outage costs more at some hours because revenue, traffic and contractual exposure are not spread evenly across the year. Calculate the five lines for an average hour and again for your busiest hour, such as a sale, a product launch or a month-end reporting deadline. Peak traffic is also when capacity limits are most likely to be reached, so the most expensive hour can also be one of the riskiest.
Duration changes the figure as well. A five-minute interruption may cost almost nothing. A full day offline can cost more than twenty-four times the hourly figure, because customers start to leave and contracts start to apply. Estimate three cases: a short interruption, a half-day outage and a multi-day outage.
Does a hosting SLA credit cover the cost of downtime?
A hosting SLA credit does not cover the business cost of downtime, and this is standard practice across hosting and cloud providers. A service level agreement (SLA) is the contract document that states a provider’s service commitments and the remedy for missing them. The remedy is normally a service credit, which is a partial refund of the hosting fee.
The Stack Harbor SLA commits to 99.9% monthly availability for its network and its infrastructure as a service (IaaS), and it names the service credit as the sole and exclusive remedy. The credit is capped at the monthly fees for the affected services. That commitment covers Stack Harbor’s own network and IaaS, not an environment it operates on another provider’s cloud. The credit is not calculated from a customer’s lost revenue, refunds, campaign spend or staff time.
Protection against the business cost of an outage comes from architecture and response, not from contract language. A separate article explains how to read a managed hosting SLA clause by clause.
What can you buy to reduce downtime? The four rungs of resilience
You can buy resilience in four rungs, and each rung costs more than the one below it. Each rung protects against a different kind of failure, so a higher rung does not replace a lower one.
| Rung | What it protects against | What it does not do | Typical recovery |
|---|---|---|---|
| 1. Restore-tested backups | Data loss, corruption, a destroyed server | Shorten the outage while the restore runs | Often hours, depending on data size |
| 2. Monitoring with a human response | Outages nobody notices, slow first action | Remove the fault that caused the outage | Detection in minutes, then the repair time |
| 3. A second node or a high-availability cluster | Failure of one server, outages during patching | Survive the loss of a whole region, or undo a bad release | Service continues at reduced capacity |
| 4. A warm standby in a second region | Loss of a datacentre or a region | Prevent all data loss, since replication usually trails the primary | A rehearsed failover, decided by a person |
Rung 1: restore-tested backups. A backup that has never been restored is an assumption. The test tells you how long a restore takes, which is the length of your worst ordinary outage. The knowledge base covers how to verify that a database restore works.
Rung 2: monitoring with a human response. A monitoring tool sends an alert. This rung buys a person who acknowledges the alert and acts on it within a stated time, during business hours, extended hours or around the clock.
Rung 3: a second node. A high-availability (HA) cluster runs the application on two or more servers behind a load balancer, with a replicated database. One server can fail, or be patched, while the service stays up.
Rung 4: a warm standby region. A warm standby is a smaller copy of the environment in a second region, kept current by replication and started by a rehearsed failover. Active-active, where two regions serve traffic at once, sits above this rung and is expensive to operate for most small and mid-sized businesses.
One cause of downtime sits outside the ladder. Releases, plugin updates and configuration changes are a common cause of outages, and redundancy copies a bad change to every node. An outage caused by a release with no staging environment and no rollback is not an infrastructure failure. The protection against it is a release process, such as a deployment pipeline with staging and rollback.
How much uptime do you need?
You need enough resilience to keep your longest outage shorter than the business can absorb, and that is a duration, not a percentage. Two terms express it. The recovery time objective (RTO) is how long the service may stay down. The recovery point objective (RPO) is how much recent data you can afford to lose.
Set both figures from the worksheet. If the expected yearly cost of four-hour outages is lower than the yearly cost of a second node, an RTO of four hours is a defensible business decision. If a four-hour outage breaches a customer contract, it is not. The knowledge base explains how to translate RTO and RPO for a non-technical chief executive and the trade-offs between RTO, RPO and architecture cost.
A percentage hides that question. A 99.9% monthly figure allows about 43 minutes of downtime in a 30-day month. Forty-three minutes on a Sunday night and forty-three minutes during a launch are different events with the same percentage.
Do you need a high-availability cluster, or are good backups enough?
Good backups are enough when the business can tolerate being offline for the length of a tested restore. A high-availability cluster is needed when it cannot.
Choose restore-tested backups and monitoring, and stop there, under these conditions.
- The peak-hour cost of downtime is small compared with the yearly cost of a second node.
- No customer contract sets a recovery time shorter than your tested restore.
- Customers and staff keep the same hours, so an overnight outage harms nobody.
Choose a second node or a cluster under these conditions.
- A single server failure during a sale, a campaign or a working day has a visible price.
- Patching keeps being postponed because every reboot is an outage.
- Customers have started asking about availability in contracts or security questionnaires.
Choose a second region under these conditions.
- A customer contract or a regulator requires a written disaster recovery plan with a recovery time.
- A tested restore cannot meet that recovery time.
When is more resilience not worth buying?
More resilience is not worth buying when the next rung costs more each year than the losses it is expected to prevent. Three situations are common.
- An hour of downtime costs little. Buy backups with restore tests and business-hours coverage, and stop.
- Your customers are asleep when you are. Round-the-clock coverage pays for hours in which nobody is harmed. Business-hours or extended coverage may be the honest fit.
- A tested restore already meets your contractual recovery time. A second region adds cost and operating work without reducing a loss you carry.
A design that limits how much fails at once can also be cheaper than duplicating everything. The knowledge base explains blast radius design.
What drives the cost of each rung?
The cost of resilience is driven by how many components are duplicated and by how many hours a person is available to respond. Each rung also carries the operating work of tests and drills.
- Backups: data volume, retention, off-site copies and the time spent on restore tests.
- Monitoring and response: the coverage window, the committed response time for each severity level and the number of environments.
- A cluster: extra servers, load balancers, database replication, shared storage and any application changes needed to run on more than one node.
- A second region: standby capacity, replication, failover tooling and scheduled drills.
Resilience usually raises the hosting bill. In one example scenario that moved a business application to a managed platform, the example scenario reports that infrastructure cost rose 11%. That figure belongs to one client and is not a typical result. The worksheet tells you whether that rise is justified. A companion article explains how managed cloud hosting is priced.
A decision framework to take to your finance meeting
Work through these seven steps with your own figures.
- Calculate the five cost lines for an average hour and for your busiest hour.
- Estimate three outage lengths: a short interruption, half a day and several days.
- List your outages from the last two years, with their causes and durations.
- Multiply a typical outage cost by the number of outages you expect in a year. That is your expected yearly loss.
- Match each past outage to the rung that would have prevented or shortened it.
- Ask providers for a quote for that rung only, and compare its yearly cost with the loss it removes.
- Write down the RTO and RPO you accept, and have an owner in the business sign them.
When you compare providers, see what to look for in a managed hosting provider.
Where Stack Harbor fits
Stack Harbor is a Canadian-owned managed cloud operations provider (MSP) for production environments, headquartered in Montréal. It serves SaaS companies, agencies and publishers that run production systems without a 24/7 operations team of their own. It operates environments on its own Canadian infrastructure and on clouds such as AWS, Azure and Google Cloud.
Three Stack Harbor solutions map to the rungs described above. With managed monitoring and on-call response, a trained person acknowledges the alert and runs a playbook designed by senior engineers, and senior engineers are engaged on Severity 1 incidents. Response targets are graded by severity and written into the agreement. Coverage is scoped as business hours, extended or 24/7. HA clusters are designed so that losing one node reduces capacity and the service stays available. That is a design property, not an uptime promise. Multi-region disaster recovery uses a warm standby, a failover that a person approves and a quarterly drill. RTO and RPO figures are scoped in the assessment and signed off by a named owner on the client side.
Where backups are in scope, the Trust & Security page lists scheduled backups with verified restore tests and a quarterly restore rehearsal. These are practices, not a promise of a recovery outcome. Stack Harbor publishes no prices. Engagements are scoped to drivers and quoted as a fixed price after a written assessment.
Stack Harbor is the wrong fit if your worksheet calls for an availability commitment above the 99.9% monthly figure in its SLA, an uptime commitment for the application itself, or compensation for business losses. It is also the wrong fit when the whole footprint is one instance and a storage bucket, because a managed operations contract would be overhead. If your worksheet points to a higher rung, the next step is a scoping conversation about your environment.
