What an outage costs a team of one

You push a change on Friday afternoon. It is small — a form field, a redirect, a dependency bump. The site loads. You close the laptop.

On Monday morning you notice that no signups came in since Friday. Not fewer. None. The form has been posting to an endpoint that returns a 500 since about four o'clock on Friday, and the signals that existed were all ones nobody was looking at: a spike in your error tracker's inbox, a run of 500s in the access log, an empty table. Someone would have had to go and look, on a Saturday, without a reason to. Most people who cannot sign up do not write to support. They close the tab.

That is the shape of a small team's outage, and it is not the shape most monitoring writing describes. Large organisations have short, loud incidents with people paged. Small teams have long ones that nobody is awake for.

Where the money actually goes

No one can put a figure on those two days — not you, and certainly not somebody selling you monitoring. What can be described is where the loss goes.

The customer who tried once. Whatever you spent to get that person to the page — an ad, a sponsorship, months of writing — was spent before they arrived. Someone clicked a link, read your page, decided to try it, and hit a broken form. That cost was already paid. Some of them come back. The ones who do not leave no trace in your analytics that distinguishes them from people who simply were not interested.

Search rankings, which decay while you are not looking. A crawler that gets a 500 does not retry immediately and does not sulk politely for a fixed period. Sustained server errors and long timeouts reduce how often a site is crawled, and a page that cannot be fetched cannot keep the position it earned. The damage here is not instant and neither is the recovery, which is the bad combination: you lose ground in two days and get it back over weeks.

Trust, which is the hardest to get back. A customer who was affected and told by you is annoyed. A customer who was affected, worked it out themselves, and then discovered you had not noticed has learned something structural about how your company operates. That inference spreads further than the incident does — into whether they recommend you, whether they build on your API, whether they renew.

Your own time, at the worst possible rate. For a team of one, the person debugging is the person shipping, doing sales, and answering support. An outage does not just cost the outage; it costs the day you had planned, and small companies do not have slack in the schedule to absorb that.

Why the small-team version is worse, not better

It is tempting to think a smaller surface means fewer failures. The surface is smaller. The observation is far worse.

A company with twenty engineers has someone looking at the product most waking hours by accident. A company with one or two has whole stretches of the week where no one loads the site, because the people who would notice are the people who built it and they are not using it as customers. The gap between breaking and knowing is not mostly a function of how good you are. Absent something that checks on its own, it is a function of how many pairs of eyes happen to be pointed at the thing.

Small teams also fail in a way large ones mostly do not: the whole thing goes at once. Whatever the stack — one box, one managed platform, one certificate, one DNS zone — there is usually a single instance of each thing, so there is no partial degradation to notice, no canary region still serving, and no colleague in another timezone who spots it. It is fine, and then it is entirely gone, and the only witness is a stranger.

Monitoring you own cannot report on itself

One correction is worth making before anything else, and it costs nothing.

If your monitoring runs on the same machine as your site, it will not tell you about the failure you most need to hear about. A cron job on the box that emails you when the site is down goes down with the box. A health check inside the application returns 200 right up until the process the health check lives in stops answering. A dashboard fed by the same database that just filled its disk shows you the last thing it knew.

This is the one property of monitoring that cannot be bought later by adding more of it. The check has to run somewhere your outage does not reach.

What it costs in effort, plainly

The word "cheap" gets thrown around, so here is the specific version for a team of one.

The setup is a list of URLs. For most small products that list is short and you already know it:

• the marketing page a paid click lands on
• the signup or checkout endpoint
• the app's front door, logged out
• the one or two API routes an integration calls
• whatever the "forgot password" flow posts to

External checking runs somewhere your outage does not reach — a hosted service, or a small box you keep elsewhere — and makes requests to yours. Either way, setting it up is that list plus a decision about where alerts go: email, Slack, a webhook. Nothing goes into your application and nothing is deployed.

It is not zero afterwards, and anyone who tells you it is has not run it. A network blip will produce a false alarm, and you will have to decide what threshold stops that recurring. You will add a URL when you ship a feature and forget to remove one when you retire it. And if the alerting is noisy enough that you start ignoring it, you have made things worse than having none. An afternoon to set up, and an occasional hour to keep honest.

That is the actual comparison. Not "monitoring versus no monitoring", but "an afternoon of configuration and the occasional false alarm versus finding out on Monday". For a small team, this is unusually cheap insurance: the premium is an afternoon, and it pays out in hours of exposure you no longer have.

What it does not cover

External checking tells you what a visitor gets. It will not tell you which query is slow, why a background job is stuck, or that your pricing page is showing last quarter's numbers. It does not simulate a full logged-in journey — it checks the addresses you give it and what comes back from them.

That is a smaller claim than "we will prevent your outages". Nothing prevents your outages. What changes is how long one goes unwitnessed, and for a team of one that interval is where nearly all of the cost lives.

You will still have the Friday deploy that breaks the form. The difference is whether you learn about it at four o'clock on Friday or nine o'clock on Monday.