Cost of Downtime for Startups: A Simple Formula

Your app went down for 40 minutes last Tuesday. Nobody can tell you what it cost. Engineering says "we need better infrastructure" and asks for budget. You have no way to judge whether that is a 5k fix or a 200k one.

The answer starts with a number: what does one hour of downtime cost your company? Once you have it, reliability stops being a feeling and becomes a spending decision like any other.

This post gives you a fill-in formula, a worked example, and a way to decide what to fix first.

The five costs of downtime

Most founders count only the first one.

Lost revenue. Sales or usage that did not happen during the outage and will not come back.
Support load. Tickets, chats and calls, plus the time to answer them, during and after.
Churn risk. Customers who leave or downgrade because of it. Usually the biggest and the hardest to see.
Engineer time. The people pulled off the roadmap to fight the fire, then write the post-mortem and fix the cause.
Contract credits. Refunds or service credits owed under an SLA, if you have signed any.

There are softer costs too, such as damage to your reputation and slower sales. Leave them out of the number at first. A conservative figure is easier to defend.

The fill-in formula

For one hour of downtime:

Cost per hour =
    Lost revenue per hour x share of revenue that is time-sensitive
  + (Extra tickets x minutes per ticket / 60) x support cost per hour
  + (Customers likely to churn x average annual contract value x chance they leave)
  + (Engineers involved x hours x loaded hourly cost)
  + SLA credits owed

How to get each input:

Lost revenue per hour: annual revenue divided by 8,760 gives an average hour. Adjust up for peak hours. If you are subscription-based, little revenue is truly lost in an hour, so set the "time-sensitive share" low (say 10%). For a marketplace or checkout flow, it may be close to 100%.
Support: ask your support lead how many extra tickets the last incident caused.
Churn: this one is a judgement call. Estimate the number of customers who noticed and the odds that one of them leaves because of it. Even 1% is worth including.
Engineer time: count everyone who stopped other work, including the follow-up.
SLA credits: read the contracts. Many startups find they have promised more than they track.

Example (illustrative)

A 15-person B2B SaaS startup. $3M annual recurring revenue. 120 customers, average contract $25k a year. Customers log in through the working day, and the product is part of their daily workflow. They have two customers on contracts with a 99.9% SLA and a 10% monthly credit.

The product goes down for 2 hours on a weekday morning.

Cost	Calculation	Amount
Lost revenue	$3M / 8,760 = ~$342 per hour; time-sensitive share 10% (it is subscription revenue); 2 hours	~$70
Support	60 extra tickets x 10 min = 10 hours x $40	$400
Churn risk	40 customers noticed; 2% chance each leaves = 0.8 customers x $25k	$20,000
Engineer time	4 engineers x 6 hours (incident plus follow-up) x $90	$2,160
SLA credits	2 customers x 10% of monthly fee ($25k / 12 = ~$2,083)	~$417
Total		~$23,000, or about $11,500 per hour

Look at where the money is. Lost revenue is nearly nothing. Churn risk is 85% of the total. That tells you what to protect: the experience of existing customers, and how fast you tell them what is happening, not raw uptime for its own sake.

The 2% churn chance is a guess. That is fine. Rerun the sum with 1% and 4% and see whether your decision changes. Often it does not.

Decide what to fix first

Now you can compare the cost of an outage with the cost of preventing it. If your engineers say a fix costs 3 weeks of one person (say $9k) and removes a failure that happens twice a year at $11,500 per hour of downtime, the maths is easy. If the fix costs $150k and removes a risk worth $5k a year, it is not.

Sort your fixes into two groups.

Cheap wins, do these first:

Uptime monitoring and alerts that wake someone up. Many outages last long only because nobody noticed.
A status page and a template for customer updates. This directly reduces churn risk and support load.
Automated database backups, with a restore you have actually tested.
One-click rollback for deploys. Most outages follow a release.
Health checks and auto-restart on your services.
A short on-call rotation and a one-page runbook for the top three failures.

