Why checking uptime is not optional

You will find out that your site is down. The only question is whether you find out from a monitor in ninety seconds or from a customer in nine hours. Here is what that gap actually costs.

Every website goes down. Yours will go down this year, and the year after, and the question was never whether it happens.

The question is how you find out.

There are only two ways. Either a machine tells you within a minute or two, or a human tells you — and the human is a customer, they have already had the bad experience, they are already annoyed, and by the time they have found your contact form and typed something the outage is hours old.

That gap is the entire subject of this post. Everything else is detail.

The gap is much longer than people think

Ask a team without monitoring how they would find out about an outage, and the common answer is "someone would notice pretty quickly".

Rarely true. Consider what has to happen for a customer to tell you:

1. They have to visit while it is broken.
2. They have to care enough to not simply leave.
3. They have to work out that the problem is yours and not their wifi.
4. They have to find a way to contact you — which, note, is often a form on the website that is currently down.
5. Someone on your side has to read that message.

Every one of those steps loses most of the people who reach it. Estimates vary by industry, but the shape is consistent: the overwhelming majority of users who hit a broken site simply leave and do not report anything. You are relying on a rare, motivated, patient person to act as your alerting system.

And the timing is against you. Outages are not evenly distributed across the day; they cluster around deploys, scheduled jobs and traffic peaks. A deploy at 18:00 on a Friday that breaks the checkout flow will be discovered on Monday morning by a team wondering why the weekend was so quiet.

The realistic numbers for an unmonitored site are: minutes to detect if you are lucky and someone happened to be looking; hours if it happens outside working hours; days if the broken thing is a page people reach rarely, or a scheduled job with no visible output, or an API used by one integration partner who assumed the errors were their fault.

With monitoring, the same numbers are: 30 to 90 seconds, consistently, at 04:00 on a bank holiday, whether or not anyone happened to be looking.

What the gap costs

There is a standard way to talk about this, and it is worth doing the arithmetic for your own numbers rather than accepting a figure from an industry report.

Direct revenue. If your site takes money, take your monthly revenue, divide by the hours you actually trade, and you have a rough hourly figure. A shop turning over £40,000 a month is losing something in the region of £55 an hour of full outage, and considerably more if the outage lands in a peak. Six hours undetected on a Saturday is not a rounding error.

Acquisition spend, burned live. This one is routinely missed. If you are running paid advertising, that spend continues during an outage. Every click you pay for during those hours lands on a broken page. You are not merely failing to convert; you are paying full price for the privilege. For a business spending even modestly on ads, a few hours of undetected downtime can cost more in wasted clicks than in lost sales.

Search. Google's crawler does not know you are having a bad day. If it arrives during an outage it records what it finds. A short outage is generally harmless — Googlebot retries, and a 503 handled correctly is understood as temporary. A long one, or a pattern of them, is a different matter: repeated failures can lead to reduced crawl rate, and pages that consistently fail to serve can eventually drop out of the index. Recovering rankings takes far longer than recovering the server.

Trust, which does not have a line in the accounts. This is the expensive one and the hardest to argue for. A customer who hits a broken checkout once will usually come back. A customer who hits it twice has learned something about you and will hesitate before relying on you again. For B2B services the effect is sharper still, because your outage is your customer's outage, and they have to explain it to their customers using information you have not given them.

The failures that hide

If the only argument for monitoring were "the website might go offline", you could half-justify skipping it — total outages are usually noticed eventually.

The stronger argument is the class of failures that are invisible by design.

Certificates. A TLS certificate expires at a precise moment, and at that moment every visitor starts seeing a full-page browser warning describing your site as unsafe. The server is fine. Every process is running. Monitoring that checks only "did the server respond" sees nothing wrong. Meanwhile your traffic goes to approximately zero, and the people who see that warning are being told, in the strongest language browsers have, not to trust you. This failure is entirely predictable — it has a date on it — and it still takes down real companies every year. It only needs something watching the expiry date.

Domain renewal. Worse than a certificate, because the recovery is not in your hands. A lapsed domain can take days to restore, and during those days your email stops working too, which means the renewal warnings you are being sent are going somewhere you cannot read them. Domain expiry monitoring is close to free and prevents a genuinely catastrophic, entirely avoidable failure.

Scheduled jobs that stop. This is the quietest failure in software. A nightly backup, a billing run, a data export, a cache warm — these things succeed silently and, when they break, fail silently too. Nobody notices the absence of an event. The classic version is the backup job that stopped running in March and is discovered in September by someone trying to restore from it. A cron heartbeat inverts the logic: the job checks in when it finishes, and the absence of a check-in is what raises the alarm.

