--- title: "A status page is a sales asset, if it is honest" description: "Uptime nobody can see is an internal fact. Published with real history, it answers a question buyers were going to ask anyway — and an always-green page nobody believes is worth less than an honest one with incidents on it." url: https://harpywatch.com/blog/a-status-page-is-a-sales-asset kind: article author: "The HarpyWatch team" published: 2026-09-08T09:00:00+00:00 tags: ["Monitoring", "Product", "Reliability"] publisher: "HarpyWatch" --- # A status page is a sales asset, if it is honest Ask an engineer to evaluate a vendor and one of the first things they do is type `status.` in front of the domain. It is a cheap proxy for two questions that are awkward to ask in a sales call: how often does this break, and how long does it take you to admit it. Three months of published history answers both, in a form nearer to evidence than to assurance — a reader still has to trust that you did not quietly delete a bad week, but that is a much smaller thing to be asked to believe. And a 404 at that address is itself a result, for somebody who went looking. ## What a status page is actually for It is worth being precise, because status pages get justified with several things they do not do. **As a notification channel it is weak.** Nobody sits watching it. The people who open it during an incident are the ones who already hit the problem and went looking. If you need customers to know something, you send it; the page is where they confirm what you sent. **It is not itself monitoring.** It is a rendering of measurements taken somewhere else — by your monitoring, or by ours, but by something that actually probes the site. A status page with no checks behind it is a page somebody updates by hand when they remember, which means it is wrong during exactly the period it matters. What it does do is three things, and they are all commercial. It **removes a question from the sales conversation**. "How reliable are you" has no useful verbal answer, because no vendor has ever answered it badly. A published history is an answer that does not depend on trusting the person giving it. It **absorbs the first wave of an incident.** An acknowledgement on the page answers "is it just me" without a support ticket, and it does so for everybody at once. How much support load that removes depends on your customers; that it removes some of it is close to arithmetic, since every person who reads the page is a person who did not need to write to you to learn the same thing. It **is something a competitor without one cannot produce on demand.** Building the page is a day's work at most. The record on it took however long it took, and no amount of budget compresses that. The asset is the accumulated record, and it only accumulates by having started. ## Why always-green is worth less than honest Consider what a reader does with a page showing 100% uptime, forever, and no incidents ever. Two reactions are available. Either the reader believes it — in which case they believe it right up until their first outage with you, and then stop believing anything on your site — or they do not believe it and file it as marketing. The second reaction is the more common one among people who run production systems themselves, for the obvious reason: they have incidents, they know their peers have incidents, and a page reporting none is more easily explained by a short history or hand maintenance than by an unbroken record. A page with incidents on it makes a better argument, and a checkable one. It says: something broke, we noticed it at this time, we said so, and it was resolved at this time. A reader can extract a detection time and a resolution time from that. Those two numbers are the ones an experienced buyer is actually after — not how often you fail, but how fast you notice and how fast you close — and no uptime percentage contains them. The cost of this is not technical. It is the meeting where someone asks whether this incident really needs to go on the public page. What the page is worth depends entirely on how you answer that when the answer is inconvenient — and a page that omits the bad month is worse than no page at all, because it is a statement you know to be false, published under your own name. ## What it costs to keep true Three things, roughly. **The measurement has to come from outside.** A status page fed by checks inside the infrastructure it describes reports correctly right up until the host, the cluster or the network segment running those checks is the thing that failed — the total outage, which is the one it most needed to report. And the page has to be hosted somewhere that survives that outage too. A status page on the same servers as the product answers "are you down" with a timeout. **Somebody has to write the updates.** The automatic part is the health of each component. The part that makes the page worth reading during an incident is a human sentence saying what is happening, and that is not generatable — nobody wants "an anomaly was detected in a service" at the moment they want to know whether to wait or work around it. **You have to decide what is on it before you need to.** Which components are public, and at what granularity. Too coarse and every incident takes the whole page red. Too fine and you have published your architecture, and a partial degradation reads as a wall of alarming colour. ## How ours works HarpyWatch has a public status page, and it is worth describing exactly rather than in general terms. It publishes at `/status/:slug`, or on your own domain with the DNS records the configuration screen gives you. It renders without a session, from a separate bundle that is checked at build time not to import the authenticated application — the same origin serves several surfaces, so that boundary is enforced by a test rather than by convention. Each component you choose to show carries a status, an uptime figure and a timeline of ticks, with ninety days behind it. Incidents appear with their own updates, and those updates are yours. In our implementation the published text is a distinct field from the internal incident note — two records, not one with a visibility flag — so publishing is something somebody does rather than something that happens to a note they already wrote. Two details matter more than they look. A period with no observation renders as a gap in the timeline, not as green — a status page is a claim about health made to people who cannot check it, so an unmeasured hour must not be drawn as a healthy one. And a component with nothing observed shows "No data" rather than 100%. Missing measurement and perfect measurement are opposite facts, and rendering them the same way would be both easy and dishonest. What it renders is not a second measurement: it is the same check results that fill your own grid, published under names you choose for an audience that cannot see the grid. ## The argument, in one line Uptime you measure privately is an engineering fact. Uptime you publish, with gaps drawn as gaps and incidents left on the record, is a commercial one. It is not free — every incident costs you a paragraph you would rather not write, and that is the cost, not the hosting — but it is the unusual kind of asset where what you have already paid for keeps appreciating as long as you leave it up.