Monitoring Is Always Cheaper Than the Outage

Infrastructure has a marketing problem. When it works, there is nothing to show. The work that prevents a bad day is invisible by definition, which makes it the easiest line to cut and the most expensive one to have cut.

The argument for monitoring is not really about technology. It is about who finds out first.

Two versions of the same incident

A queue backs up at 11pm on a Thursday.

Version one. An alert fires at 11:04. Someone on call sees it, restarts the worker, and confirms the backlog drains. Total cost: fifteen minutes of one person's evening. Nobody outside the team ever knows.

Version two. Nothing is watching. At 9am on Friday, customers start reporting that their orders never confirmed. Now you have an outage, a support queue, a manual reconciliation job, and a credibility problem with the people who reported it to you.

Same technical fault. The difference in cost is not double. It is closer to fiftyfold, and most of it is not the engineering time.

What "we have monitoring" usually means

Most teams that say they have monitoring have uptime checks. Something pings the homepage every minute and alerts if it stops responding.

That catches total failure, which is the least common and least damaging category, because total failure is obvious. It misses everything that degrades quietly:

• A queue that is draining slower than it fills
• An error rate that went from 0.1% to 3%
• A disk that will be full in nine days
• A backup that completes successfully and produces an unusable file
• A certificate expiring on a Saturday
• A third-party API that got slower, so your timeouts now fire occasionally

None of these page anyone. All of them become incidents eventually, usually at the worst moment, because these things correlate with load.

The rule worth adopting

Every alert should describe something a human can act on.

An alert that fires regularly and gets dismissed is worse than no alert, because it teaches everyone that alerts are noise. Once that lesson is learned, the real alert gets dismissed too.

So the discipline is not adding more alerts. It is keeping the number small enough that each one is taken seriously, and deleting any alert that has fired three times without anyone doing anything about it.

Backups, specifically

A backup job that reports success and has never been restored is not a backup.

The failure mode is not backups that fail loudly, those get fixed. It is backups that succeed for eighteen months, producing files that turn out to be incomplete, encrypted with a key nobody has, or missing the one database that got added later.

A restore test is also one of the few checks that shows up in both operations reviews and security reviews, for the same reason: it is the difference between assuming you can recover and knowing it. The only meaningful test is a restore. Into a clean environment, from the backup alone, with someone timing it. Once a quarter is enough. The number you get, how long a full recovery actually takes, is one you want to know before you need it rather than during.

The honest cost comparison

Monitoring costs a setup effort and a small ongoing amount of attention. It has no visible return, ever, which is exactly why it gets deprioritised.

An outage costs engineering time, support time, reconciliation, and a quantity of customer trust that nobody puts on a spreadsheet but everybody notices in the following quarter.

The comparison is not close. It just never feels urgent until the week it does.

The unglamorous version of this, alerts that mean something and restores that have actually been tested, is most of what managed IT services buys you. When the alerts point at the application rather than the environment, that becomes a development problem instead.