---
title: "The debt you take on when a customer tells you first"
description: "An outage costs what it costs. Being informed of it by the person it happened to costs something separate, it accrues, and it is charged against the next incident rather than this one."
url: https://harpywatch.com/blog/the-credibility-debt-of-being-told
kind: article
author: "The HarpyWatch team"
published: 2026-10-20T09:00:00+00:00
tags: ["Monitoring", "Product", "Reliability"]
publisher: "HarpyWatch"
---

# 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.