Unmonitored downtime is downtime you do not get to bound
Unmonitored downtime is an outage whose length is decided by chance rather than by you: it lasts from the moment the failure starts until the moment somebody happens to look. The technical fault is identical either way — an expired certificate, a bad deploy, a full disk, a lapsed domain. What changes is the duration, and duration is what you are billed for in lost orders.
That is why the same failure can cost fifteen minutes on one site and three days on another. A monitored site converts a failure into an alert within minutes. An unmonitored site converts it into a discovery, and discoveries happen on their own schedule — Monday morning, after a long weekend, when a customer finally emails to ask whether you have gone out of business.
Why nobody tells you the site is down
The intuition that "someone would have said something" is the single most expensive assumption in this area. A visitor who hits a broken checkout does not open a support ticket; they leave and buy elsewhere. Only a small minority of affected users ever contact you, and they contact you late — after they have tried twice, assumed it was their connection, and given up. A quiet inbox during an outage is the normal case, not the reassuring one.
Your own instruments will not raise their hand either. Analytics show fewer sessions, which looks like a slow day rather than a broken one. Server dashboards can be perfectly green while DNS, a CDN, or a certificate makes the site unreachable from outside. Even you may not notice: your browser has the page cached, your DNS resolver has a stale answer, and your office network takes a different path than your customers do.
Do the arithmetic for your own site
You do not need an industry statistic to size this — your own numbers are better, and the calculation takes two minutes. Take the revenue you expect in the window that was affected and multiply by the share of it that depends on the broken page. For a storefront the fine-grained version is: sessions per hour × conversion rate × average order value = revenue per hour at risk. Multiply by the hours of the outage.
To illustrate the shape of it: a store seeing 900 sessions an hour at a 2% conversion rate and a $60 average order is putting roughly $1,080 an hour through that funnel. Detected in 10 minutes, a checkout failure costs on the order of $180; discovered the next morning after nine hours, the same failure costs closer to $9,700. The fault was the same size in both cases. Only the detection time differed.
Two corrections make the estimate honest. First, traffic is not flat — an outage during your peak hours costs several times what the same outage costs at 4 a.m., so use the sessions in the affected window rather than a daily average. Second, not every lost session is a lost sale; some customers come back. Subtract a recovery share you actually believe, and the remaining number is still usually large enough to end the argument.
The costs that keep arriving after the site comes back
Missed orders are only the visible part of the bill. Paid traffic keeps spending while the landing page is broken, so every click during an outage is money converted directly into a bounce. Search crawlers that repeatedly meet server errors on a page will slow their crawling of it, which delays how quickly your content is refreshed in the index. Abandoned carts and failed payments generate support work later, at a worse ratio than an order would have.
Then there is the part you cannot invoice: a customer who hit a security warning on your domain has no way to tell a lapsed certificate from a compromised site. Trust is cheap to keep and slow to rebuild, and it decays fastest during the outages you did not know about, because those are the ones nobody was there to explain.
Detection time is the part you control
You cannot prevent every failure — dependencies break, certificates expire, providers have bad days. What you can decide in advance is how long a failure runs before somebody knows. That is time to detect, and it is the cheapest reliability improvement available: no architecture change, no new infrastructure, just an outside-in check on a schedule.
Availability arithmetic makes the leverage explicit. Availability is MTBF ÷ (MTBF + MTTR), so every minute cut from recovery counts exactly as much as a minute of failure prevented — and the first thing recovery waits on is detection. A five-minute check bounds discovery to minutes. In PageLantern, an incident opens after two consecutive failed checks by default, and HTTP, HTTPS, API, and content checks are confirmed from a second region before that incident opens, so the alert you get at 2 a.m. is worth standing up for.
Cover the pages that take money first
Start where a failure has a price tag rather than trying to cover everything at once. Put an HTTP check with a content assertion on the home page, a key product or pricing page, and the cart or sign-up step — asserting on the status code and a string that only appears when the page really rendered, because a broken page that still returns 200 is the classic silent outage. Add certificate and domain-expiry monitoring, since both are time bombs that take the whole site down at once and give no warning in your logs.
Then cover what happens behind the page: an authenticated API check on the endpoint your checkout depends on, and heartbeat monitors on the scheduled jobs — order exports, payment reconciliation, nightly backups — whose failure you would otherwise discover days later. On paid plans, hosted browser checks can walk a storefront journey and capture a screenshot when it breaks; they exercise the path up to checkout rather than placing real orders. Send the alerts somewhere a human actually reads, and publish confirmed incidents to a status page so customers stop guessing.