Website Downtime Tracker: Downtime Logs and Uptime History

How to track website downtime and keep a record of every outage

To track website downtime, point an external monitor at every URL you care about, set a check interval of 60 seconds, and let it write each failed check into an incident log with a start time, an end time and a duration. TrackDowntime does that for websites and APIs, stores the status code and response time on every check, and keeps the uptime history per endpoint so the record already exists the day somebody asks for it.

Last updated September 2026

60s

Between checks on Professional and Enterprise

3

Timestamps per incident: first failure, recovery, duration

365+

Days of history on Enterprise, with no cap

What a downtime tracker has to record to be worth anything later

Plenty of tools will tell you a site is down. Far fewer keep a record you can still use three months later, when the hosting invoice arrives or a client asks why their traffic dropped on a Tuesday. These are the things that decide whether the history is evidence or just a feeling.

A start time, an end time and a real duration

Every incident is stored with the moment the first check failed, the moment a check succeeded again, and the measured gap between them. That is a duration, not an estimate. When a provider says the outage was brief, you have the two timestamps that decide the argument.

The status code that came back

A 500 is a broken application. A 502 or 504 usually means the web server never got an answer from the thing behind it. A connection timeout points at DNS, the network or a firewall. The tracker stores what actually came back on each check, so the log narrows down the cause instead of only proving the symptom.

Response time on every single check

Sites rarely fall over without warning. They get slower first. Because response time is recorded on every check and not only on failures, a page that has drifted from 400ms to 2.6s over a month is visible in the history weeks before it starts timing out.

Measurement from outside your hosting

Checks run from monitoring nodes that have nothing to do with your server, your CDN account or your host's internal dashboards. That independence is the whole point of the record. A log kept by the same company that caused the outage settles nothing.

Uptime percentage over any period you pick

The tracker adds up the logged incidents against the checks that ran, so you get an uptime figure for last week, last month or the quarter, per endpoint. That is the number that goes in a client report or gets compared against a 99.9 percent guarantee.

History that stays around long enough to use

Retention is where cheap tools quietly fail you. TrackDowntime keeps 30 days on Starter, 90 days on Professional and keeps the full history with no cap on Enterprise. Pick the plan by how far back you will need to look, not only by how many sites you run.

Setting up downtime tracking on the sites that matter

Step 1

Add every URL that can cost you money

Not just the homepage. Add the checkout, the booking page, the login endpoint and the API base URL as separate endpoints. Each one gets its own incident log, which is what lets you say the site was fine but checkout was down for 22 minutes.

Step 2

Set the interval to 60 seconds on anything revenue facing

The interval sets the resolution of your record. A monitor that checks every 5 minutes can only ever tell you an outage was somewhere between 1 and 10 minutes long. At 60 seconds, the log is accurate to the minute, which is the difference between a claim a host accepts and one they argue with.

Step 3

Add the phone number that should ring

Tracking and alerting belong on the same endpoint. When a check fails twice in a row, TrackDowntime places an automated voice call, sends an SMS and emails you, and keeps escalating until a check succeeds again. The same incident that wakes you up is the one written to the log.

Step 4

Read the history before you need it

Open the endpoint once a month rather than only after a bad night. Repeated short outages at the same hour usually mean a cron job, a backup window or a noisy neighbour on shared hosting. That pattern is the most useful thing a downtime tracker gives you, and it is invisible unless somebody looks.

A downtime tracker earns its money the day somebody disputes an outage

The reason to keep a downtime log is not curiosity. It is that three separate conversations go badly without one, and all three involve money.

The first is the hosting bill. Most managed hosts publish an uptime guarantee, usually 99.9 percent, and most of them will issue a service credit when they miss it. Almost none of them issue it automatically. You have to ask, and you generally have to ask with dates and durations attached, often within a short window after the incident. If your only record is the memory of a bad Saturday, you do not get the credit. If you have a dated incident log from a monitor that has no relationship with your host, the conversation is short.

The second is the client. Agencies that bill a monthly retainer get asked, sooner or later, what exactly the retainer covers. An uptime figure per site, with the incidents listed underneath, answers that in one screen. It also protects you in the other direction: when a client insists the site was down all afternoon and it was their office network, the log says so.

