How Long Is Too Long for Website Downtime?
There's no universal number. "Too long" depends on your business impact, your customer expectations, and the recovery time you can tolerate. This guide shows how to define acceptable downtime using SLOs, error budgets, and recovery objectives.
Short answer
Downtime is "too long" when it exceeds your recovery time objective or consumes your error budget for the month.
Start with an SLO and error budget
Define availability targets
SLOs define your target availability (e.g., 99.9%). The error budget is the remaining allowed unavailability in a time window.
Use error budgets to decide "too long"
If your downtime consumes the entire error budget, that's a clear signal you've exceeded acceptable downtime for the period.
Define a Recovery Time Objective (RTO)
RTO is your maximum acceptable outage
RTO is the maximum acceptable delay between an interruption and service restoration. It should align with business impact.
Monitoring frequency must match RTO
Monitoring intervals should be short enough to detect failures in time to meet your RTO.
What makes downtime "too long" for your business?
Revenue impact
If each hour down costs real revenue, your acceptable downtime is likely minutes, not hours.
Customer expectations
If customers expect 24/7 access, even short outages can be costly.
Operational response
If you can't respond quickly, you need earlier detection and shorter intervals to reduce total downtime.
Regulatory or contractual SLAs
If you promise availability to customers, your allowed downtime is defined by those commitments.
A simple way to decide
- Define your most important customer action (purchase, booking, login).
- Estimate the cost per hour if that action is unavailable.
- Set an RTO (e.g., 30 minutes) based on that cost.
- Pick an SLO and calculate the error budget for the month.
- Set monitoring intervals that detect failures fast enough to meet RTO.
Want to shorten downtime?
Start a 30-day free trial and detect outages fast enough to meet your RTO.
FAQ
Is there a "good" amount of downtime?
It depends on your SLO and error budget. Most businesses set a monthly budget and aim to stay under it.
What if I don't have an SLO?
Start with a target availability (like 99.9%) and refine it based on business impact.
Does a short outage always matter?
It depends on timing and impact. Short outages during peak hours can be more costly than longer outages at night.
How does monitoring interval affect downtime?
Longer intervals can delay detection. Use intervals short enough to meet your recovery objective.
Sources
Google SRE Book (Embracing Risk): error budgets are 1 minus the SLO over a defined time window.
AWS Well-Architected Reliability (REL13-BP01): RTO is the maximum acceptable delay between interruption and restoration; recovery objectives should be defined per workload.
NIST Glossary (RTO): the maximum tolerable length of time a system can be down before the organization is impacted.