Website Downtime History: How Long Has a Site Been Down?

There is no public record of how long a website was down. Nothing indexes outages the way a registrar indexes domains, so downtime history can only be reconstructed from sources that happened to be watching: your own access logs, your CDN analytics, Google Search Console host status for the last 90 days, archive snapshots, and support tickets. Each of those gives you a fragment. Only continuous monitoring set up before the outage produces an actual timeline, which is the awkward part of the answer: the tool that answers "how long was it down" has to have been running while it was down.

The question usually arrives in one of two forms. Either something broke, you fixed it, and now a client or a manager wants to know how long it lasted. Or you are evaluating somebody else's service and you want to know how often it falls over before you depend on it. Those need different answers, so this covers both.

Why you cannot look up a website's downtime history

Availability is not a property of a website that exists somewhere waiting to be read. It is a measurement, and a measurement only exists if an instrument was pointed at the thing at the time. Nothing on the internet is systematically recording whether every site is answering requests, minute by minute, and archiving it. The closest things that exist are crowd-sourced complaint aggregators, which only register a service large enough that thousands of strangers notice simultaneously, and the site's own monitoring, which belongs to the site.

This trips people up because so many other properties of a domain are publicly recorded. Registration dates, nameserver changes and certificate issuance all leave permanent public trails. Availability leaves none. A site that was completely offline for six hours last Tuesday looks, from outside and after the fact, exactly like a site that was up the whole time.

So the practical question is not where to look it up. It is which of the systems around your site happened to write something down.

Where the evidence actually is

Read down that table and the pattern is hard to miss. Every source except the last one is a byproduct of some other system that happened to be running, and each is blind to a different layer of failure. This is the same layering that decides where you look during a live incident, which is why the website down checker reports DNS, TCP, TLS and HTTP separately rather than returning a single up or down word. An outage that leaves no trace in your application log is not a mystery, it is a failure that happened below the application.

How to reconstruct a specific outage after the fact

Work from the sources that survived the failure toward the ones that did not.

Start with whatever sat in front of the failure. If you run a CDN, its analytics are the best record you have, because the edge kept serving and kept counting while the origin was dead. Look for the point where origin errors climb and the point where they return to zero. Those two timestamps bracket the outage more tightly than anything else you will find.

Then read the gap in the access log. On a site with steady traffic, an outage is a silence: a last entry, then nothing, then a burst as everyone who was waiting reloads at once. That burst is a better recovery marker than the first ordinary request, because it is unmistakable. If your logs are already shipped somewhere queryable, this is a two line question rather than an afternoon of grep, and it is worth the trouble of getting them there before you need them. Being able to ask a question of the data in plain English and get back the count of 5xx responses per minute between two timestamps turns a forensic exercise into something you can do while the meeting is still happening.

Check Search Console for the SEO consequence. The Crawl stats report keeps host status for the last 90 days and tells you whether Google hit availability problems, whether they were in the last week or earlier, and what responses it got. This matters beyond dating the outage: Google reduces crawl rate while 5xx errors continue and restores it once healthy responses resume, so a long outage costs you crawl budget for a while afterwards. It is also the one source in this list that a client will accept as independent.

Finally, write down when you found out. Not when it broke. When somebody told you. That number is the one worth improving, and it is usually the number nobody records.

The gap nobody measures: detection delay

Every outage has two durations. There is how long the site was broken, and there is how long it was broken before anyone knew. The second one is the part you control, and on most sites it is the larger share.

If you check on a fixed interval, a failure that starts at a random moment is discovered on average half an interval later, and in the worst case a full interval later. That is simple arithmetic, and it lands harder than people expect once you put it against a monthly availability target. At 99.9 percent you have 43 minutes and 48 seconds of downtime a month in total, counting a month as a twelfth of a 365 day year.

A five minute interval spends more than a tenth of an entire month's budget before the first alert even fires, and that is on the detection alone, before anybody has read the message, opened a laptop or worked out what broke. Move the target to 99.99 percent, where the whole month allows 4 minutes and 23 seconds, and a single worst case detection at a five minute interval has already spent 114 percent of the budget. The check interval stops being a preference and becomes the thing that decides whether the target is achievable at all. The uptime calculator has the full allowance table if you want to run this against your own number.

The honest version of "how long was the site down" is therefore two numbers, and the second one is more useful: it was down for 22 minutes, and we knew about it for 4 of them. Nobody asks for the second number, and it is the only one you can do anything about.

Checking someone else's downtime history

Evaluating a vendor is the easier case, because reputable services publish it. Look for a status page with an incident archive rather than a green light, since a status page showing only the present tells you nothing about the past. Read the incident write-ups: frequency and honesty matter more than the headline percentage, and a vendor that publishes detailed postmortems for small incidents is telling you something a vendor with an empty history is not.

Treat any published uptime figure as a claim until you know how it was measured. Availability calculated from the vendor's own checks, excluding scheduled maintenance, on a monthly rather than yearly basis, is a very different number from availability measured externally across a year with maintenance counted. Both can honestly be called 99.9 percent. If it matters commercially, the fix is to measure the dependency yourself rather than to read harder, and the same monitoring that watches your site can watch the API you depend on.

What to do so the question is answerable next time

Set up an external check before you need one. The value is not really the alert, though the alert is what people buy it for. The value is that six months from now, when someone asks how often this happens, there is a record instead of a memory.

Three things worth getting right at setup. Check often enough that the interval is small compared with the downtime you would accept, which for anything commercial means 30 to 60 seconds rather than 5 minutes. Check from more than one location, so a regional routing problem does not read as an outage and a real outage is confirmed rather than guessed. And check the layers separately, watching the certificate expiry date and the DNS records as well as the status code, because the outages that cost the most are usually the ones where the server was running perfectly and something else in front of it had failed.

Then, when the question comes, the answer is a timestamp range rather than an argument. That is worth more in a client conversation than any amount of reconstruction after the fact, and it takes about ten minutes to arrange.

Common questions

Is there a website down history checker? Not in the sense people mean. Tools that describe themselves that way either show the history of checks they ran for you after you signed up, or they aggregate user reports for large consumer services. Neither can produce a history for an arbitrary site retroactively, because nobody was measuring it.

Can I see if a website was down yesterday? Only through the sources listed above, and only if you own the site or one of them happens to be public. From outside, with no prior monitoring, the honest answer is no. This is the main practical reason to monitor a dependency you care about rather than trusting that you will find out later.

How far back does Google Search Console go? The Crawl stats report covers the last 90 days for host status and the response breakdown. It is sampled at Googlebot's crawl rate rather than a fixed interval, so it dates problems to a day rather than a minute, and short outages can pass without Googlebot running into one at all.

Does the Wayback Machine show downtime? No. It shows successful captures. A missing day means nobody crawled the site that day, which happens constantly on sites that are perfectly healthy. Snapshots can prove a site was up at a moment and can never prove it was down.

How long does a website have to be down to hurt SEO? Short outages are recoverable. Google keeps URLs returning 5xx in the index for a while and drops them if the errors persist, while reducing crawl rate throughout and restoring it once healthy responses return. A few minutes is noise. A sustained outage costs you both index coverage and crawl budget, and the crawl budget takes longer to come back than the pages do.