The third is the renewal. Hosting contracts get renewed on impressions rather than data. Six months of tracked history turns that into a decision you can defend, because you can see whether the outages are clustering, getting longer, or landing at the same time every week. If you want the alerting side of that record as well, the downtime alerts by phone call page covers how the escalation works while an incident is still open.

Why your hosting provider's status page is not a record of your downtime

Status pages are marketing surfaces that happen to contain facts. They are updated by the same people who are, at that moment, busy fixing the thing that broke. They report at the level of the platform, not your account, so a failure that took down one node, one PHP-FPM pool or one site's database connection often never appears at all. And they are edited after the fact.

There is a more basic problem. A status page tells you about the provider's infrastructure. Your visitors do not buy from the infrastructure, they buy from your site. Plenty of outages happen with the server perfectly healthy: an expired certificate, a bad deploy, a plugin update, a DNS change that propagated badly, a WAF rule that started returning 403 to real customers. The host's status page stays green through every one of those.

External monitoring measures the thing the customer experiences, from outside your network, on a fixed schedule, and writes it down whether or not anyone is watching. That is what makes it a record. It is the same reason nobody accepts a self reported meter reading.

Check interval decides how precise your downtime log can be

This is the single most misunderstood setting in monitoring, and it is worth being blunt about it, because it determines whether your history is usable.

A monitor only knows what happened at the moments it checked. With a 5 minute interval, an outage that began at 02:03 and ended at 02:07 might be recorded as starting at 02:05 and ending at 02:10, or missed entirely if both checks happened to land in the working window. Your log will be wrong by up to two intervals in each direction. For a short outage, that is a margin of error larger than the outage.

At 60 seconds the error is bounded at roughly a minute at each end. That matters in two places: SLA claims, where a provider will happily argue about a five minute uncertainty, and pattern spotting, where brief repeated failures are exactly the signal you are trying to catch and a coarse interval smooths them into nothing.

TrackDowntime runs 5 minute checks on Starter and 60 second checks on Professional and Enterprise. If the endpoint carries revenue or sits behind an SLA you have signed, put it on the 60 second interval. If it is a marketing microsite, 5 minutes is honest enough. The uptime monitor pricing page lists the interval and endpoint count on each plan.

Tracking many sites at once without losing the per site record

The moment you pass about ten endpoints, downtime tracking becomes a reporting problem rather than a monitoring one. Everything is in one list, everything looks fine at a glance, and the thing that goes wrong is the site nobody has opened in a month.

Two habits fix most of it. Keep endpoints named after what breaks, not after the domain, so an incident log reads "acme checkout" rather than "acme.com 3". And separate the paths within a site, because an application can be up while the one page that takes payments is not, and a single homepage check will never tell you that.

For agencies and internal IT teams running client portfolios, the per client sizing, the endpoint maths and what it works out to per site are covered on the website monitoring for agencies page. Enterprise also carries white label reports, which is what you want if the uptime history is going out under your own brand rather than ours.

Who tracks downtime, and what they do with the log

Agencies reporting to retainer clients

One account, every client site as its own endpoint, an uptime figure and an incident list per site each month. It turns the awkward question about what the retainer buys into a one screen answer, and it catches the client site that has been failing quietly since a plugin update.

Stores working out what an outage actually cost

An ecommerce operator matches the logged outage window against the order timeline and the ad spend for those hours. Knowing the checkout was unreachable from 01:12 to 01:51 turns a vague bad night into a number, and gives you something concrete to take to the host or the platform.

IT managers deciding whether to renew a host

Six months of independent history per site, showing frequency, duration and time of day. That is the difference between renewing on habit and renewing on evidence, and it is also the leverage you need if you would rather negotiate than migrate.

SaaS teams with uptime commitments of their own

If you promise customers 99.9 percent, you need your own measurement of the API rather than your cloud provider's. Per endpoint history on the routes customers actually call gives you the number before your customers calculate it for you.

Freelancers and consultants defending their work

When a site you built goes down, the first assumption is usually that you broke it. An independent log that shows the outage started at 4am on a night nobody deployed anything moves the conversation to the host, which is where it belongs.

Anyone about to renegotiate a hosting contract

Walk into the renewal with the previous quarter's incidents per site: how many, how long, and what time of day. It is the one thing that reliably changes the price, because the provider can see you are measuring.

How much downtime history each plan keeps

