Downtime budget calculator
Pick a common SLA target or enter your own. The calculator uses calendar averages: 24 hours per day, 30.4375 days per month, and 365.25 days per year.
What the downtime budget actually means
The budget is not a permission slip to ignore failures until the last minute is spent. It is a planning limit. A 99.9% monthly target gives you roughly 43 minutes and 50 seconds of downtime in an average month. One bad database deploy, one expired certificate, or one network routing problem can consume that entire budget before the team finishes arguing about ownership.
For a small company, the number is useful because it turns reliability from a vague aspiration into an operating rule. If a customer-facing app has a 43-minute monthly budget, a 15-minute outage is not "small." It is about one third of the month. That should affect escalation, customer communication, and how quickly a rollback decision is made.
Common uptime targets
| Target | Monthly downtime budget | What it normally fits |
|---|---|---|
| 99% | About 7 hours 18 minutes | Internal tools, experimental services, and non-critical dashboards where manual recovery is acceptable. |
| 99.5% | About 3 hours 39 minutes | Useful business systems with some tolerance for scheduled maintenance or delayed repair. |
| 99.9% | About 43 minutes 50 seconds | Most public websites, ecommerce stores, SaaS apps, APIs, and customer portals. |
| 99.95% | About 21 minutes 55 seconds | High-value commerce, B2B workflows, and customer-facing APIs where outages quickly create support load. |
| 99.99% | About 4 minutes 23 seconds | Payment paths, login systems, order intake, primary API gateways, and other revenue-critical paths. |
The four SLA mistakes monitoring has to catch
1. Monitoring the homepage but not the transaction path
A homepage can return 200 while checkout, login, search, or an API dependency is broken. If the customer promise is about the ability to use the service, monitor the workflow entry points, not only the public landing page.
2. Treating partial failure as uptime
A service can be "up" and still unusable: response time jumps to 18 seconds, a required keyword disappears, SSL is near expiry, or the API returns an error page with HTTP 200. Use content checks and response-time thresholds when the difference matters.
3. Confusing detection time with outage time
With a 5-minute interval, a failure can start seconds after a successful check and remain invisible until the next check. That does not make the outage shorter. It means detection is delayed. For 99.99% targets, a 5-minute interval is too coarse for primary revenue paths.
4. Forgetting dependency ownership
If DNS, a CDN, payment processing, or a third-party API breaks your user journey, customers still experience downtime. Keep separate monitors for your own app and for the external dependencies that decide whether the app can complete work.
A practical monitor set for a small SaaS app
- Homepage HTTPS check: catches public routing, certificate, and web server failure.
- Login page HTTPS check with keyword validation: catches broken app rendering and auth-route failures.
- API health endpoint: returns dependency-aware status, not just process liveness.
- Database TCP check if the database is externally reachable from the monitor location; otherwise expose a controlled health result.
- SSL certificate expiry monitor for the apex and key subdomains.
- Status page monitor from a second provider so your public status channel is not blind.
Start with the free website status checker for a one-off check, then create persistent monitors from your dashboard.
How to choose the right check interval
Use the interval that matches the financial and operational cost of late detection. A five-minute check is reasonable for many marketing sites and internal tools. A one-minute check is more appropriate for login, checkout, order intake, and APIs that trigger urgent customer support when they fail.
The interval also changes how you interpret alerts. A single failed check on a 1-minute monitor can be transient. Two consecutive failed checks on a checkout endpoint are already worth paging someone. On a 5-minute monitor, waiting for three consecutive failures means accepting a detection delay that may be longer than the monthly budget for high-SLA paths.
Turn the number into an incident rule
After you know the downtime budget, define the first decision before the outage happens. For example: if the public API is down for more than 3 minutes, rollback starts unless the owner can prove a faster fix is already deployed. If checkout is down for more than 5 minutes, publish a status update and notify support. If the same endpoint has three short incidents in a week, treat it as one reliability problem, not three harmless blips.
That is where uptime monitoring becomes operationally useful. The alert is only the first signal. The value is in converting that signal into a response that protects the monthly reliability budget.