At some point, your website will go down. It's not a question of if—it's when. Hardware fails. Software has bugs. DNS propagates incorrectly. Certificates expire. Databases crash.
The difference between a minor hiccup and a major disaster isn't whether downtime happens. It's how fast you detect it, how well you respond, and how effectively you prevent it from recurring.
This guide covers everything about website downtime: understanding it, surviving it, and minimizing it.
Dealing with an outage right now? Skip to what to do when it happens or create an emergency status page instantly.
What is Website Downtime?
Website downtime is any period when your site or service is unavailable or unusable for visitors. This includes:
- Complete outage: Server returns errors (500, 502, 503) or doesn't respond at all
- Partial outage: Some pages work, others don't. Homepage loads but checkout is broken
- Functional downtime: Pages load but functionality is broken—can't log in, can't submit forms, can't complete purchases
- Performance degradation: Site loads but is so slow that it's effectively unusable
The last two are often worse than complete outages because they're harder to detect. A server returning 500 errors triggers monitoring alerts. A checkout that silently fails might not.
Why even "up" isn't always enough: Why uptime alone isn't enough.
Types of Downtime
Planned Downtime
Scheduled maintenance, deployments, migrations. You know it's coming and can prepare: notify users, schedule during low-traffic hours, have a rollback plan.
Planned downtime is increasingly avoidable with zero-downtime deployments, but some operations (major database migrations, infrastructure changes) still require it.
Unplanned Downtime
The bad kind. Something breaks unexpectedly: server crash, bug in a deploy, DDoS attack, expired certificate, DNS issue. No warning, no preparation.
Partial Downtime
Only some users or some features are affected. A CDN node fails in Asia, your payment processor has an outage, a single microservice crashes. Often harder to detect than full outages.
Common Causes of Website Downtime
Most outages trace back to a handful of repeat offenders. They cluster into five buckets: infrastructure (hardware failure, resource exhaustion, cloud provider outages), software (bad deployments, database problems, memory leaks), network and DNS (misconfigured records, expired SSL certificates, CDN failures), external factors (DDoS attacks, third-party dependency outages, traffic spikes), and human error (config mistakes, forgotten renewals).
The pattern that matters: a large share of downtime is entirely preventable. Expired certificates, lapsed domains, and full disks don't have to take you offline if you're watching for them.
Deep dive: the 12 most common causes of website downtime, with how to detect and prevent each one.
The Real Cost of Downtime
Direct Revenue Loss
When your site is down, you can't sell. The formula is simple: hourly revenue x hours of downtime = lost sales.
Calculate yours: Downtime cost calculator.
Indirect Costs
Direct revenue loss is only the beginning:
- SEO impact: Extended downtime causes de-indexing. Recovery takes weeks.
- Customer trust: Users who experience outages are less likely to return or recommend you
- Support costs: Every minute of downtime generates support tickets and social media complaints
- Lifetime value: A churned customer doesn't just cost one sale—you lose their entire future spend
- Team productivity: Incident response pulls your team away from building
Scale Matters
| Monthly Revenue | Cost per Hour | Cost per Day |
|---|---|---|
| $1,000 | $1.37 | $33 |
| $10,000 | $13.70 | $329 |
| $100,000 | $137 | $3,288 |
| $1,000,000 | $1,370 | $32,877 |
Remember: actual costs including reputation damage are typically 2-3x the direct revenue loss.
What to Do When Your Site Goes Down
When the alert fires, work in order: verify the outage from a different network, communicate immediately on your status page (acknowledge before you know the cause), diagnose by checking logs, error rates and recent deploys, fix or mitigate (roll back, restart, scale, route around), then verify recovery from multiple locations and close the loop with a resolution update.
The biggest mistakes are going silent and declaring victory too early — checking only the homepage while checkout is still broken.
Deep dive: a step-by-step action plan for when your site goes down, with timings and commands. In a hurry? Spin up an emergency status page now.
Communicating During Downtime
How you communicate during an outage matters as much as how fast you fix it. The rules are simple: communicate fast (acknowledge before you know the cause), be honest rather than evasive, update every 15–30 minutes even with no new information, use your status page as the primary channel, and close the loop with a resolution update.
Deep dive: how to communicate during an incident — with templates and timing.
Get your status page ready first: status page best practices.
Preventing Downtime
You can't eliminate downtime completely, but a small number of habits prevent most of it. The high-leverage ones: monitor everything that matters (uptime, response times, resource trends), enable auto-renewal and alerts for SSL certificates and domains, automate deployments with fast rollback, watch disk space and background jobs that fail silently, and have a status page ready before you need it.
Most of these are set-and-forget. The point isn't heroics — it's removing the preventable causes so you only ever fight the genuinely unexpected ones.
Deep dive: how to prevent website downtime — the 80/20 checklist plus infrastructure, deployment, DNS and SSL specifics. See also the complete monitoring checklist.
After the Incident: Learning and Improving
The most valuable time is right after an incident, while details are fresh. Within 24–48 hours of anything significant, write a blameless post-mortem: what happened (timeline), why (root cause), how it was detected and resolved, and what you'll change. Turn it into concrete action items with owners and deadlines — a post-mortem without follow-through is just documentation.
Track MTTD (mean time to detect) and MTTR (mean time to recovery) over time. Both should trend down as you learn from each outage.
Deep dive: how to run a post-mortem — a copy-paste template and a worked example.
Frequently Asked Questions
What is an acceptable amount of downtime?
Industry standard for most businesses is 99.9% uptime (about 43 minutes of downtime per month). Critical systems target 99.99% (about 4 minutes/month). 100% uptime is practically impossible. What matters is minimizing downtime duration and communicating well when it happens.
How do I know if my website is down?
The fastest way is automated uptime monitoring that checks your site every 1-5 minutes and alerts you immediately. Without monitoring, you'll typically find out from customer complaints—hours after the outage started. Set up monitoring to detect issues within minutes.
What causes the most website downtime?
The three most common causes are: 1) Software bugs and bad deployments, 2) Infrastructure and hosting issues, and 3) Human error (configuration mistakes, expired certificates, forgotten renewals). Third-party service failures and DDoS attacks are also significant causes.
Does downtime affect SEO?
Brief downtime (minutes) has minimal SEO impact. Extended downtime (hours to days) can cause Google to temporarily de-index pages, drop rankings, and stop crawling. Recovery after extended downtime can take days or weeks. Fast detection and resolution minimizes SEO damage.
How can I prevent website downtime?
You can't prevent all downtime, but you can reduce it: use monitoring to detect issues fast, implement redundancy (multiple servers, CDN), use zero-downtime deployments, monitor SSL and domain expiry, and have an incident response plan ready. Post-mortems after incidents help prevent recurrence.
Downtime Is Inevitable. Disasters Aren't.
Every website experiences downtime. What separates well-run sites from disaster stories is preparation: monitoring that catches issues fast, communication that maintains trust, and processes that prevent recurrence.
Start with monitoring. Add a status page. Build a response plan. Learn from every incident. Your uptime will improve steadily.