The debt you take on when a customer tells you first

Hey, is your site down? I can't log in.

That message has already done something separate from whatever is broken. It has told the sender a fact about you they did not have before, and the fact is not "the site is down". It is that they found out first.

The outage is a technical event with a duration. This is not. It does not resolve when the service comes back, and nothing about this incident settles it.

The reply is structurally weak

Whatever you write back is constrained before you start.

You cannot say when it started, because you do not know — you only know when they noticed. You cannot say what is affected, because you have not looked yet. You cannot say it is fixed, because you are opening a terminal while typing. So the message is some version of thanks for flagging, looking into it now, which is honest and which also confirms, in five words, that the flag was load-bearing.

The alternative version of that message has none of those constraints. We saw this at 09:12. It affects logins for accounts using SSO. Here is where to watch. Identical outage. The sender has a start time, a scope, and somewhere to look, and none of those required the incident to be over.

That is not better communication. It is the same person with more information at the moment they had to speak.

What the customer generalises to

The inference they draw is broader than the incident, and it is not unfair.

They cannot see your database, your backups, your certificate renewals, or your deploy process. They have one observation about your operational awareness, and they got it by accident. Reasoning from one sample is what everyone does with a supplier; it is what you do with yours. If nobody was watching the login page, it is reasonable to assume nobody is watching the things that are harder to notice.

Notice which direction this runs. Being told first is not evidence that your engineering is bad — plenty of well-run systems have gone down while nobody was looking. It is evidence about observation, which is the thing a customer is least able to verify and therefore most inclined to extrapolate from. And the extrapolation is sticky, because nothing afterwards disconfirms it: a month of uptime is not evidence that you would have noticed. Only the next incident tests it.

The second one is judged against the first

This is where the cost is actually paid.

Incidents are not priced independently. The second one arrives with the first one attached, and the customer's question has changed. The first time, it was "what happened?". The second time it is "is this what it is like to be your customer?" — and that question is answered by the pattern, not the cause.

Two incidents, both handled well, both with you speaking first, read as a company with normal failures and a functioning process. Two incidents where the customer reported both read as a company that does not know what its systems are doing, which is a much more expensive belief because it is about the future rather than the past.

The asymmetry is worth being precise about. A single self-reported incident does not build much: it is one data point and people are generous about first impressions. A single customer-reported incident does not destroy much either. What compounds is the pattern, and the pattern is set early, with very few samples, and it is very hard to move afterwards because the only way to move it is more incidents.

Why this keeps happening to reasonable people

It would be easy to file this under carelessness. It is better understood as a predictable outcome of how the work is prioritised.

Monitoring is a task whose payoff is largely counterfactual. It produces a record and a baseline, both genuinely useful; what it does not produce on a good day is anything anyone points at. The value is a conversation that did not happen, an email that was not sent, an inference a customer did not draw — and none of those appear anywhere. Meanwhile the cost of not having it lands on a different day, in a different form, and gets attributed to the outage rather than to the absence of a check.

That is a hard shape for any prioritisation process to see. It is also why the task survives eight consecutive planning sessions without being done: it is never urgent on the day you are choosing, and it is never the named cause on the day you pay.

There is a second reason, mechanical rather than organisational. The people who look at the site most are the worst placed to be surprised by it: on the working network, already logged in, in a browser holding the cached certificate intermediate. Looking harder does not fix that. Looking from somewhere else does.

The thing being bought is a few minutes of sequence

Reduced to its incentive, external monitoring buys you the order of the conversation. It does not make the failure smaller. Everything above follows from that ordering rather than from the failure itself.

That is a small mechanism with a disproportionate effect, and it is worth being honest about its limits and its upkeep. It does not help with an incident nobody's checks can see — a bug affecting one account, a slow query that never crosses a threshold, data that is wrong rather than absent. It does not write the message for you. A check that runs every five minutes gives you at best five minutes of head start, which is enough to speak first and not enough to have fixed anything. And a threshold set too tight produces alerts nobody believes, which costs you exactly the attentiveness you were buying.

Five minutes is small. It is also the difference between we're investigating an issue that started at 09:12 and thanks for flagging — and the first of those carries a start time and a scope, which is diagnostic information as well as a better sentence.

HarpyWatch runs checks against your sites from outside your infrastructure and tells you by email, Slack or webhook when one of them changes. It also leaves a record you can point at afterwards, which has its own uses. But the part this piece is about is the ordering, and whether that is worth having depends on how much you would like your customers to go on assuming somebody is watching.