The email that starts with 'Is your site down?'
It is Saturday morning. A customer emails to say they cannot log in. Then another. Someone checks the site from their phone and sees an error page. Nobody knows how long it has been like that. The developer is not answering. Somebody posts a holding message on social media while someone else searches for the hosting login.
By Monday it is fixed, and everyone agrees it should not happen again. Then it does, a few months later, in almost the same way.
Why outages go unseen
Most small businesses do have some monitoring. The problem is usually what it checks and who it tells.
- It checks that the home page loads, while the login, checkout or booking form is broken.
- Alerts go to an email address nobody reads, or to a developer who has left.
- Alerts fire so often for trivial things that people have learned to ignore them.
- Nobody is clearly responsible out of hours, so everyone assumes someone else is looking.
- There is no written plan, so each outage starts with a search for passwords.
The server can be up and the business can still be down. A monitor that only checks the server is answering the wrong question.
What finding out late costs
The damage from an outage is roughly the time it lasts multiplied by how many people it affects. Monitoring does not stop things breaking. What it changes is when the clock starts, and who is holding it.
| Cost | Why it matters |
|---|---|
| Lost orders and bookings | Every hour down is business that goes elsewhere |
| Trust | Customers notice when you did not notice |
| Longer outages | The clock only starts when someone is told |
| Stressful response | Scrambling for logins and phone numbers makes mistakes more likely |
| No learning | Without a record, the same fault returns |
There is a reputational side that lasts longer than the outage. A customer who reports a fault and gets a quick, informed answer usually forgives it. A customer who reports it and discovers you had no idea is left wondering what else you are not watching.
How we make sure you know first
- List what matters. With you, we identify the journeys the business depends on: logging in, checking out, submitting an enquiry, the API a partner calls.
- Monitor those journeys, not just the home page. Synthetic checks run through them on a schedule from outside your hosting, using tools such as UptimeRobot, Better Stack, Pingdom or the cloud provider's own services.
- Add error tracking inside the application, for example with Sentry, so faults that affect some users show up even when the site is technically up.
- Route alerts properly: to named people, on a channel they actually read (phone, Slack, Microsoft Teams), with an escalation if the first person does not acknowledge.
- Tune out the noise. Alerts fire for things that need action, and everything else goes to a daily summary.
- Write a short runbook: who responds, where the logins are kept, how to check the usual causes, how to roll back, and how to tell customers.
- Set up a status page if customers depend on your service, so you can tell them what is happening before they ask.
We can also be the people who respond, or support your team in doing it. That depends on what fits your business and is agreed explicitly, not assumed.
When it is set up
An outage now starts with an alert on the right person's phone, not an email from a customer. That person has a runbook and the access they need. Customers see a status message rather than silence. And after each incident, a short note records what happened and what was changed, so the same fault does not catch you twice.
Recognise any of these?
- You have learned about an outage from a customer, supplier or social media.
- Your monitoring only checks whether the home page loads.
- Alerts go to an inbox nobody watches or a person who has left.
- Nobody is clearly responsible if the site fails outside office hours.
- Nobody could find the hosting login quickly in an emergency.