What is downtime?
A site is down when a visitor cannot reach it or cannot use it: the page does not load, the server returns an error, the checkout hangs, the login fails. Downtime is the measure of how often and how long that happens. Hosts express the opposite as uptime, usually in nines: 99.9 percent uptime allows roughly nine hours of downtime a year, and 99.99 percent allows under an hour.
It comes in two kinds. Planned downtime is a maintenance window the team chose: a migration, a major update, a hardware change. Unplanned downtime is everything else: a traffic spike that overwhelms the server, a bad deploy, an expired certificate, a plugin update that breaks the theme, a denial-of-service attack, or a data center losing power. The first is a scheduling decision. The second is the one that costs.
Why it matters
Why downtime matters
When a site is down, everything that depends on it stops: sales, leads, sign-ups, the campaign that just went live, the press link that just got shared. The direct cost is the revenue lost per minute. The indirect cost is worse: visitors who hit an error remember it, search engines that find a site down repeatedly start to trust it less, and a brand that sold confidence looks careless. Downtime during a launch is the specific nightmare, because it is the moment the most people are looking.
In practice
How downtime works in practice
- 01
Preventing it is a stack of unglamorous habits. Hosting sized for the peak, not the average. A CDN in front of the origin to absorb spikes. A staging site where updates are tested before they touch production. Backups that are taken automatically and, crucially, restored once in a while to prove they work. Certificates and domains on auto-renew. Monitoring that checks the site from outside every minute and texts someone when it fails.
- 02
Handling it is a plan written before it is needed: who is on call, how to roll back the last change, how to switch to a holding page, how to tell customers. The fastest recoveries are the ones where the team knows the most recent change and can undo it. Afterwards comes the part most teams skip, the honest write-up of what broke and what will stop it breaking again.
Watch out
What people get wrong about downtime
Treating uptime as the host's problem alone. Most downtime we see is self-inflicted: an update applied straight to the live site on a Friday afternoon, a form plugin that silently stopped sending, a card on file that expired and took the hosting with it. The other mistake is only finding out from a client. If the first alert comes from a person rather than a monitor, the monitoring is missing. And a quieter one: declaring the site fine because the homepage loads, while the checkout or the contact form has been broken for a week.
Finally, teams over-index on the nines in the hosting contract and under-index on the ten minutes it takes to set up a staging site, which prevents more outages than any service level agreement.