Working pages that are wrong. Covered at length in what is uptime, but it bears repeating because it is the most common blind spot in real monitoring setups: a page that returns HTTP 200 and contains the words "Database error" is down, and a check that only reads the status code will report it as up indefinitely. So will a checkout page that loads perfectly and whose payment provider is refusing every transaction.

Slow, which is down with extra steps. A page that takes fourteen seconds is functionally unavailable to most of the people who try it. They leave before it finishes. If your monitoring has no opinion about response time, you can degrade from snappy to unusable over weeks without a single alert firing.

"We have a status page" is not monitoring

A hand-updated status page tells your customers what you already know. It is a communication tool, and a good one, but it is downstream of detection. If a human has to notice a problem before the status page changes, the status page cannot tell you about problems.

The useful arrangement is the other way round: monitoring detects, and the status page reflects what monitoring found. Then the page is accurate at 04:00 without anyone waking up, and your customers can answer their own question instead of filling in your contact form — which, again, may be on the site that is currently down. That is why status pages are attached to the monitoring here rather than sold as a separate product.

The costs that outlast the outage

The revenue arithmetic above is the part people model. The costs that persist after the site comes back are usually larger and almost never counted.

Search engines were also visiting. A crawler that hits a 500 during an outage will retry, and a short incident costs nothing. A repeated pattern of errors and timeouts does eventually affect how often you are crawled and how your pages are assessed, because slow and unreliable is a signal about quality whether or not you intended it as one. The site that is intermittently down for four hours a month is quietly paying for it in traffic it never sees.

Trust is asymmetric. A customer who has watched your checkout fail once will remember it for longer than your uptime average deserves. This is why the difference between "we posted about it within two minutes" and "several people emailed us before we noticed" matters out of all proportion to the minutes involved. The first reads as a company operating its service; the second reads as a company that does not know what its service is doing.

The recovery is worse when detection is late. An outage caught in ninety seconds is usually still attached to its cause — the deploy that just finished, the certificate that just expired, the disk that just filled. Nine hours later the trail is cold, the logs may have rotated, and you are debugging archaeology. Fast detection does not just shorten the outage; it makes the fix cheaper.

And the second one is free. Almost every failure listed above recurs. A monitor that caught the cause once turns the second occurrence into a five-minute fix by someone who recognises the alert. Detection compounds.

The objections, taken seriously

"We're too small for this." Smallness is the argument for it. A large company has an operations team, an on-call rota and probably four monitoring systems. A three-person company has none of that, which means an outage runs until someone happens to look. The smaller you are, the larger your detection gap, and the more of your revenue a single bad Saturday represents.

"Our host monitors it." Your host monitors their infrastructure, and they are checking that the machine is up and the network reachable. They are not checking whether your application returns the right page, whether your certificate is valid, or whether last night's deploy broke the signup form. Their monitoring protects their SLA, not your business.

"It's another subscription." It does not have to be. The free tier here covers fifty monitors permanently — with every check type and a status page, not a crippled sample of them — which is more than most small businesses will ever need. If cost is the blocker, the blocker is removable. See pricing.

"We'll get alert fatigue." This is the only objection that describes a real risk. A monitoring system that pages you for every transient network blip will be muted within two weeks, and a muted monitor is worse than none, because you still believe you are covered. The answer is not to skip monitoring; it is to insist on confirmation from a second location before anything pages a human, and to be deliberate about which failures are worth waking someone for. How to check status properly is largely about exactly this.

The actual minimum

If you do nothing else, do these four. It is twenty minutes of work and it covers the overwhelming majority of what actually goes wrong:

1. An HTTP check on your homepage that asserts on a word which only appears when the page has genuinely rendered — not merely on a 200.
2. An HTTP check on the one page that makes you money: checkout, signup, login. This is the page whose failure is expensive and whose breakage is least likely to be noticed by you personally.
3. Certificate and domain expiry on every hostname you own. Set once, prevents two of the most embarrassing possible outages.
4. A heartbeat on your backup job. Not because backups fail often, but because the day you need one is the worst possible day to learn it stopped running in the spring.

Then set up alerts that reach you where you actually are, and — this matters more than the setup — deliberately break something on purpose to confirm the alert arrives. An untested alerting path is a guess.

Detection is not the whole of reliability. But it is the part everything else depends on, it is cheap, and going without it is a decision to find out about your outages from the people you are trying to sell to.

Start free — fifty monitors, no card, and the four checks above take about twenty minutes to put in place.