What is an hour of downtime actually costing you?
Enter your revenue and see the real number — cost per minute, per hour, and per incident — plus what each uptime SLA actually allows you to lose. Nothing is uploaded; everything is computed on your device.
What each uptime SLA lets you lose — per month
| Uptime | Allowed downtime / mo | Cost if you burn it all |
|---|
Revenue-only estimate, assuming demand is spread evenly across the period. The true cost of downtime is usually higher — SLA credits, churn, support load, and engineering time stack on top of the lost revenue shown here.
How the cost of downtime is calculated
The fastest honest estimate is pure arithmetic: take your revenue for a period, divide by the number of minutes in that period, and you have revenue at risk per minute. Multiply by the length of an outage and you have the cost of that incident. If only part of your business depends on the system that went down, scale it by that share. That's exactly what the calculator above does — and it deliberately counts only directly lost revenue, so the number is a floor, not a ceiling.
The reason the figure lands harder than people expect is that minutes are small and revenue is large. At $300,000 a month you're losing roughly $6.85 every minute the system is dark — about $411 an hour, before a single customer churns or a single SLA credit is owed.
Uptime, SLAs, and your error budget
An uptime SLA is a promise about how little downtime you'll have. The gap between that promise and 100% is your error budget — the amount of downtime you're allowed to "spend" before you're in breach. Three nines (99.9%) sounds airtight until you do the math: it's about 43 minutes a month. Four nines (99.99%) leaves you just ~4 minutes. A single bad deploy can blow a month's entire budget in one afternoon.
Most preventable downtime isn't exotic infrastructure failure — it's change. A bad deploy, a risky migration, a config mistake, or an AI agent running a destructive command against production with nothing standing in the way. That whole category is self-inflicted, which means it's also preventable.
How to stop spending your budget on self-inflicted outages
Reduce release risk with a repeatable operating workflow: start the new version, check its health, control the traffic cutover, and prepare recovery before changing production. Choose manual review for high-risk releases, or allowlist and automatic approval where your policy permits them. Keep database restore procedures separate from application rollback.
Know the cost. Take control of the operating work.
Infraveil deploys releases, supervises processes, checks service health, applies managed gateway traffic rules, and provides restart and rollback controls for your backend. Run that work from one control plane while your applications stay on servers you control. Recovery options depend on the service and the release material available.
See the live demo →Frequently asked questions
How do you calculate the cost of downtime?
Cost per minute = revenue for the period ÷ minutes in that period, scaled by the share of revenue that depends on the system that's down. Multiply by the outage length for the cost of an incident. It's a revenue-only floor — real cost runs higher.
What's a good uptime SLA?
It depends on what an outage costs you — which is exactly what the tool shows. As a reference: 99.9% allows ~43 min/month, 99.99% allows ~4 min/month. Pick the target where the cost of more nines is worth less than the downtime it prevents.
Does this include churn and SLA penalties?
No — it's intentionally conservative and counts only directly lost revenue. Churn, SLA credits, support load, and engineering firefighting time stack on top.
How do I actually reduce downtime from deploys and AI agents?
Use health checks and a deliberate traffic cutover, scope automation to the job, and prepare restart, rollback, and database restore procedures. Choose manual review for high-risk managed releases; use allowlist or automatic approval where appropriate. See how Infraveil runs the workflow →