Your Customers Shouldn't Be Your Monitoring System

Here's a question with an uncomfortable answer for a lot of teams: how did you find out about your last outage?

If the answer is a support email, an angry message, a tweet, or the founder happening to refresh the site — you don't have monitoring. You have customers doing the job of monitoring, unpaid, and reporting their findings in the least useful format available: after the damage, with no detail, while annoyed.

This post is about closing that gap. It's written for the technical-enough owner or founder who suspects their setup is thin here and wants to know what "enough" looks like without buying a platform they don't need.

Why "is the site up?" is the wrong question

Most teams that do have something in place have an uptime checker pinging their homepage every five minutes. That's better than nothing, and it will miss most of what actually goes wrong, because up is not the same as working.

All of these happen on a site that returns a cheerful 200 OK on its homepage:

• Payments are failing at the final step. The homepage is fine. Revenue is zero.
• The background job queue stopped an hour ago. Nothing is broken on screen; nothing is being processed either — emails, invoices, exports, imports, all silently piling up.
• Password reset emails stopped sending. Every locked-out user just quietly leaves.
• One customer's data is broken while everyone else's is fine. There's no page that reports this.
• The disk is 98% full. Everything works perfectly, for about six more hours.
• The certificate expires on Saturday. Everything works perfectly until it doesn't, for everyone, at once.
• The last deploy doubled response times. Nothing is down; the product just feels bad now, and it will keep feeling bad until someone happens to compare.

None of that is exotic. It's the ordinary shape of software failure, and a homepage ping sees none of it.

The four layers worth watching

Think of it in layers, cheapest and most valuable first. Most small teams need the first three and can stop there.

1. Is it up?

The floor. An external check hitting your application from outside your own infrastructure — because a check running on the server can't tell you the server is gone. Hit a page that actually touches the database, not a static health endpoint that returns "ok" no matter what's behind it.

2. Is the money path working?

The highest-value monitoring most small teams don't have. Pick the two or three journeys your business genuinely depends on — sign up, log in, add to cart and pay, submit the booking — and have a script perform them on a schedule, like a robot customer, and alert when a step fails. This is the check that catches the "site is up, checkout is broken" class of outage, which is the expensive class.

It takes an afternoon to set up and it is worth more than every dashboard you will ever install.

3. Is it healthy?

Signals that something is wrong now, or about to be:

• Errors — an error tracker in the application, with alerts on new error types and on a rate that spikes. Not a log file nobody opens; something that comes to you.
• Response times — the slow trend, watched, so the frog-boiling gets noticed. Watch the slowest few percent of requests, not the average; averages hide the users who are actually suffering.
• Queues and jobs — the depth of any background queue, and an alert when a scheduled job doesn't run. Silence is the most under-monitored failure mode in software, because nothing fires when nothing happens.
• The boring finite things — disk space, memory, certificate expiry, domain expiry, API quotas, credit-card-on-file expiry for your cloud provider. Unglamorous, entirely predictable, and a genuinely common cause of self-inflicted downtime.
• Backups — an alert when a backup does not succeed. An unverified backup is a hope, not a backup.

4. What changed?

When you're staring at a graph that went bad at 14:32, the only question that matters is what happened at 14:32. Record your deployments in the same timeline as your metrics, so "did we cause this?" takes ten seconds instead of forty minutes of guessing. Most incidents are caused by a change, and most of those changes were yours.

Alerts people actually read

More alerting is not better alerting. The most common failure isn't having no monitoring — it's having monitoring that everyone learned to ignore.

Two rules keep a channel alive:

Every alert has an owner and an action. If nobody knows who responds, or the response is "look at it and shrug", it isn't an alert — it's a metric, and it belongs on a dashboard you look at deliberately, not in the channel that's supposed to wake someone.

A noisy alert must be fixed or deleted, this week. Once a channel cries wolf regularly, people stop reading it, and then a real alert arrives into a room that has learned to look away. A muted alert is worse than no alert, because it comes with the feeling of coverage. If you have a channel like that today, deleting half of it is a real improvement.

One more thing worth deciding explicitly: what's worth waking a human for? Be honest. Plenty of businesses genuinely don't need anyone awake at 3 a.m. — the honest goal is often "we know before the first customer of the morning does," and that's a legitimate, much cheaper target. What you don't want is to have never decided, and to discover during your first real 3 a.m. incident that everyone assumed someone else was watching.

If you have nothing, do these five this week

In rough order of value per hour spent:

1. Error tracking in the application, with alerts on. Free tiers are genuinely fine at your size.
2. An external check on one real user journey, not the homepage.
3. One channel where alerts land, with a named person expected to look.
4. Expiry alarms — certificate, domain, cloud payment method. Set them and forget them.
5. A "backup did not succeed" alarm, then actually restore one backup to prove it works.

That's an afternoon or two, it costs nearly nothing, and it moves you from "customers tell us" to "we tell ourselves." The difference in how a bad week feels is very hard to overstate.

The honest limit

Monitoring doesn't fix anything. It shortens the distance between something breaking and someone competent knowing about it — that's the whole job. So the value depends entirely on what happens after the alert fires: who sees it, whether they can act — if only one person on your team ever can, that's its own problem — and whether the cause gets written down so it isn't rediscovered next quarter. An alert into an empty room is theatre.

That's also why it doesn't stay solved on its own. Coverage decays as the system changes, because a new feature rarely arrives with new checks around it. Watching the system is a rhythm, not a purchase — which is exactly why it sits inside an ongoing engagement rather than a project. On our side, that's Managed DevOps: automated monitoring and alerting run continuously with a traceable record of what fired and when, and it's our job to notice — so we'll be straight about the interested party writing this.

If you'd like an outside read on what's currently invisible in your setup, that's part of what our free DevOps review covers: what breaks first as you grow, what it takes down with it, and how you'd find out. Written down, free, yours to keep — including if you hand it to your own team and fix the list yourselves.

But the five items above don't need us, or anyone. Do them this week. Then the next thing your customers tell you can be about your product instead of your plumbing.