Retention and check interval are the two settings that decide how useful the record is. Both are set by the plan, so it is worth picking on the basis of how far back you will need to look rather than on endpoint count alone. Prices are monthly; annual billing is roughly half.

Plan	Endpoints	Check interval	History kept	Alerts included
Starter, $29/mo	5	5 minutes	30 days	Email
Professional, $99/mo	25	60 seconds	90 days	Phone call, SMS, email
Enterprise, $299/mo	Unlimited	60 seconds	No limit	Phone call, SMS, email

Alerts are never billed per message on any plan, so a bad month costs the same as a quiet one. SSL certificate expiry monitoring and response time history are included on every plan.

Questions people ask before setting up downtime tracking

How do I track website downtime?

Put the site under an external monitor that checks it on a fixed interval from outside your hosting, and make sure it writes every failed check to an incident log with a start time, an end time and a duration. Checking manually or relying on your host's dashboard does not produce a record, because nothing is written down when nobody is looking.

Add each important path as its own endpoint rather than only the homepage, so the log can distinguish a site being slow from a checkout being unreachable.

How do I check my website's downtime history?

Open the endpoint in your monitoring tool and read its incident list. Each entry should show when the first check failed, when the site answered again, and the duration between the two, alongside the status code that came back. In TrackDowntime that history sits on the endpoint itself and is kept for 30 days on Starter, 90 days on Professional and without a limit on Enterprise.

History only exists from the moment monitoring starts. There is no way to reconstruct outages from before an endpoint was added, which is the practical argument for setting it up on a quiet day rather than after a bad one.

How do I check a website downtime percentage?

Uptime percentage is the share of successful checks over a period, so it comes from the same log as the incidents. Pick the window you care about, usually a calendar month, and read the figure for that endpoint. A 99.9 percent month allows about 43 minutes of downtime, and 99 percent allows about 7 hours 18 minutes, which is why the gap between those two numbers matters more than it looks.

What does a website downtime tracker record?

For every check: the timestamp, the HTTP status code and the response time. For every incident: the first failed check, the recovery, the total duration and the endpoint it belongs to. That combination is what lets you show a hosting provider exactly when the site was unreachable, and what lets you notice a page getting slower long before it starts failing.

Can a downtime log prove downtime to my hosting provider?

It is the evidence most providers ask for. Uptime guarantees are almost never paid out automatically, and the credit request usually needs dates, times and durations, sometimes within a short window after the incident. An independent third party log satisfies that because it was not produced by the provider being asked to pay.

The provider's own SLA terms still decide how much credit you get and how you claim it, so read the agreement before you calculate what you are owed.

How often should a downtime tracker check my site?

Every 60 seconds for anything that takes money or sits behind a signed SLA, and every 5 minutes for lower stakes pages. The interval sets the accuracy of your record: a 5 minute check can be wrong about the start and end of an outage by up to five minutes in each direction, which is enough uncertainty for a provider to dispute a short incident.

Is downtime tracking the same thing as downtime alerts?

No, and running one without the other is the common mistake. Alerts are what happens during an incident, and their job is to reach a human fast enough to shorten it. Tracking is what survives afterwards, and its job is to make the pattern visible and the outage provable. TrackDowntime does both from the same check, so the incident that places the phone call is the one written into the history.

Does tracking downtime slow my website down?

No. The monitor makes an ordinary HTTP request from outside your infrastructure, once per interval. At 60 second checks that is 1,440 requests a day, which is a rounding error next to normal traffic and less load than a single search engine crawl. Nothing is installed on your server and no agent runs on it.

Start the record now, not after the next outage

A downtime tracker can only show you history it was running for. Add your first endpoint, set the interval, and the log starts filling from the next check. Starter is $29 a month for 5 endpoints with 30 days of history. Professional is $99 for 25 endpoints at 60 second checks, 90 days of history and phone call alerts.

Compare plans

Keep reading

Downtime alerts by phone call

What happens while an incident is still open: an automated call, SMS and email that repeat until the site is back.

Website monitoring for agencies

Running a client portfolio from one account, endpoint sizing per client and what it works out to per site.

Uptime monitoring pricing compared

What monitoring tools charge in 2026, the real cost per site, and the fees that inflate the invoice.

Downtime monitor features

How the checks, the alerting and the uptime history fit together across websites and APIs.

Website Downtime Tracker: Downtime Tracking Software With Incident Logs and Uptime History