How do you find out your site is down before a customer tells you?
In short
Being told by a customer is expensive twice: you lost the sales and you looked like you were not watching. Getting told first needs three things: a check that follows what a customer actually does, an alert on a channel you cannot miss, and enough restraint that you still believe it after a month.
Every outage has two costs. The first is the orders you did not take. The second is the sentence “your site has been down since yesterday”, written by a customer who found out before you did — and that one is paid in confidence, over a much longer period.
Why does the customer notice before you do?
Because the customer is doing something specific: buying, logging in, paying. You are looking at a dashboard, or not looking at all.
The stories are consistent. A site down for at least a day, noticed only because an unrelated third-party service happened to show Apache’s default page. Another, where the outage alert had been sent correctly and had landed in spam. In both, the monitoring was not the thing that failed: the noticing was.
Is the home page enough?
It is the minimum, and it answers a narrower question than most people think. A home page that returns 200 proves that a web server is answering on that address. It does not prove that the login works, that the basket adds, that the payment step loads, that the search returns anything, or that the order email leaves the building.
The failures that hurt an online shop are almost all downstream of the home page. So the check has to go downstream too: a saved sequence that opens a page, follows a link, submits a step and expects a particular status code or a particular word on the screen. If step four stops returning the payment page, you know before the first customer gives up.
Two more checks belong in the same group, because they fail on a calendar rather than at random: the TLS certificate, counted in days remaining, and the domain’s own expiry date. An expired certificate is a full outage for every visitor, announced weeks in advance to anyone who was counting.
What has to happen between the failure and your phone ringing?
Five things, and together they decide whether monitoring is useful or just noisy: the failure has to be confirmed, the platform’s own network problems must not be counted as your outage, the message has to reach where you are, it has to arrive once rather than nine times, and it has to come back if you forget.
It must be confirmed. A single failed check means very little: a slow moment, a packet lost, a network hiccup somewhere between the two ends. Requiring the failure to repeat, and asking a second vantage point to agree, removes most false alarms without adding meaningful delay.
It must know whose fault the network is. If the thing that lost its connection is the watcher rather than the watched, that is not your outage and must not be counted as one. Those failures should be quarantined and reported as a platform advisory, not as nine incidents on your account.
It must arrive where you are. Email is the record, not the alarm; it is filtered, folded and read in the morning. A chat message reaches you during the day. A phone call is what you want for the two or three services where an hour of silence is genuinely expensive — and it should respect quiet hours, so that the ones that do ring at night mean something.
It must not repeat itself nine times. When a server goes, everything on it goes with it. One alert for one outage, with a single recovery message, is the difference between an alert you read and an alert you mute.
It must come back if you forget. A reminder while the service is still down — after an hour, after six, then daily — catches the incident that was acknowledged at midnight by someone who then went back to sleep.
And the customers who ask anyway
While you are fixing it, somebody has to answer the phone. A public status page, with a short message written in the visitor’s own language, turns twenty interruptions into one link — and it is also the record of what happened, which you will want later, when someone asks how long it lasted.
What to do this week
- List what a customer actually does on your site: log in, search, add to basket, pay. Those are your checks, not the home page.
- Build one sequence that walks the most valuable of those paths and expects a specific word on the final step.
- Put the days remaining on the certificate and the domain expiry somewhere you will see them.
- Choose one service that justifies a phone call at 3 a.m. — just one, honestly chosen — and route it to a call.
- Write the status page before you need it. Nobody writes a good one during an outage.
The goal is not a perfect dashboard. It is that the next time something breaks, you are already fixing it when the first customer writes.
What we cannot tell you
- We cannot see whether an order confirmation reached the customer's inbox: we see that your site accepted the order, not what the mail provider did with the message afterwards.
- We cannot complete a real payment to test it: a synthetic transaction walks the steps and stops before charging anything, so what happens on the bank's side stays outside our view.
- We cannot see a queue, a cron job or a stuck import unless something on your side publishes a number we can read.
- We cannot tell you why it broke. We tell you what failed, when, from where, and what the check saw; the cause is still yours to find, with better starting information.
Questions people actually ask
How quickly would I know?
It depends on how often the site is checked — from every five minutes on the free plan down to every fifteen seconds — plus a short confirmation. A failure has to repeat on consecutive checks, and on the monitors where you ask for it a second vantage point has to see it too, before anyone is woken up. One blip never becomes a phone call.
My home page is fine but customers cannot check out. Would that be caught?
Only if something checks the checkout. A home page returning 200 proves the web server is answering, and nothing more. The check that catches it is a synthetic transaction: a saved sequence of steps — open the product, add to basket, reach the payment step — where each step has to return the expected page. It walks the path a customer walks and stops before a real charge.
What if the alert goes to spam, like last time?
Then the alert does not exist. This is the most common way an outage runs for a day: the mail was sent and filtered. Use more than one channel for the things that matter — email for the record, a chat message you read anyway, and a phone call for the handful of services that justify waking someone up. A ringing phone is the only channel that does not depend on someone looking.
How do I avoid being woken up for nothing?
By making the platform prove the outage before it escalates: consecutive failed checks rather than one, confirmation from a second location, and a rule that when our own network is the thing that broke, your service is not marked down for it. Then group what happens together — one server failing takes several monitors with it, and that should be one alert, not nine.
What about the certificate and the domain?
Both fail on a fixed date, which makes them the easiest outages in the world to prevent and the most embarrassing to have. Watch the days remaining on the certificate and the expiry of the domain itself, and treat the warning as a task with a date, not as a notification to dismiss.