These usually take days, not months. See DevOps and deployment optimization for the delivery side of this.

Expensive wins, do these when the numbers justify them:

Multi-region failover
Moving to a more complex orchestration platform
Full active-active databases
A dedicated SRE team

Each of them carries its own ongoing complexity, which causes outages of its own. Reach for them only when the cost-per-hour figure and your contracts demand it. Zero-downtime strategies explains which techniques are worth it at which stage.

For your CTO or engineers

Track incidents in a simple log: start, detection time, resolution time, cause, customers affected. After three months, you have real inputs for the formula.
Measure time to detect and time to recover separately. Detection is usually the cheapest to improve.
Set a service level objective per user journey (login, checkout, API) rather than one number for everything. The SLO and error budget guide shows how.
Look first at deploys, database migrations and third-party dependencies. In many systems these are the top three causes.

When 99.9% is enough

Uptime targets sound abstract. Translated to time per month:

99% allows about 7 hours of downtime a month.
99.9% allows about 43 minutes a month.
99.99% allows about 4 minutes a month.

Each extra nine costs roughly an order of magnitude more to run, so go up only when you must.

For most early-stage B2B products, 99.9% is plenty. Your customers are not going to leave over 43 minutes a month, but they will leave over slow answers, no communication, or the same failure repeating.

Go higher if:

You process payments or time-critical transactions, where each minute loses money directly.
You are in a regulated area where availability is part of the contract.
A customer of significant size requires it in writing, and pays for it.
Your cost-per-hour figure is large enough that the extra spend pays back.

Do not promise 99.99% in a contract unless you can measure it and you have built for it.

When NOT to do this

Do not chase reliability before the product has users. If nobody depends on you yet, an hour of downtime costs very little. Ship, then harden.
Do not build multi-region failover for a 10-customer product. Backups and fast recovery do the job.
Do not turn the formula into false precision. It is a way to compare options, not an accounting statement.
Do not ignore the cheap fixes because a big one sounds more serious. Monitoring and rollback beat an elaborate architecture you cannot operate.

Common mistakes

Counting only lost revenue and concluding downtime is cheap.
Promising an SLA in a sales contract without tracking uptime.
Buying more infrastructure when the real causes are bad deploys.
Having no way to learn about an outage except a customer email.
Skipping the post-mortem, so the same failure returns in three months.
Testing backups never, until the day you need them.

Checklist

Estimate cost per hour with the five-part formula
Run it at low, medium and high churn assumptions
Start an incident log if you do not have one
Set up uptime monitoring and alerts to a real person
Create a status page and an update template
Confirm one-click rollback and a tested backup restore
Review contracts for SLA promises
Choose a target (99.9% for most) and write it down
Rank fixes by cost per hour avoided divided by cost to build

Get the number and a plan

If you want help putting this on paper, my DevOps and reliability work starts from exactly this kind of cost-versus-fix comparison. The scaling and reliability guide collects related posts, and the backend scaling checklist is a good companion.

Book a free 30-minute technical review. Bring your last incident and we will build your cost-per-hour figure together.

FAQ

What is a reasonable uptime target for an early-stage SaaS?

99.9% is enough for most B2B products at this stage. It allows about 43 minutes of downtime per month, and reaching it is far cheaper than 99.99%.

How do I estimate churn risk from an outage?

Count the customers who noticed, then pick a small chance (1% to 5%) that each leaves because of it. Your incident log and customer success team will sharpen the guess over time. Run the formula at several values to see if the decision changes.

Do I need an SLA?

Only if a customer asks for one or you sell into regulated or enterprise buyers. If you promise one, track uptime from day one and know what credits you owe.

Is downtime still a problem if my customers never complain?

Yes. Many customers go quiet and leave at renewal. Quick, honest communication during an outage matters as much as the outage length.