The message arrives at ten past four. A customer, being helpful, mentioning that your website has been down since lunchtime and nobody noticed. Somebody checks and it has. Nobody knows for how long, or why, or what it cost.
The instinct afterwards is to buy uptime monitoring, and it is a reasonable instinct that solves less than people expect. Most outages that matter are not the site being down. They are the site being up and something important on it not working, which almost nothing checks by default.
Why a website goes down and nobody notices
A basic uptime check asks your home page whether it responds and records a yes. That catches the total failure, which is real and worth catching, and it is also the least likely thing to go wrong.
It will happily report everything as fine while your contact form silently stops sending, your payment provider rejects every card, a certificate expires and browsers warn people away, your search results are the only thing broken, the site loads in eleven seconds, or a deployment breaks the checkout on phones only. Every one of those costs money, none of them makes the home page stop answering, and the form one is the worst because it is invisible and it costs you enquiries you will never know you had.
The four levels worth watching
| Level | What it asks | What it still misses |
|---|---|---|
| 1. Is it up? | Does the server answer, from more than one location so your own connection is not the thing being tested. | Everything that is broken while the server answers, which is most things. |
| 2. Do the important journeys work? | A script that actually walks through the path that earns money: search, add to basket, checkout, or fill in the form and confirm it arrived. | Problems affecting only some browsers or devices, and things that are working but slowly. |
| 3. Is it fast enough? | How long real pages take, tracked over time, so gradual decline is visible rather than only sudden failure. | Errors that do not slow anything down. |
| 4. Is it erroring? | Whether the application is throwing errors, and whether the rate has changed, which is usually the first sign of a bad deployment. | Nothing much. This is the level most small businesses never reach and the one that catches problems earliest. |
Level two is the one that pays for itself. It is also the one almost nobody sets up, because it takes an hour of thought about which journey actually matters rather than five minutes of entering a URL.
Two unglamorous additions worth having whatever else you do: an alert well before your certificate expires, and an alert before your domain does. Both are entirely preventable outages that still happen constantly, usually to a renewal notice sent to somebody who left.
An alert nobody receives is not an alert
This is where most monitoring quietly fails. The tool worked perfectly, detected the outage within a minute, and sent an email to an address nobody has opened since a member of staff left.
- Name a person, not a team address. A shared inbox at three in the morning belongs to nobody. Say who is responsible and when.
- Use something that interrupts. Email is not an alert out of hours. A message that makes a phone ring is.
- Have a second person. The first one will be on a plane at some point, and that will be the day.
- Test it deliberately. Trigger a real alert and confirm it reaches someone. Do this again every few months, because routes rot: people leave, numbers change, apps get muted.
- Fix false alarms immediately. An alert that cries wolf twice a week will be ignored within a fortnight, and then it is worse than nothing because everyone believes they are covered.
- Decide what does not warrant waking someone. Otherwise everything wakes them, and the next step after that is muting everything.
What to do when it fires
Written down in advance, because nobody thinks clearly at two in the morning.
- Confirm it is real from a different network and device. A surprising share of alerts are the monitoring having a bad moment.
- Say something publicly if it is customer-facing. A short note that you are aware and working on it turns an outage into an inconvenience. Silence turns it into a story.
- Check what changed. A deployment, a certificate, a payment method, an expiry, someone editing something. Almost always the answer.
- Restore first, understand later. Roll back, switch to a maintenance page, whatever gets customers moving. The investigation can happen when nothing is on fire.
- Write down what happened while it is fresh, including how long before anyone knew. That number is the one worth improving.
- Fix the detection, not only the fault. If a customer told you first, the outage was one problem and the not-knowing was another.
The failures that never trigger anything
Some of the most expensive problems produce no alert at any level, because nothing is technically broken. Worth checking these manually every month, since no tool will tell you.
- The contact form sends to nowhere. The form submits, the visitor sees a thank-you page, and the notification goes to an address that stopped working when someone left. Every check passes. Test it monthly by submitting it yourself and confirming it arrived.
- Emails from your site land in spam. Order confirmations and password resets are delivered as far as your systems are concerned. Customers say they never arrived. Nothing anywhere reports a failure.
- Payments succeed and orders do not arrive. The customer is charged, the confirmation shows, and the order never reaches whoever fulfils it. Reconcile takings against orders regularly rather than trusting that they match.
- Search engines can reach it but cannot index it. A setting changed during a redesign, and a site can drop out of results while being perfectly available to anyone who types the address.
- It works everywhere except one browser, or only breaks on phones, which is where most of your visitors are.
The common thread is that every one of these is silent, and the first sign is a customer who is annoyed for a reason nobody can reconstruct. A ten-minute monthly walk through your own site as a customer, buying something or submitting the form, catches more of these than any amount of tooling.
About uptime promises
Nobody can promise your site will never go down, and we will not. Your hosting provider will have outages. So will your payment provider, your email provider, your DNS provider and the content network in front of you. Some of those are companies whose engineering budgets exceed the revenue of most businesses, and they still have bad days.
What can honestly be promised is a response: that somebody knows quickly, that a named person is looking at it within an agreed time, and that you hear about it from us rather than from a customer. Treat a guarantee of perfect uptime as a marketing claim rather than an engineering one. If the difference between response and repair is not spelled out in whatever you are being sold, ask, because that is the clause that matters at four in the morning. Our support with stated response times sets that out, and where the underlying problem is architectural rather than operational, that is reliability work.
What it costs
| What you get | Typical monthly |
|---|---|
| Basic uptime check from a few locations, email alerts | Free to $20, and worth setting up this afternoon |
| Uptime plus a scripted journey or two, alerts that interrupt | $30 to $150 |
| The above plus performance tracking and error monitoring | $100 to $400 |
| All of it, watched by people who will act rather than forward it to you | $400 to $2,000 |
Illustrative ranges from the kind of work we quote, not a price list. The jump in the last row is not tooling, it is somebody being awake and accountable.
Set something up this week
- Put a free uptime check on your home page today. Ten minutes. Whatever else you conclude, do this one.
- Add certificate and domain expiry alerts. Two more minutes, and it removes the most embarrassing category of outage.
- Write down the one journey that earns you money, and get a scripted check on it. This is the hour that matters.
- Name the person alerts reach, and a second one, and put it in writing where someone will find it.
- Trigger a test alert and confirm it arrives, on a phone, out of hours.
- Write the six steps above on one page and put it somewhere findable, because you will not compose them calmly during an incident.
Not for you if
The number worth tracking is not uptime. It is how long between something breaking and a human knowing. If that number is currently however long it takes a customer to be annoyed enough to email you, everything on this page is an improvement.