If nobody was monitoring the site, there is no trustworthy record of when it last went down. Downtime is not logged anywhere central, no authority keeps a register of outages, and the internet does not remember which sites were unreachable last Tuesday. What exists instead is five partial sources that can reconstruct fragments of the picture, each measuring something slightly different from what you are asking about.
This article covers each source and what it actually proves, explains the specific ways they mislead people, and closes with the only method that produces a reliable answer, which is the one you have to start before you need it.
The five sources, in order of reliability
Your own monitoring history. If a monitoring service was watching the site, this is the answer and everything else on this list is a workaround. A check running at a known interval produces a timestamped record of every failure with its duration, and it is the only source that measures reachability directly rather than inferring it.
The site's own status page and incident history. Most serious services publish an incident archive with start times, durations, and postmortems. This is authoritative for what the operator acknowledged, which is a narrower thing than what happened. Short outages often go unrecorded, partial failures are frequently described as degraded performance rather than downtime, and status pages hosted on the same infrastructure as the service can be down during the very incident they should be reporting.
Server logs, if it is your site. A gap in access logs is strong evidence that requests were not being served, though it cannot distinguish an outage from a quiet night. Application error logs are better, and an error rate spike with a start and end time is close to a real record.
Crowd-sourced outage trackers. Downdetector and similar services aggregate user reports, which makes them useful for large consumer services and nearly useless for anything else. They measure complaints rather than availability, so a site with few users generates no signal regardless of how down it was.
The Internet Archive. The Wayback Machine records the pages it captured and when it captured them. A snapshot proves the site was reachable at that moment. A gap proves only that the archive did not crawl during it.
How each one misleads people
The failure mode is the same across all five: mistaking a proxy for a measurement. Crowd-sourced trackers are the worst offender. A quiet Downdetector graph is regularly cited as proof a site was fine, when it usually means nobody who was affected bothered to report it. For a business tool used by a few thousand people, an outage can be total and the tracker will show nothing at all.
The Internet Archive misleads in the opposite direction. Its crawl schedule is irregular and driven by its own priorities, so gaps between snapshots are almost always crawl gaps rather than outages. A three week hole in the archive of a small site is entirely normal and says nothing about availability. Status pages mislead through incentive: the operator decides what counts as an incident, when it started, and when it ended, and those judgments are made by people whose service credits depend on them. That is not necessarily dishonesty, but it is a reason to treat a vendor's own uptime figure as a claim rather than as data.
Server logs mislead through absence. Low traffic at four in the morning looks like an outage, and a site serving cached responses from a CDN can produce healthy edge logs while the origin is dead. Search Console crawl error reports have the same shape: they tell you Googlebot had trouble, at a resolution measured in days, which is too coarse for most questions people actually have.
Reconstructing a specific incident
When you need to establish what happened during one particular window, the technique is triangulation rather than trusting any single source. Start with whatever direct record exists, then look for corroboration in things that leave timestamps as a side effect.
Certificate transparency logs record when certificates were issued, which sometimes explains an outage caused by a renewal. DNS history services show when records changed, which frequently correlates with a period of partial unreachability. Deployment and change logs, if you have access to them, are the highest-value corroboration available, because most outages begin with a change. Support ticket volume and its timestamps are a surprisingly good proxy for user-visible impact. Social media posts complaining about the site carry timestamps and are often the only public record of a small service's outage.
None of these measures uptime. All of them place events on a timeline, and enough events on a timeline usually reveal the shape of an incident well enough to act on. What they will not give you is a duration you would want to put in a contract dispute, which matters when the reason you are asking is that a vendor missed an availability commitment. In that situation, independent monitoring you ran yourself is the difference between a position and an opinion.
The only answer that actually works
The honest conclusion is that this question has no good retroactive answer and an excellent prospective one. Monitoring is cheap, takes a few minutes to configure, and produces exactly the record that no amount of forensic work can reconstruct afterwards. Every one of the workarounds above exists because somebody needed a record that nobody was keeping.
This applies with particular force to services you depend on but do not control. If a vendor's uptime matters enough that you would want to prove a breach, or enough that you need to know whether last month's problems were them or you, independent monitoring is the only thing that will answer it, and it has to have been running at the time. Setting it up costs less than a single hour spent reconstructing an incident from social media timestamps, and unlike that hour, it works. For the live version of the question rather than the historical one, our guide to checking whether a website is down covers what to do right now.
Common mistakes in investigating past downtime
Treating Downdetector silence as proof of uptime. It measures user complaints, not availability. A site with a modest audience can be completely down and generate no reports at all.
Reading Wayback Machine gaps as outages. The archive crawls on its own irregular schedule. A gap between snapshots almost always means it did not visit, not that the site was unreachable.
Accepting a vendor's uptime figure as data. The operator decides what counted as an incident and when it started and ended, with service credits on the line. Treat it as a claim to be corroborated.
Confusing quiet traffic with an outage. A gap in access logs at four in the morning is usually a gap in visitors. Error rates and monitoring records distinguish the two; raw request volume does not.
Starting monitoring after the incident you needed it for. The record you want can only be created in advance. Every retroactive method on this list is a partial substitute for a check that was not running.
FAQ
Is there a website that shows the outage history of any site?
No general one exists. Crowd-sourced trackers cover large consumer services through user reports, and individual operators publish their own incident histories, but there is no central registry of availability for arbitrary sites.
Can I find out if a website was down yesterday?
Only through indirect evidence unless somebody was monitoring it. The site's status page, your own logs if it is your site, crowd reports for large services, and timestamped support tickets or social posts are the available sources.
Does the Wayback Machine show when a site was down?
Not reliably. It shows when the archive successfully captured pages. A gap usually reflects the crawler's schedule rather than an outage, and a snapshot only proves the site was reachable at that one moment.
How far back does uptime monitoring history go?
As far back as the monitoring was running, and no further. Retention varies by provider, but no service can report on a period before you started checking, which is why the setup is worth doing before you need the data.
Closing thought
The reason this question is so hard to answer well is that availability is a property of moments rather than an artefact that gets stored somewhere. Every source in this article is a fossil, and reading fossils tells you something about what happened without ever telling you precisely when or for how long. That is usually enough to form a theory and rarely enough to settle an argument.
Which makes the practical response simple, if slightly unsatisfying: start the record now. Odown checks the sites and services you care about from seventeen locations, keeps a timestamped history of every failure and its duration, and does it for yours and for the third parties you depend on. If you have just spent an afternoon trying to reconstruct an outage from other people's timestamps, website monitoring starts at twelve dollars a month with a fourteen day trial and no card required.
