--- title: "Knowing before your customers do is the whole product" description: "Monitoring is usually justified as insurance against downtime. The better argument is commercial: the gap between a customer telling you your site is broken and you telling them is a gap they can feel." url: https://harpywatch.com/blog/knowing-before-your-customers-do kind: article author: "The HarpyWatch team" published: 2026-09-02T18:06:09.141245+00:00 tags: ["Monitoring", "Product", "Reliability"] publisher: "HarpyWatch" --- # Knowing before your customers do is the whole product There are two versions of the same outage. In the first, a customer emails support: *is your site down for anyone else?* Someone forwards it. Someone else checks. Forty minutes later there is an answer, and the answer arrives after the customer has already told a colleague that your product is flaky. In the second, the customer opens their inbox and finds a message that arrived before they noticed anything: *we saw this at 09:12, here is what it affects, here is where to watch.* The outage is identical. What it costs you in trust, in support time, and in the next renewal conversation is not. ## What the customer is actually learning The customer in the first scenario learns something true and expensive: **you did not know.** They found out about your system before you did, using nothing but a browser. That single fact colours everything else they believe about your engineering. That inference is not unfair. If nobody was watching the front page, it is reasonable to assume nobody is watching the certificate, the backup job, or the data. The customer cannot audit any of that, so they use the one signal they have. The customer in the second scenario learns that you were watching. The failure still happened. But the thing they take away is that your systems are observed and your communications are proactive, and that is a genuinely different company to be a customer of. So "monitoring reduces downtime" is the weaker version of the argument. Monitoring does not stop a bad deploy or a lapsed registration. What it changes is who speaks first. ## The sales conversation this changes A public status page with real history is a sales artefact that has to be accumulated rather than written. A slide claiming reliability is a claim. A page showing every check against your own site for the last several months — including the days it went red, and how long red lasted — is evidence, and it is evidence that gets stronger the longer it exists. You cannot produce it retroactively on the morning of a procurement review. Either you have been collecting it or you have not. Security and procurement questionnaires ask about availability and incident response, and most answers are prose. A link to a history of observed results answers several of those questions in a form the reader has no reason to disbelieve. The uncomfortable half of this is worth stating plainly: publishing history means publishing the bad days. A status page that has never been red is a status page nobody believes, or one that is not really measuring. The value comes from it being falsifiable. ## Why the smaller team wins this one On this one axis — who finds out first — a four-person company with external monitoring can beat a forty-person company without it. The reason is structural rather than motivational. Large organisations have monitoring. What they often lack is monitoring that sits **outside the thing being monitored**. Internal observability tells you about your application when your application is running. It tells you very little when DNS is wrong, when the certificate on the load balancer expired, when the CDN is serving a stale document, or when the whole region is gone — and those are precisely the failures where the dashboard goes quiet at the exact moment it was supposed to speak. A check that runs inside the stack it is watching goes down with it. You can build around that — a health check in a separate region, a separate account, a separate provider — and organisations that have been burned do exactly that. The point is that it takes deliberate work, and the property you are working towards is simply that the observer is somewhere else. The small team's advantage is that adopting external checking is a short piece of work that stays coherent afterwards, because there are ten URLs and one person who knows all of them. The large team's disadvantage is not incompetence; it is that the same decision has to survive four departments. ## Be concrete about what it costs The word "cheap" gets used loosely, so here is what it means here. The kind of external monitoring described here is a background process making requests to a handful of URLs on a schedule. Some tools in this space do want an agent or a sidecar installed; this kind does not, and that is the version being costed. No change to your application, no deployment, no library, no migration, no code review. The work is: list the addresses that matter, decide who gets told, and choose what counts as broken. The list of addresses that matter is usually short — the marketing site, the app's front door, the login endpoint, the two or three API routes a customer's integration actually calls, and the status page itself. That is not a platform. It is a config file. The honest limit is that this is observation from outside, and outside is not everywhere. External checks will not tell you which query is slow, why a worker is backing up, or which user hit the bug. They tell you what a visitor gets. Those are different jobs and you want both; only one of them survives your own infrastructure being unavailable. ## Where the compounding happens The second-order effect is the one that ends up mattering most, and it takes a few months to arrive. Once results are collected continuously, you stop arguing about whether the site "felt slow last Tuesday". The record exists. A deploy can be lined up against the response time, the redirect chain and the headers on either side of it. A regression that would previously have been noticed six weeks later by a customer becomes a red cell an hour after it shipped, when the person who caused it still remembers what they did. That is the actual saving, and it is not the outage. It is the redirect that got one hop longer, the header that went missing, the response that got slower — each caught while it was still a change rather than after it had aged into an incident. ## Where HarpyWatch sits in this We build one of these, so take the following as description rather than persuasion. HarpyWatch runs thirty-one kinds of check against your sites from outside your infrastructure, on a schedule, and puts the results in one grid — one row per asset, one column per check. It alerts by email, Slack and webhook, and it can publish a public status page from the same results, so the page your customers read is derived from the same measurements your team is woken by rather than being a second thing someone updates by hand. It will not tell you why your database is slow. It will tell you, before your customers do, that the thing they are pointed at is not doing what you think. That is a smaller claim than most monitoring marketing makes. It is also the part that changes the conversation.