Downtime Cost Calculator
A practical reference for teams that need to estimate the business impact of an outage.
Free downtime cost calculator: estimate the revenue, support, and churn cost of an outage so you can decide where faster monitoring and redundancy actually pay off.
When to reach for this tool
Reach for this when you need to estimate the business impact of an outage during setup, debugging, or an incident review. A one-off check is useful for diagnosis, but production systems need continuous monitoring once the immediate question is answered.
- Revenue per hour is only part of the cost; support load and churn add up.
- Use the figure to rank services, not as a precise guarantee.
- High-cost services justify faster detection and redundancy.
What actually goes into downtime cost
Lost revenue during the outage is the obvious number, but it is rarely the largest. A complete estimate adds the support load an outage generates (tickets, calls, staff time), any SLA credits you owe contractually, the productivity lost if internal teams are blocked, and the hardest to quantify but often the biggest: churn and reputation damage from customers who lose trust. You do not need these to the dollar. The point is comparative — a service whose outage triggers revenue loss, SLA credits, and churn deserves faster detection and more redundancy than one whose failure is a mild inconvenience. Use the estimate to rank where monitoring effort and resilience spending pay off.
- Direct lost revenue during the outage window.
- Support cost — tickets, calls, and staff time.
- SLA credits owed under contract.
- Internal productivity lost while teams are blocked.
- Churn and reputation damage — often the largest, hardest to quantify.
From one-off check to continuous monitor
Use the estimate to prioritize monitoring for the services where downtime carries real revenue, support, or contractual cost, and to justify tighter check intervals where they pay off.
- Recreate the same check in Sandglass on an interval so the next change is caught without re-running the lookup.
- Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever fixes the problem.
- Track the result over time instead of treating one manual reading as the final answer.
Why a lookup is not monitoring
A downtime number is only as good as its inputs. Treat it as a way to rank what to protect first, not as an exact figure to quote in a contract.
Use this tool well
Step 1: Run the check and read the result
Use the output to confirm the current state, and treat anything surprising as a starting point for diagnosis rather than a verdict.
Step 2: Define what healthy means
Write down which results count as healthy, degraded, or failed before you automate anything.
Step 3: Promote it to a continuous monitor
Recreate the same check in Sandglass on an interval so the next change is caught automatically.
Step 4: Route the alert to an owner
Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever will fix them.