Where the Hours Go: An Anatomy of WordPress Downtime
Ask anyone who has sat through a long WordPress outage what took so long, and the answer is rarely "the fix". The fix, once someone found it, was a plugin rolled back or a database imported. Ten minutes of real work. The other hours went somewhere else: waiting for someone to notice, waiting for the right person to wake up, hunting for a password, waiting on a support ticket, waiting for a cache to clear. Downtime is mostly waiting, and waiting is something you can plan out of a site long before anything breaks.
Why count hours at all?
Because hours are what an outage costs. A broken site is not expensive for the first minute. It becomes expensive as the minutes pile up: sales that do not happen, leads that go to a competitor, staff time spent firefighting, and a support inbox that fills up behind the outage and keeps someone busy for days after it ends.
Some of those costs are easy to see and some are not. Lost sales show up in your analytics as a dip. The hours your developer or agency bills for the emergency show up on an invoice. Harder to see are the visitors who tried once, found an error and never came back, the paid ads that kept running and sending clicks to a broken page, and the review someone left because they could not reach you. None of these grow with the difficulty of the fault. They grow with time. A five-minute fix that sits unnoticed for eight hours costs far more than an hour-long fix that starts right away. That is why it pays to think about outages in hours, and to ask how many of those hours were spent fixing and how many were spent waiting.
If you want to put a number on your own site, BackupYourSite's breakdown of what an hour of WordPress downtime really costs is a sensible starting point. It splits the bill into three parts, lost revenue, labour and a recovery-time multiplier set by how your backups are built, and argues that the last one is the number site owners most often underestimate. That framing is the reason for this article. You usually cannot change what an hour costs you. You can change how many hours an outage lasts.
Once you think of it that way, every segment below becomes a line in a budget. Cut an hour from any of them and you save the same money as cutting an hour from any other.
An outage, split into honest segments
Most post-mortems record two times: when the site went down and when it came back. That single number hides almost everything useful. Split it up and a much clearer picture appears. A typical WordPress outage moves through nine segments, though not every outage visits all of them.
1. Detection: from the moment the site breaks to the moment someone knows.
2. Reaching the right person: from "someone knows" to "someone who can fix it is working on it".
3. Getting in: logging in to the host, the server, the database, the backup storage.
4. Diagnosis: working out what broke and choosing what to do.
5. Finding a usable backup: locating a copy that is before the break and actually complete.
6. Moving the data: getting that backup to where it needs to be.
7. Restoring: putting files and data back in place.
8. Propagation: caches, CDNs and DNS catching up with the fixed site.
9. Verification: proving the site works, not just that it loads.
Let's go through them one at a time.
1. Detection: the segment nobody times
An outage that starts at 11 p.m. and is spotted at 8 a.m. has used nine hours before anyone has done anything. On many small sites, detection is the longest segment by a wide margin, and it is invisible because nobody was watching while it happened.
What makes it long: relying on customers or the owner to notice, outages that start outside working hours, and partial failures that do not take the homepage down. A broken checkout, a contact form that silently stops sending, or a page that only fails for logged-out visitors can run for days.
What shortens it: an external uptime monitor that checks the site every few minutes and alerts a person, not just an inbox nobody reads at night. Go further than the homepage. Check a page that touches the database, and if the site sells anything, check that the checkout page loads. Some monitors can look for a specific piece of text on the page, which catches the case where the server returns a normal response but the page is broken.
2. Reaching the right person
An alert that goes to someone who cannot act on it just moves the waiting. The owner gets a text at midnight, but only the developer can fix it, and the developer's phone is on silent. Or the agency is notified, but the client holds the hosting login.
What shortens it: decide in advance who is first on call for each site, who is second, and what counts as worth waking someone for. Write it down where the alert lands. For agencies, this includes clear agreements with clients about out-of-hours response, because a fast restore that starts eight hours late is not fast.
3. Getting in: access friction
This segment surprises people. The right person is awake and ready, and then spends forty minutes trying to log in. The hosting password lives in a former employee's head. Two-factor codes go to a phone that is in a drawer at the office. The SSH key was on a laptop that has since been replaced. The backup storage account was opened by someone else and nobody knows the login.
Strong security is not the problem here. Two-factor authentication on hosting and backup accounts is exactly right. The problem is security that only one person can operate. What shortens it: a shared password manager or vault for the team, recovery codes for two-factor stored somewhere at least two people can reach, and a quarterly check that every credential needed for a restore still works. That last part matters. Credentials go stale quietly, and you only find out when you need them.
4. Diagnosis
Diagnosis is the segment with real skill in it, and also the one where a bad choice costs the most time later. Restore the wrong thing and you add a second outage on top of the first.
What makes it long: no error logs, or logs nobody knows how to find; several changes made around the same time so nobody can say which one broke the site; and a habit of guessing and trying instead of looking.
What shortens it: knowing where the PHP error log is on each host, turning on WordPress debug logging to a file rather than to the screen when you need it, and keeping a simple change log, even a shared note, of updates and edits with times attached. If the change log says "updated three plugins at 10:40 p.m." and the monitor says the site broke at 10:42, diagnosis takes about a minute.
5. Finding a usable backup
"We have backups" and "we can find the right backup in five minutes" are very different statements. This segment is where they come apart.
What makes it long: not knowing where backups are stored; backups that turn out to be older than expected because a scheduled job had been failing quietly; backups that are incomplete, such as files with no database or a database with no uploads; and backups stored in a format that has to be restored through a tool you no longer have installed.
There is also a nastier version. If the server itself is the problem, any backup stored on that same server or in that same hosting account may be out of reach along with the site. Backups kept by the host can mean a support ticket and a queue before you even see them.
What shortens it: one written note, per site, saying where the backups live, how often they run, how far back they go and how to log in. Copies stored away from the site, so a server or account problem does not take them down too. And some form of check that backup jobs are actually succeeding, so the newest copy is the age you think it is.
6. Moving the data
This one is simple arithmetic, which makes it easy to estimate in advance and strange that so few people do. Divide the backup size by the real transfer speed between where the backup is and where it needs to go.
For example, a 5 GB backup moved at a steady 10 MB per second takes roughly eight and a half minutes. The same backup downloaded to a laptop on a slow home connection and then uploaded to a new server could take well over an hour, because it travels twice and the upload leg is usually the slowest. The numbers here are only illustrations. The point is that the route matters as much as the size.
What shortens it: restoring server to server instead of through a laptop, keeping large media out of the critical path when only the database needs restoring, and knowing roughly how big each site's backup is before the day you need it.
7. Restoring
The part everyone pictures. Files go back, the database is imported, configuration is adjusted. For a typical small site with a well-organised backup, this can be one of the shorter segments. It stretches when the restore runs into limits: a database import that times out through a browser-based tool, an upload limit that refuses a large archive, file permissions that come back wrong, or a restore that depends on WordPress itself being able to load.
That last one is worth thinking about. A restore that runs from inside the WordPress admin needs a working admin. If the outage is a fatal error or a broken database, that path is closed, and you are suddenly doing a manual restore over SFTP and the command line with no rehearsal. What shortens it: having at least one restore path that does not depend on the broken site, and knowing how to use it.
While the restore runs, put up a proper maintenance response. An HTTP 503 status with a Retry-After header tells browsers and search engines the outage is temporary, which is better for search visibility than a page that returns an error or a normal-looking page with broken content. Google's own guidance treats a 503 as a signal to come back later.
8. Propagation
The site is fixed on the server, and visitors are still seeing the broken version. This is propagation, and it catches many people by surprise.
Caches are the usual cause. A page cache plugin, a host-level cache, an object cache, PHP opcache and a CDN can each keep serving old content until they are cleared or expire. If the restore involved moving to a new server, DNS adds its own delay, governed by the record's TTL (time to live), and resolvers that cached the old address will keep sending some visitors there until it runs out.
What shortens it: a written list of every cache layer on each site and how to purge it; lowering DNS TTLs ahead of any planned move; and testing in a private browser window, because your own browser cache can make the site look fixed or broken when it is neither.
9. Verification
A site that loads is not the same as a site that works. Verification is checking the things that matter: forms send, checkout completes, logins work, emails go out, scheduled tasks still run and the backup job itself is running again.
Skipping this segment does not save time. It just moves the time to later, when a customer reports that the contact form has been silently failing since the restore. What shortens it: a fixed checklist per site, so verification is a ten-minute routine rather than an improvised hour.
Which segments are fixed and which can shrink?
Not every segment responds to effort in the same way. It helps to sort them.
The pattern is clear when you look at it. Most of the segments that make outages long are not technical problems. They are preparation problems. Monitoring, an on-call order, a password vault, a note saying where backups are, a purge list and a checklist are all things that cost very little and take an afternoon to set up. They also happen to be the segments where the most hours hide.
Keep a time ledger
The simplest way to make all of this real is a time ledger: a small table per site that records how long each segment took the last time it was measured, and what you are doing about the slowest one.
Fill in the target with what you would be happy with. Fill in the last measured column only with times you actually observed, from a real outage or a rehearsal. Leave it blank if you have never measured it. A blank cell is honest and useful. It tells you exactly where you are guessing.
After each outage or rehearsal, update the row and pick one fix for the slowest segment. One fix per round is enough. Over a year, that steady trimming is what turns a long, messy outage into a short, boring one.
Measure it before it happens
Waiting for a real outage to fill in your ledger is a slow and expensive way to learn. The better route is a rehearsal: a planned restore to a staging copy, timed from start to finish, with every segment you can simulate.
Some segments rehearse well. Getting in, finding the backup, moving the data, restoring, propagation on a staging domain and verification can all be timed honestly on a quiet afternoon. Detection and reaching the right person are harder, but you can still test them. Take a staging site down on purpose and see how long the alert takes to reach someone, and whether it reaches the right someone.
Rehearse under conditions that look like a real outage, not a calm one. Assume the WordPress admin will not load. Assume the person who usually does this is away. That is where hidden waiting shows up. If you want a structure to follow, there is a good WordPress restore runbook written for 2 a.m. conditions on the BackupYourSite blog. It starts from triage, ranks restore paths by how much they depend on things that might also be broken, and closes with a quarterly drill that records your recovery time as a measured number rather than a hope.
Write the times straight into the ledger. The first rehearsal is often humbling. That is the point. Every minute it finds in a rehearsal is a minute you will not spend during a real outage.
The segments people forget
Three things sit outside the nine segments but change how long an outage feels and how much it costs.
Communication
While the site is down, someone has to tell customers, the client or the team what is going on. Writing that message from scratch in the middle of an incident takes longer than you would think, and it pulls attention away from the fix. A short pre-written status message, with blanks for the time and the expected return, saves that effort. So does deciding in advance where it gets posted.
Partial service
Not every outage has to be all or nothing. A static holding page that shows contact details and a phone number keeps some value flowing while the full site is restored. For a store, even a page that tells people when to come back is better than an error. This does not shorten the outage, but it can cut what the outage costs per hour.
The after-hours effect
The same outage takes longer at 2 a.m. than at 2 p.m. People are slower, harder to reach and more likely to make mistakes. Support queues at hosts and agencies may be thinner. Emergency rates for outside help are often higher. If your sites can fail at night, your plan has to work at night, which is the strongest argument for writing everything down and for restore paths that a tired person can follow.
Cheap fixes, ranked by hours they tend to save
If you only have one afternoon, here is a reasonable order of work. The ranking is a general guide, not a measured result, and your own ledger will tell you where your sites differ.
10. Add external uptime monitoring with alerts to a person. This attacks detection, which is often the longest segment on small sites.
11. Write a one-page note per site. Where the backups are, how to log in to everything, who is on call, where the error log lives. This cuts several segments at once.
12. Put credentials in a shared vault and test them. Access friction disappears when two people can always get in.
13. Make sure at least one backup copy lives away from the site. This keeps the backup reachable when the server or account is the problem.
14. Have a restore path that does not need WordPress to be running. This keeps the restore segment short on the outages that hurt most.
15. Write a cache purge list. Five minutes to write, and it saves the "it's fixed but still broken" confusion.
16. Write a verification checklist. This stops verification from turning into a second outage days later.
17. Run one timed rehearsal. Then fill in the ledger with real numbers.
What not to confuse this with
It is easy to mix up recovery speed with backup frequency. They are different numbers that answer different questions. How often you back up decides how much data you can lose, usually called the recovery point objective (RPO). How quickly you can restore decides how long you are down, usually called the recovery time objective (RTO).
Backing up every hour does nothing for a site that takes nine hours to be noticed and three hours to log in to. And a site that can be restored in twenty minutes still loses a day of orders if its newest backup is a day old. Both numbers matter, and improving one does not improve the other. This article is about the second one, because it is the one most often left to chance.
Conclusion
Long outages are rarely long because the problem was hard. They are long because the time between "something broke" and "it's fixed and checked" is full of waiting, and most of that waiting is preparation that never happened. Nobody noticed. Nobody could log in. Nobody knew where the backup was. Nobody remembered the CDN.
Split your next outage, or better, your next rehearsal, into its segments and time each one. Put the numbers in a ledger. Fix the slowest segment, then the next. The cost of an hour of downtime is mostly out of your hands, but the number of hours is not, and those hours are where your real savings are.
