# HarpyWatch — The Nest, in full

Every published post, concatenated. Canonical addresses are under https://harpywatch.com/blog/. Each post is also available on its own at the URL given beneath its title.

---

## Staging configuration travels, and agents help it

URL: https://harpywatch.com/blog/staging-configuration-travels
Author: The HarpyWatch team
Published: 2026-10-01
Kind: article
Tags: AI Agents, Deployment, SEO

The fastest way to get something working is to copy the configuration from
wherever it already works. It is a reasonable technique and most of us have
used it, and an agent asked to make a deployment work tends to reach for it for
the same reason we do: it is the shortest path from broken to working, and
nothing in the task says otherwise.

Configuration copied from staging is configuration that says staging — in a
hostname inside a <link rel="canonical">, in an X-Robots-Tag header, in the
origin an API is willing to answer. None of those is contradicted by anything
running on your machine.

What actually travels

These are not hypothetical. They are the ordinary residue of an environment
that was cloned rather than derived.

A canonical tag pointing at the staging hostname. The template renders
<link rel="canonical" href="https://staging.example.com/pricing"> on the
production page. Every browser renders the page normally. Search engines are
told, by you, in your own markup, that the authoritative copy of this page
lives at an address they cannot reach or should not index. The page is live,
correct and quietly asking to be excluded.

A noindex that shipped. Staging carries X-Robots-Tag: noindex or a meta
equivalent so it does not compete with the real site. Correct. Then it rides
along in the image, the config map, or the nginx snippet somebody copied, and
the production site is now instructing crawlers to drop it. The page renders
perfectly. Traffic decays over weeks and the cause is a header nobody reads.

A test API key. Payments succeed in the test ledger and never charge
anybody. Email sends to a sandbox that accepts everything and delivers nothing.
The application logs success on every path, because from its point of view
every path succeeded. This one is particularly cruel: it fails by working.

A database URL. Production pointed at the staging database, or worse,
staging pointed at production and now writing to it. The first is a site whose
data quietly does not persist where anyone expects. The second is a test suite
mutating real rows.

A CORS origin. Access-Control-Allow-Origin: https://staging.example.com,
served in production. The API answers every request from a browser at the real
hostname with a response the browser then refuses to hand to the JavaScript
that asked for it. The server's logs show 200s. The user sees an empty panel.
The developer, testing from a tool that does not enforce the same-origin
policy, gets a clean 200 and moves on.

A robots policy. Not just noindex — a robots.txt with Disallow: /, or
a sitemap reference pointing at the staging host, or a crawl-delay written to
stop a load test from hammering a small box.

Why none of these show up locally

Every item on that list is a fact about the response a stranger receives from
a particular deployed hostname, not a fact about the code. The repository is
identical in both environments. The difference is in what an environment
variable, a config map or a build-time substitution put there, and by
definition that substitution does not happen on the machine where the code was
written.

So the local check cannot see it. The unit test cannot see it — it does not
make an HTTP request to a public hostname. And whoever verified the change,
human or agent, verified it against the dev server, where the canonical tag
rendered a localhost URL and nobody minded.

And the browser will not tell you either. A canonical tag, a robots header and
a CORS origin are all invisible in rendered output. You have to look at the
headers and the markup as delivered, at that address, from outside.

Check the deployment, not the intention

The correction is to stop treating "it passed on my machine, and the deploy
reported success" as evidence about production, and start observing production
as its own object. Observation does not prevent any of this — the wrong header
still ships — it changes how long the wrong header is live before somebody
knows. For a canonical tag or a robots policy, that interval is the entire
cost.

Three checks cover most of what travels. They do not cover all of it — the
limit is at the end of this section, and it is a real one:

- http-headers reads the headers the deployed host actually returns —
including X-Robots-Tag, cache directives and anything else that arrived in
a copied config file. You assert what should be there; the check tells you
what is.
- robots-policy fetches robots.txt and the meta and header equivalents,
and tells you whether this hostname is currently asking to be indexed or
asking to be forgotten. Two environments should disagree about this, and only
one of them should say Disallow: /.
- cors-policy makes the preflight request from an origin you name and
reports what came back. This is the only way to see the failure, because the
server does not consider the request an error and the browser's refusal
happens after the response has already been logged as a 200.

None of these three detects a test API key. That is a real limit and worth
stating: from outside, a payment that succeeds in the test ledger looks exactly
like a payment that succeeded. Credential provenance is something only your own
deployment process can assert, and the fix is that production secrets come from
a store nothing else can read, not from a file that was copied.

Why an agent makes this worse, specifically

The difference between a person doing this and an agent doing it is not care.
It is that a person who configured both environments by hand ends up knowing
how the two differ, and that knowledge is what makes them stop over a pasted
value whose origin they cannot name. The pause is a side effect of having done
the work slowly, and it is doing more safety work than anyone credits it for.

An agent produces a configuration that is quick, plausible and mostly correct,
and nobody ends up holding that map. Not the agent, whose context for the task
ends with the task. And not the reviewer, who is reading a diff — where the
value appears as a variable name — rather than the substitution that fills it
at deploy time. There is nothing to be uneasy about, because nobody remembers
making a decision.

Which is why the check has to be external and automatic. The environments no
longer differ in ways anyone is tracking. They differ in ways only the deployed
response can tell you about.

The cheapest moment is before DNS

There is a version of this that costs almost nothing. Run the checks against
the staging URL — the real deployed staging host, not localhost — before you
point production at it, or before you promote the image.

At that moment every value on the list above is observable at an address that
exists, and none of them is affecting anybody
yet. You are not looking for staging to be perfect; you are looking for the
list of things that are true of staging and must not become true of production.
That list is short and reading it takes a minute. The alternative is finding
out from a search engine, and a page dropped from an index does not come back
the moment you fix the header — it comes back on the crawler's schedule, which
for a small site is measured in weeks.

---

## Monitor the site nobody is looking at yet

URL: https://harpywatch.com/blog/monitoring-before-you-have-users
Author: The HarpyWatch team
Published: 2026-09-29
Kind: article
Tags: AI Agents, Monitoring, Reliability

A site with ten thousand users has a monitoring system whether or not anyone
built one. It is called the support inbox. Something breaks, and within minutes
there are three tickets, a tweet and somebody's colleague saying it works for
them. The signal is noisy and slow, but it exists.

A site with no users has none of that. It has visitors — a few a day, from a
link somewhere — and most of the ones who hit a broken page close the tab.
They do not file a bug. They were never going to. The outage is silent and it
costs you exactly the people you were trying to get.

Which inverts the usual instinct. Monitoring feels like something you add once
a site matters enough to protect, but user reports are the only detection an
early site has, and it does not have any users. What is left is you, whatever
you last deployed, and however long it takes you to look again.

The specific way a new site breaks

It is rarely the server falling over. A new site is usually one process on one
managed host serving very little traffic, and that arrangement is hard to
overload. The failures are of a different kind, and most of them share a
property: the site returns 200 the whole time.

The domain resolves to nothing, because the nameservers were changed and the
old record is still cached in your browser and nowhere else. The certificate
was issued for www. and the apex was never added, so half the people who type
the name in get an interstitial. The redirect from the old landing page loops.
A robots.txt written for the staging build is still telling every crawler to
go away. An API route the front page calls returns a 500 for anyone not
carrying the session you had open when you tested it.

Every one of these works on the machine it was built on. Several are invisible
even in a browser, if it is the browser that has been open since before the
change. And in a workflow where the config, the redirects and the deployment
were written by a coding agent in a single session, nobody chose any of them
deliberately — the build passed, the session ended, and the gap between that
and a working public site is whatever nobody read.

What to watch on day one

The useful first setup is small enough to be embarrassing. That is the point of
this piece: it is not a project, it is a few minutes.

| Check | The failure it catches |
| --- | --- |
| http-uptime | The site is not serving. The baseline; everything else assumes it. |
| dns-resolution | The name does not resolve, which looks identical to the site being down but is fixed somewhere else entirely. |
| ssl-cert-expiry | The certificate on the wire is expired or about to be. Total outage, entirely predictable. |
| redirect-chain | Apex to www, HTTP to HTTPS, and old paths to new ones — the hops a visitor actually makes. |
| dom-content | The page returned 200 and rendered the wrong thing. A framework error page is a 200 in a lot of setups. |
| robots-policy | You are still telling search engines not to index you. |

That is six checks against one URL. They have to run from outside your own
infrastructure, for a reason that only bites during a total failure: a check
running on the same host, in the same container or behind the same network
segment reports nothing once that host, container or segment is the thing that
went down — precisely when you needed a report.

One addition is worth making immediately after: point the same set at your
staging URL before you switch DNS to it. Finding a broken redirect or a
noindex that travelled from staging is cheap before the traffic arrives and
awkward afterwards, and it is the same six checks against a different hostname.

What can wait

Being honest about the other side of this matters more than adding items.

Performance budgets can wait. core-web-vitals, ttfb-budget and
page-weight measure things worth measuring, but the number they give you on a
site with no traffic is a number with no consequence attached. Set them when
you have a baseline to regress from.

Most security headers are not urgent yet. csp-policy in particular is
worth doing properly, and doing it properly means understanding what your pages
load. A content security policy added on day one to satisfy a checklist tends
to be either so permissive it does nothing or so strict it breaks the site the
first time you add an embed.

Anything whose value scales with page count is premature. broken-links and
sitemap-health are genuinely useful and they get more useful as the site
grows. On a five-page site you can read it yourself in less time than
configuring the check.

Alerting on everything is a habit not worth acquiring. With six checks and one
site, alerts on all of them are fine because the volume is nothing. The
discipline you will need later is deciding which of them are worth waking you
up. Start by paging on http-uptime and ssl-cert-expiry and reading the rest
when you look.

Why this is smaller than it sounds

Monitoring has a reputation for being a platform: agents to install, dashboards
to build, a retention policy to argue about. That reputation is earned, and it
is earned by instrumenting your own infrastructure, which is a genuinely large
problem and not the one on the table here.

Watching a website from outside has no install step, because the check connects
the way a visitor does, and no instrumentation step, because the observable is
the response. What you supply is short enough to name exactly: the URL, an
interval, credentials for anything behind a login, and one address that
receives the alerts. That last item is the one
people skip, and a check with nowhere to report is a check that has changed
nothing.

The corresponding limit is worth naming too. An external check sees what a
visitor sees, which means it cannot see anything a visitor does not: a job
queue that has stopped draining, rows written to the wrong database, an
inconsistency that only appears after a login you did not give it. Those need
instrumentation from inside. What outside observation is for is the class of
failure where the site itself is unreachable, wrong, or lying to crawlers —
which on a new site is most of them.

This is what HarpyWatch does — checks run from outside your infrastructure on a
schedule, results in one grid, alerts by email, Slack or webhook. Configuring
the list above is a form, six times. Deciding what should alert you and
verifying that the alert actually arrives takes longer than the configuring
does, and it is the part worth doing carefully.

What that buys is a shorter time to discovery. Without monitoring, the gap
between a site breaking and you knowing is however long until you next look —
on a site you are not yet promoting, that can be weeks. With it, the gap is the
check interval, plus delivery, plus however long the alert sits unread. None of
those three is zero. All three together are typically minutes, against weeks.
Everything else here is detail; that substitution is the argument.

---

## The API contract changed underneath the frontend and nothing failed

URL: https://harpywatch.com/blog/the-contract-changed-underneath
Author: The HarpyWatch team
Published: 2026-09-24
Kind: article
Tags: AI Agents, Monitoring, Reliability

uptimepercent used to be a number. It is now a string, because a Rust
serialiser gained a format!("{:.1}", pct) to round it to one decimal place,
and format! produces text.

The backend tests pass: they assert on the value, and "99.9" is the value. The
frontend builds: TypeScript is describing a response it was told about, not one
it received. The page renders. In the cell where a percentage belongs there
is now 99.9%%, or NaN%, or nothing at all, depending on which arithmetic ran
first.

Nothing in either build raised a hand.

Why the build cannot save you here

The failure has a precise location: the boundary where a typed program stops
being able to check its own beliefs.

Inside the backend, types are enforced. Inside the frontend, types are enforced.
Between them is JSON, which enforces nothing. The frontend's
interface UptimeSummary is not a check on anything — it is a comment the type
checker happens to trust. When the two sides disagree, the disagreement lives in
the one place neither language is looking.

Every failure in this family is the same shape:

- A field changed type: number to string, string to enum object, scalar to
array of one.
- A field was renamed: openIncidents became openincidents, so the old
name is now undefined and undefined renders as an empty cell.
- A field became optional and is now absent on some rows — usually the
interesting rows, the ones where a check has not run.
- A field got nested: { latency: 42 } became { latency: { p50: 42, p95: 81 } }, and the template now stringifies an object.
- An array became paginated: what was [...] is now { items: [...], next: null }, and .map is not a function.

None of these throw on the server. Most do not throw on the client either.
JavaScript's defining characteristic in this situation is that it keeps going.
An absent value propagates through template interpolation and arrives on screen
as blank, as the literal word undefined, or as NaN once it has been through
a calculation. The page looks like a page. It is simply wrong.

What agents changed about the odds

This has always happened, in every codebase with a client and a server written
by different people. What changes when the writing is done by agents is that the
two sides of a contract can now be edited hours apart by processes that share no
memory, and the diff each produces is small enough to approve without opening
the other side.

When the API and the client are edited from two separate sessions, neither
session holds both sides in context. Each makes a locally correct change. One
was asked to round a percentage and did so cleanly, with a test. The other was
asked to add a sparkline and did so cleanly, with a test. Nothing anywhere
contained both facts at once.

It happens with one agent across two sittings for the same reason: the context
that knew the response shape ended when the session did.

And the pull request looks good. A diff adding format!("{:.1}", pct) is small,
tidy, well-named and obviously improving something. It gets approved quickly,
because the question a reviewer asks is "is this change correct" and the answer
is yes. The question that would have caught it — "who else believes this field
is a number" — needs the whole set of consumers in view.

There is machinery for that. A checked-in OpenAPI or GraphQL schema with
generated clients moves the disagreement to build time, and if you have it,
use it — it is strictly better than what follows. The gap is that it only covers the endpoints
described by the schema, and it is a statement about the code in the repository
rather than the pair of services currently deployed.

Integration tests test the version you had

The usual answer is contract testing, and it is a good answer that has a
specific hole.

An integration test asserts that the API and the client agree at the moment
CI ran, against the code in that branch. That is genuinely valuable. It is
also a claim about a repository, not about a deployment.

The things it does not cover are exactly the things that bite:

- The API is deployed and the frontend is not, or the reverse. The two versions
agreed in the repository and do not agree in production.
- The response shape depends on data. The test fixture has a monitor with
results; production has one that has never run, and that row is the one with
the null.
- Something upstream changed. A third-party API you proxy altered its own
payload, and your serialiser passed the change straight through.
- A cache, a proxy, or a CDN is serving a body from before the deploy.
- A rollback restored an older API against a newer client.

In every case CI was green and the deployed pair disagree. The assertion has to
run against the running system, on a schedule, or it is answering a question
about the past.

Assert the shape, continuously

The correction is unglamorous, and it is detection rather than prevention: check
that the deployed endpoint still returns what the deployed client expects,
repeatedly, from outside. It will not stop the deploy. It will tell you within
one check interval instead of within one customer email.

HarpyWatch does this with two checks that do different amounts of work.

json-api requests an endpoint and asserts on the response body itself —
that a path exists, that a value matches, that a field is present. It is the
right tool when there are two or three facts about a response you actually care
about and you do not want to describe the rest of it.

json-schema validates the whole body against a JSON Schema you supply.
This is the one that catches the type change, because a schema says
"type": "number" and "99.9" is not one. It also catches a field going
missing when the schema marks it required, and a field going nested when the
schema says it is a scalar. The check fails at the endpoint that changed rather
than three services downstream, which is what makes the failure legible instead
of a hunt.

You do not need a schema for every endpoint. You need one for the handful whose
breakage would render a screen wrong without erroring — the summary payloads,
the counts, the anything-a-dashboard-draws. For most products that is a handful of
endpoints, not the whole API surface.

Two honest limits

First, a schema is a thing you wrote, and it can rot. If the API legitimately
gains a field and nobody updates the schema, you get either a false failure or,
if the schema is permissive, a silent gap. Schemas need to live next to the code
that produces the response and change with it.

Second, this catches shape, not meaning. uptimepercent: 0 is a perfectly
valid number and may be catastrophically wrong. No schema will tell you that a
value is stale or fabricated — only that it is the right type. Shape
validation is the floor, not the ceiling.

Both limits are worth accepting, because the failure being prevented is the one
that produces a confident, populated, entirely wrong screen — and nothing in either
codebase's type system is going to notice it.

---

## Four hops to nowhere: what refactors do to your redirects

URL: https://harpywatch.com/blog/four-hops-to-nowhere
Author: The HarpyWatch team
Published: 2026-09-22
Kind: article
Tags: Deployment, Monitoring, SEO

A link in a two-year-old newsletter is clicked, and here is what happens before
the reader sees anything:

http://example.com/blog/post-name
→ https://example.com/blog/post-name      (301, http to https)
→ https://www.example.com/blog/post-name  (301, canonical host)
→ https://www.example.com/articles/post-name    (301, section rename)
→ https://www.example.com/articles/post-name/   (301, trailing slash)
→ 404

Five requests. Five DNS-and-connection round trips in the worst case. And the
destination does not exist, because the article was retired in a content cull
and the redirect rule was written against a pattern rather than a list.

Four redirects, added eighteen months apart, each correct when it was written,
and none ever deleted — because deleting a redirect is how you break the thing
it was protecting. Chains are an emergent property: whoever added the fourth
was not looking at the first three, and no file anywhere shows all four
together.

A coding agent changes the rate. Asked to rename a route, it will add the
redirect, which is more than most humans manage — forgetting is the older
failure. But it adds it at whichever layer it happens to be editing: the
framework's route table, or nginx, or the CDN config. Three layers, no single
file that shows the whole picture, and nothing in the task that prompts it to
check whether the target of its new redirect is itself a redirect.

The four shapes, and what each one does

The chain. Two or more hops to reach content. Every hop is a full request
and, when it crosses an origin, a fresh DNS lookup, TCP connection and TLS
handshake. That is several round trips before any bytes of content, so the cost
scales with latency rather than bandwidth: on a mobile connection with 100ms
round-trip time, a cross-origin hop costs several such
round trips on its own, and a faster pipe does not help.
Google's documentation says Googlebot follows up to ten redirect hops in a
single crawl attempt and advises keeping chains short; treating three or more
as a defect is the conventional reading and it is sound. How much link signal survives a
long chain is disputed, and hard for you to measure either way — which is
itself the argument. Point the link at the final destination and the question
never arises.

The loop. /a redirects to /b, /b redirects to /a. Browsers stop
after a fixed limit — Chrome at twenty hops — and show
ERRTOOMANYREDIRECTS. A crawler gives up and drops the URL. This is a total outage for that page and it is
invisible to anyone whose browser has cached an earlier answer, which
frequently includes the person who deployed it. The classic cause is two rules
in two layers disagreeing: nginx forcing a trailing slash while the application
strips it.

The mixed http/https hop. A chain that dips into http, even for one hop,
sends that request in the clear. Any header on it — a cookie without Secure,
a session token in a query parameter — is on the wire. It also gives anyone on the path — a
compromised router, a hostile access point — the chance to rewrite that
response and send the browser somewhere else entirely, before HSTS has had a
chance to apply.
The usual shape is http://old.example → http://new.example →
https://new.example: someone fixed the host and left the scheme to the layer
below, which is one hop too late.

The redirect to a 404. The most common one, and the most damaging. A
pattern-based rule (/blog/(.) → /articles/$1) is written when the sections
matched. Then articles get retired, and the rule cheerfully maps a live inbound
link to a page that does not exist. A 301 into a 404 is worse for you than a plain 404 would have been: the
original URL has been declared moved, and the destination it was moved to
returns nothing. You have retired the old page without producing a new one.

Here is how the treatment differs, roughly:

| Shape | What a browser does | What a search engine does |
| --- | --- | --- |
| One hop, 301 | Follows, caches the redirect | Passes signals, indexes the target, eventually replaces the old URL |
| Chain of 3+ | Follows, pays the latency | Follows, but crawl budget is spent and Google's own advice is to shorten it |
| Loop | ERRTOOMANYREDIRECTS | Drops the URL |
| Any http hop | Follows, request sent in the clear | Follows; the insecure hop is a security finding, not an SEO one |
| 301 into 404 | Shows the 404 | Deindexes the old URL, finds nothing at the new one |

One more distinction, routinely got wrong: a 302 says "keep the old URL,
this is temporary". Six months of a 302 that was always meant to be permanent
means the old URL is still the indexed one. Generated code uses whatever the
framework's redirect() helper defaults to, which is often 302. Check yours.

Why you cannot see this from inside

You can read your nginx config, your route table and your CDN rules and still
not know what happens to a request, because the answer is the composition of
all three plus whatever the CDN does with trailing slashes on its own
initiative. You can reconstruct it from edge logs afterwards, if you have them
and the patience. Making the request from outside and following it answers the
question directly.

That is what HarpyWatch's redirect-chain check does — it is our product, so
weigh the recommendation accordingly. It starts at a URL, follows every hop,
records each status code and location, and reports the full path, the number of
hops, whether any hop was insecure, and whether the terminus is a loop or an
error. Its companion broken-links catches the last shape in the table: it
crawls what your pages link to and reports what does not resolve, including the
links that resolve through three hops into a 404 that clicking around the site
would never reach. Neither is a clever check. Both answer a question that is easy to assume you
already know the answer to.

The limit is real: an external check follows the links it can discover from a
public page, plus whatever URLs you give it explicitly. It does not know about
the inbound link in somebody else's PDF or the QR code on a printed flyer —
exactly the class of link redirects exist to protect, and the class most likely
to point at a URL no one has considered since 2021. For those you have only the
redirect configuration itself, which is an argument for keeping it in one
readable place rather than in three.

Do it before DNS moves

A restructure is a scheduled event. The URLs that will move are known before
the deploy, and so are the chains they will create: both are properties of
configuration that already exists in a branch.

So put the new site on a staging hostname and run the checks against that
before you point anything at it. Take your most-linked URLs, run them through,
and look at the hop counts. A chain found at that moment costs one line in a
config file. The same chain found a month later costs whatever the traffic to
those URLs was worth — and you will not be able to measure that, because
traffic that did not arrive leaves no record anywhere.

---

## Eleven domains nobody approved

URL: https://harpywatch.com/blog/eleven-domains-nobody-approved
Author: The HarpyWatch team
Published: 2026-09-17
Kind: article
Tags: AI Agents, Monitoring, Reliability

Open the network tab on your marketing site and count the distinct hostnames it
contacts. Then try to say, for each one, who added it, when, and which of them
you could remove today.

Most people can account for three or four. Ordinary marketing pages routinely
contact more than twice that, and the gap between the list and the memory is
the subject of this piece.

How the list grows

Nobody sits down and decides on eleven domains. They arrive one reasonable
request at a time.

"Add analytics" gets you a tag. "We need to know which ads convert" adds a
second, from a different vendor, which loads its own partner pixel at runtime.
"Add live chat" brings a widget that pulls its own font and its own error
reporter. Someone trials a heatmap tool for a fortnight and the trial
ends but the snippet does not. A tag manager is installed so that marketing can
add tags without engineering, which works exactly as designed: tags get added
without engineering.

None of this needed AI. What a coding agent changes is the friction — the hour
of someone's attention that used to sit between "we should track that" and a
script tag in production, and that was the only brake on the process. Asked to
add analytics, an agent finds the vendor's documented snippet and puts it in
the layout template, which is what the vendor's own quickstart tells it to do.
It will not ask whether the previous three analytics tools are still needed, or
notice that two of them now collect the same events, because it was asked to
add a thing and the thing was added.

You can build a test that fails when a page acquires a new outbound domain. It
takes a browser-based test that inspects network requests, or a
Content-Security-Policy-Report-Only header with somewhere to send the
reports. Neither is on by default in the frameworks we have used, and neither
appears in the change that added the tag.

Six months of that, and the honest answer to "why does the page contact this
host" is that a ticket, once, implied it.

What it costs, in three separate ways

These are usually discussed as one problem. They are not — they have different
owners and different fixes.

Performance. A third-party script is a request to a host you do not
control, resolved through a DNS lookup and a TLS handshake you cannot warm, on
a connection whose latency and availability are somebody else's operational
concern. A synchronous tag in the head blocks parsing. A tag that injects
further tags at runtime is a request chain your build has never seen and your
performance budget cannot account for, because the second and third hops do not
exist until the first one runs. The heavy part is rarely the bytes; it is the
main-thread time spent parsing and executing them — on a low-end Android
handset, not on the machine you tested it on.

Privacy and compliance. Every one of those hosts receives, at minimum, the
visitor's IP address, user agent, and the full URL of the page — which on a
search results page or an account page can carry more than you meant. Under
GDPR that is processing personal data by a third party on your behalf, which
needs a lawful basis, a record, and usually a line in a privacy policy — and
whether the vendor is your processor or a controller in its own right is a
question with real consequences that most teams have never asked about half
their tags. Your consent banner blocks the tags it
knows about. It does not block the pixel that the tag it allowed loaded on its
own initiative. The organisation's stated position and the browser's actual
behaviour drift apart quietly, and it is often somebody outside the
organisation who notices first.

Supply chain. A <script src> from another origin is not a dependency in the sense
that an npm package is. It is not pinned, not reviewed, and not the same file
tomorrow. The vendor can change it at any moment, and so can anyone who
compromises the vendor, or buys them, or lets a domain lapse. That code then
runs with your origin's privileges: it can read the DOM, read cookies not
marked HttpOnly, and read anything a user types into your forms. The
canonical version of this attack is card skimming injected into a third-party
script on a checkout page — the Magecart pattern — and it is still in use
because it works. The site's own code is perfect throughout. This is the risk
that gets the least attention of the three, and it is the one that ends in a
breach notification.

Why an audit does not fix it

The usual response is to do an inventory. Someone spends a day, produces a
spreadsheet, removes three tags, and everyone feels better.

That spreadsheet is accurate until the next release, and in a stronger sense it
was never accurate at all: it recorded what the page loaded on one machine, in one
country, in one consent state, on one day. Third-party behaviour is
conditional. Tags fire on some pages and not others, for some geographies and
not others, after some interactions and not others. A vendor that loads one
partner today loads four next quarter because they signed a deal, and nothing
in your repository changed.

The thing you actually want to know is not "what did we install". It is what
does a browser contact when it loads this page, right now — and you want to
know it as a continuous fact, so that a new hostname appearing is an event
somebody sees, rather than an archaeological finding six months later.

That is a monitoring question, not an audit question, and it has to be asked
from outside. A build-time inventory cannot see a script that injects another
script at runtime, because that only happens in a browser.

Watching it as a fact

HarpyWatch is our own product, so read this knowing that. Its
third-party-data-flow check loads the page in a browser and records the
origins it contacts, so the set is observed rather than declared. page-weight
measures what actually arrived over the wire, which is where a script that has
quietly tripled shows up as a number rather than a feeling. csp-policy
reports what your Content Security Policy permits: the gap between the origins
you allow and the origins you use is the size of the hole left open. And
cookie-flags and mixed-content catch the two ways a third party most often
degrades the security of a page it was only visiting.

The limits are worth stating. An external check sees what a fetch of a public
URL sees; conditional tags that only fire on a logged-in account page, or only
for one country, are outside its view. And knowing that a domain is contacted
is not the same as knowing what was sent to it — that still needs someone to
open the request and look.

What you get is the list as it is today rather than as anyone remembers it,
and a signal when it changes. Deciding whether the change was approved is still
a person's job. The difference is that the question gets asked while somebody
can still remember the ticket.

---

## Reading a site the way a machine does

URL: https://harpywatch.com/blog/reading-a-site-the-way-a-machine-does
Author: The HarpyWatch team
Published: 2026-09-15
Kind: article
Tags: Deployment, Monitoring, SEO

Open your site in a browser and it looks fine. That is the browser's job. It
follows redirects without telling you, fills in a missing certificate
intermediate from a cache of ones it has already seen, runs the JavaScript that
assembles the page, and recovers from malformed HTML without saying so anywhere
you will look. Some of that shows up in developer tools if you go looking.
Almost none of it shows up in the window.

Much of what visits your site does less. Some crawlers render JavaScript, on a
second pass and not always; plenty take the first response and stop. A link
checker reads a status code. A server-to-server callback often runs against a
trust store that has never seen your site, so nothing is cached for it.

Here is how to look at your own site the way they do. Every command below runs
in a normal terminal and needs no account. Replace example.com with yours.

The first response, with nothing helping it

Start with the raw exchange. -s silences the progress meter, -D - dumps the
headers, -o /dev/null throws the body away.

curl -s -D - -o /dev/null https://example.com/

Note what you did not pass: no -L. curl does not follow redirects unless
you ask, which is the point — you are seeing the first thing your server says,
which is what a lot of software acts on.

Read the status line first. A 200 on the front page is unremarkable. A 301
where you expected a 200 means every client that does not follow redirects is
one hop short of your content, and every link pointing here spends a round trip
it did not need to.

The redirect chain, one hop at a time

Every hop costs a round trip and gives something else a chance to go wrong:
headers dropped, query strings eaten, a cookie set on one host and not sent to
the next. http:// to https:// to www. to a trailing slash is four requests
to serve one page, and nobody built it on purpose — each hop was added
separately and correctly.

curl -sIL -o /dev/null -w '%{numredirects} hops -> %{urleffective} (%{httpcode})n' http://example.com

To see the hops themselves rather than the count:

curl -sIL http://example.com | grep -Ei '^(HTTP/|location:)'

Start from http://, not https://. That is where visitors, old bookmarks and
printed URLs start, and it is the version of the chain that gets tested least.

Two failures to look for. A chain that never terminates — A redirects to B
redirects to A — is invisible to any check that follows redirects and reports
only the final status, because there is no final status. And a redirect that
takes its destination from a query parameter will send a visitor anywhere:

curl -sI 'https://example.com/login?next=https://example.org/' | grep -i '^location:'

If the Location header comes back pointing at example.org, you have an open
redirect. It is a phishing vector wearing your domain, and it is the default
implementation of "return to the page you came from".

What the headers admit

The header block is a statement about how your site expects to be treated. Read
it as one.

curl -sI https://example.com/ | sort

Worth noticing: whether Cache-Control on an HTML document outlasts your
deploy cycle, whether cookies carry Secure, HttpOnly and SameSite, whether
Content-Security-Policy exists at all, and whether
Access-Control-Allow-Origin says  on anything returning private data.

Compression deserves its own command, because you have to ask for it:

curl -sI -H 'Accept-Encoding: gzip, br' https://example.com/ | grep -i content-encoding

No Content-Encoding line means the response came back uncompressed. That is
usually not a config change anyone made — it is a proxy inserted in front, or a
Content-Type the compressor does not recognise, and it shows up as a site
that got slower for no visible reason.

The page without JavaScript

This is the one that surprises people most.


curl -s https://example.com/ | wc -c
curl -s https://example.com/ | grep -o '<title>[^<]'


What you get here is what a client that does not execute JavaScript receives.
For a server-rendered site that is the page. For a client-rendered one it is a
<div id="root"> and a script tag, and every crawler that does not run a full
browser sees an empty document with your title on it.

That is not automatically a problem. It is a problem if you assumed otherwise.

The files you wrote once and never looked at again

curl -s https://example.com/robots.txt
curl -s https://example.com/sitemap.xml | head -40

Disallow: / shipping to production is expensive out of all proportion to its
size, because it works exactly as written: crawlers stop fetching, pages drop
out of the index over the following weeks, the site stays up the whole time, and
the cause is a two-line file nobody has opened since launch.

For the sitemap, check two things beyond it parsing: that the URLs in it are
the canonical ones, and that they still exist. Pull a handful and ask:

curl -s https://example.com/sitemap.xml 
| grep -o '<loc>[^<]' | sed 's/<loc>//' | head -20 
| xargs -I{} curl -s -o /dev/null -w '%{httpcode} {}n' {}

Anything that is not a 200 is a page you are actively telling search engines
to fetch and which is not there.

What the TLS handshake actually presents

Your browser will not tell you your chain is incomplete, because it probably
has the missing intermediate cached from another site.

echo | openssl sclient -connect example.com:443 -servername example.com 2>/dev/null 
| openssl x509 -noout -subject -issuer -dates

That gives you the leaf: who it is for, who signed it, and the validity window.
For the chain as sent, drop the second openssl and read the Certificate chain block at the top of the output: each entry's i: line should be the next
entry's s: line, up to a root the client trusts. If it stops early, your site
works for you and fails for a freshly installed client.

The -servername flag is not optional. Without it you are not sending SNI, and
on shared infrastructure you will be handed a completely different
certificate than a real visitor gets.

To check what the server will actually negotiate rather than what it prefers:

openssl sclient -connect example.com:443 -servername example.com -tls12 </dev/null 2>&1 | grep -E 'Protocol|Cipher'

Swap -tls12 for -tls13, or -tls11 if you want to confirm the old ones
are refused.

And resolution, underneath all of it

dig +short example.com A
dig +short example.com CNAME

DNS fails independently of your servers, and its failures are total: an
NXDOMAIN or a SERVFAIL means no client reaches anything, however healthy the
servers are. It is also the layer most likely to be holding a stale record from
a migration — pointing at an address that still answers, with something older
than you think behind it.

Doing this once tells you about one moment

Everything above is a snapshot, from one machine on one network, of one second.

Run it against a staging hostname before you point DNS at it and you find the
broken redirect, the missing header and the sitemap entry that 404s while they
still cost nothing to fix.

None of these failures announce themselves when they start, though. A chain
shortens on a renewal nobody attended. A header disappears when someone puts a
proxy in front. A sitemap goes stale when a route is renamed. The gap between
the last time you ran these commands and the next is the window in which all of
that is true and unobserved.

Running them on a schedule, from outside your infrastructure, and being told
when an answer changes — that is what monitoring is, mechanically.

A note on what we build, since it is the same thing: HarpyWatch runs this set
and a couple of dozen more against your hostnames and puts the answers in one
grid. There is nothing in it you have not just run by hand. The difference is
the schedule and the memory of the previous answer.

Run the commands first. If the answers are boring, you have learned something
worth knowing.

---

## The outages that live beneath your application

URL: https://harpywatch.com/blog/beneath-the-application
Author: The HarpyWatch team
Published: 2026-09-10
Kind: article
Tags: AI Agents, Monitoring, Reliability

Your application can be perfect and your site can be unreachable. Between a
visitor typing a name and a request arriving at your server sits a system with
no code in it. It has four parts: a registration with an
expiry date, a delegation to a set of nameservers, a zone containing records,
and a chain of resolver caches holding old answers until their TTL runs out.

When it breaks, it usually breaks completely, and it does so with no error for
you to read — the request never reached anything of yours that logs.

Four failures, in order of how quietly they happen

A lapsed registration. A domain is a subscription. It renews on a clock
measured in years, its reminders go to whichever address was on the registrant
record at the time — often a person who has left, or a role alias that was
never forwarded — and the card on file expires long before the domain does.
When it lapses, the name stops resolving, or resolves to a registrar parking
page, which is the more dangerous outcome, because it returns 200. Everything you host is gone from the
internet and the certificate you renewed on schedule has nothing to be
presented for.

A nameserver change nobody propagated. You move DNS providers. The new zone
is built, the records look right, and the delegation at the registrar is
updated — or half of it is. For the duration of the old delegation's TTL,
resolvers are split: some ask the new provider, some ask the old, and the two
disagree. The failure is partial and correlates with which resolver the visitor's network
uses — so the bug reports arrive as "it works for me", truthfully, from
everyone who says it, and you cannot reproduce it from any machine whose
resolver happens to be on the right side.

A record pointing at a recycled IP. This is the one that deserves more
attention than it gets. You tear down a server. The A record stays. That
address goes back into the provider's pool and is allocated to somebody else,
possibly within hours. Now your hostname resolves to a machine you have no
relationship with. staging.example.com serves a stranger's site — and because
your name still resolves and something answers with a 200, any check that
asserts only "connected, status code below 400" is green. Worse, whoever now holds that address can satisfy an HTTP-based domain
validation challenge for your hostname, because the challenge is served from
whatever the record points at. They do not need your registrar account. They
need only the machine your record still names.

A record that was right and stopped being. A CNAME to a platform that
renamed its endpoints. A TXT record for domain validation that was cleaned up
by someone tidying a zone. An MX record removed alongside a service
migration, so the domain is fine and the mail is not — including, if you are
unlucky, the mail your registrar sends about expiry.

Why this class is different

Three properties, shared by all four.

Not in the code, so review does not reach it. There is no diff and no test.
The change happened in a registrar's console or a DNS provider's UI, possibly
months ago, possibly by someone who no longer works with you.

Not local, so a development environment cannot reproduce it. Your machine
has a resolver cache, an /etc/hosts file and a browser that has been open for
days, and all three lie in the same direction.

Cached, so breakage and visibility are separated by a TTL you set long ago
and have forgotten. A 24-hour TTL means a bad record published today starts
failing tomorrow, for some people, in an order set by their resolvers.

The agent-adjacent part

None of this is caused by an agent. An agent cannot let your domain lapse and
cannot change your delegation. That is why it is worth writing about: the
registrar account and the zone were never in a file anyone was reading, and
they do not become better understood because the code around them got easier
to produce.

Concretely: an agent asked to move a site to a new host will change what needs
changing in the repository and tell you what to point at it. It will not ask
which of your other twelve A records still names a machine you own, because
that question has no artefact. Nobody is being careless. There is nothing to
review.

What to observe, and from where

Two checks cover most of it, and both have to run from outside your network,
against public resolvers, on a schedule.

dns-resolution resolves the name the way a visitor's resolver does, and
reports what came back. It catches the delegation that half-propagated, the
record that disappeared, and the resolution that started failing while your own
laptop kept serving a cached answer. It is deliberately upstream of everything
else in a monitoring grid: if this is failing, no result below it means
anything, and a set of checks that all fail together with dns-resolution at
the top is a different sentence from a set that fail independently.

domain-expiry watches the registration itself, against a date known years
in advance — which makes it the most preventable outage on this list. The alert
is useful weeks out, not days. Auto-renewal and a calendar reminder do most of
this job; the check exists because both of those depend on an account and a
payment method nobody has looked at recently, and it is the only one of the
three that fails loudly rather than quietly.

Two things this pair does not do, stated plainly. Neither tells you whether the
address a record points at is still yours — resolution succeeding and the
answer being correct are different questions, and the recycled-IP case
satisfies the first while failing the second. Checking that is an inventory
problem: what you own, what you resolve to, and the fact that those two lists
should reconcile. And neither watches your registrar account, your renewal
payment method, or who receives the reminder. Those live in an account nothing
external can see.

For the recycled-IP case specifically, the closest external signal is content:
dom-content against a hostname you expect to serve your page will notice
when it starts serving somebody else's. That is a coarse instrument, and it
only works on hostnames you thought to check.

The unglamorous conclusion

There is no clever mechanism here. This layer fails differently from your
application because nothing about it is in version control: the changes are
made in a web console, by whoever had the login, on a clock measured in years
rather than deploys, and there is no artefact recording that they happened.

The defence is unglamorous too: something outside your infrastructure resolves
your names regularly and tells you when the answer changes, and somebody can
state the expiry date of every domain you own without logging in to find out.
That is the difference between a five-minute fix and a weekend on the phone to
a registrar's support queue, arguing about a name that has entered its
redemption period.

---

## A status page is a sales asset, if it is honest

URL: https://harpywatch.com/blog/a-status-page-is-a-sales-asset
Author: The HarpyWatch team
Published: 2026-09-08
Kind: article
Tags: Monitoring, Product, Reliability

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.

---

## The agent will make the check pass

URL: https://harpywatch.com/blog/the-agent-that-fixed-the-symptom
Author: The HarpyWatch team
Published: 2026-09-03
Kind: article
Tags: AI Agents, Monitoring, Reliability

A test fails intermittently. You hand it to an agent and say: make this stop
failing.

There are two things it could do. It could work out that the test starts a
server and asserts against it before the port is listening, and make the
assertion wait on the actual readiness condition. Or it could wrap the
assertion in a retry with a short sleep.

Both make the test green. One takes forty minutes of reading and a guess that
might be wrong. The other takes nine seconds and almost always works, because a
retry loop converts an intermittent failure into an intermittent delay.

Only one was asked for. Both satisfy the request as stated.

This is not a complaint about agents

You can file this as a quality problem — better models read more carefully,
better prompts say "fix the root cause" — and get some of the way. The
structure underneath does not move: when you give something a signal and ask it to turn
the signal green, you have specified the signal, not the property you wanted.
An optimiser takes the cheapest available route to a satisfied condition. If a
route exists that does not involve fixing anything, it is a correct solution to
the problem you actually posed.

Humans do this too, and we have a whole vocabulary for it — teaching to the
test, gaming the metric, Goodhart's law. What is different now is throughput and
traceability. When a person suppresses a warning to get a build through, there
is someone who knows they did it. When forty files acquire the same treatment in
an afternoon there is no such record, and each line reads as reasonable.

The shape of a symptom fix

The pattern is easy to recognise once you have the category, and hard to see one
commit at a time. The same move, five ways:

| The complaint | The cheap green | What went unfixed |
| --- | --- | --- |
| This page is slow | Add a long Cache-Control max-age | The query behind it |
| This test is flaky | Retry three times | The race |
| This request fails sometimes | Raise the timeout | Whatever takes that long |
| Type error at this line | Widen the type, or cast | The value that should not be there |
| This check is noisy | Loosen the threshold | The thing crossing it |

Every one of these is a legitimate engineering action in some context — a cache
header is often exactly right, a timeout is sometimes genuinely too tight. That
is what makes the category hard to police: the symptom fix is not a wrong
action, it is the right action applied for the wrong reason, and the reason is
not in the diff.

The cache header case is worth sitting with, because the damage is delayed and
lands somewhere else. A slow page gets a max-age. The page is now fast for
anyone who receives a cached copy, the measurement improves, and the report says
the work is done. The query is still slow — for the first visitor after every
deploy, for every authenticated request that cannot be cached, and for the
database, which now does the same expensive work in bursts after each deploy and
each eviction: lower on average, spikier, and on nobody's graph. And a second
failure mode has been added, one that did not exist before: a document cached
longer than it should be, serving last week's content after this week's
deploy.

The property that distinguishes a good signal

If the cheapest satisfying route is the one that gets taken, the useful
question is not "how do I stop it doing that". It is what does the cheapest
route cost when the honest one is the only route available.

Signals differ enormously in that.

An assertion inside your own repository is the weakest case. The thing measured
and the thing measuring live in the same tree, under the same permissions, and
whatever must satisfy the check can also edit the check. Deleting the assertion,
weakening the fixture, adding skip — all one-line fixes, none of which stand
out in a diff of two hundred lines. Such a signal is only as strong as the
attention of whoever reads that diff, and attention is what runs short first.

A signal measured from outside is a different kind of object. If the statement
is "a GET to https://example.com/pricing from a machine you do not control
returns a 200 with the expected content, a valid certificate chain, and a first
byte inside a budget", then there is no edit that makes it true except making
it true. You cannot cache your way past a redirect loop. You cannot retry your
way past a missing intermediate certificate — the client either builds a path
to a trusted root or it does not. No cast, threshold or annotation makes a
sitemap's URLs return 200 when the pages behind them have been deleted.

The boundary matters, because the cache example above crosses it. A
Cache-Control header does make an external latency measurement faster without
the query getting faster, and that is a real limit on this argument. What
resists it are the checks whose subject is a fact rather than a budget: what
the chain contains, where a redirect terminates, whether a sitemap's URLs return
200, whether the rendered page contains the string it should. No header changes
those. Thresholded signals can be moved by configuration; factual ones cannot,
and that is which to rely on.

What this asks of you, practically

Three things follow, and none of them require distrusting the agent.

Keep at least one signal outside the blast radius of the change. If every
check that reports on your site can be edited by the same session that edited
the site, you have one system reporting on itself. It is the same argument as
not running monitoring on the servers it monitors, moved one layer up: there the
compromise is availability, here it is authorship.

Prefer checks that assert on what a visitor gets. Response status, rendered
content, headers on the wire, the certificate actually presented, the redirect
chain a browser follows. These are facts about the deployed system rather than
the repository, and they stay true statements regardless of who wrote the code
or how carefully anyone read it.

Look at the deployed thing before the traffic does. None of this has to
wait for an incident. Point the same external checks at a staging hostname and
read the result before you move DNS. The redirect that loops, the header that
vanished, the page that renders a stack trace — all visible to an outside
request the moment the thing is reachable.

The honest limit

An external check cannot tell you that the retry was the wrong fix. It never
looks at your repository, so a suppressed test and a passing one are the same
thing to it. If an agent papers over a race condition, HarpyWatch will not
notice, and neither will anything else that observes from outside — right up until the race produces a
response a visitor can see, which is exactly the moment it becomes our problem
rather than yours.

So this is not a replacement for reading the diff. It is the part of
verification that does not depend on anyone having read it — and as the volume
of generated change rises, the share of it genuinely reviewed falls.

Prefer the checks whose only cheap route runs through the actual repair. They
do not remove the need for someone careful — the piece above is a list of the
gaps they leave — but they shrink the set of problems that can be closed
without being solved, and that set is where the expensive surprises live.

---

## Your monitor cannot live in the thing it monitors

URL: https://harpywatch.com/blog/your-monitor-cannot-live-in-the-thing-it-monitors
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: Monitoring, Reliability

Some outages announce themselves. The worst ones arrive as an absence: the
graphs stop, the checks stop reporting, and for the first several minutes the
on-call engineer's only evidence that anything is wrong is a customer email.

When that happens, there is usually one reason. The thing doing the watching
was standing on the thing that fell over.

A monitor is only as independent as its worst common dependency

Consider four common arrangements, in increasing order of sophistication. They
fail in different ways, and they share one property.

A /healthz endpoint in the application. It reports the application's view of
itself. When the process is dead, nothing serves the endpoint, and the answer
is not "unhealthy" — there is no answer. Something else has to notice the
absence, and that something else is usually the next item on this list.

A cron on the same box that curls the site and emails on failure. One host, two
processes. Kernel panic, full disk, an OOM killer that took both processes, a
systemctl stop in the wrong terminal — the site and its watcher die in the
same instant.

An uptime pod in the same Kubernetes cluster. That survives a single node
failing, which is real progress. It does not survive the ingress controller
misrouting after a bad config reload, CoreDNS failing so that no pod can
resolve anything, an expired kubelet client certificate taking nodes NotReady
in a block, or the API server being unreachable so nothing gets rescheduled.
Those are the failures that take out the whole service, and they take the
watcher with it.

A monitoring stack in the same cloud region, on separate instances. Stronger
still — and still sharing a region, an account, a network path and, usually,
the same nameservers.

Each of these measures something real. The limitation is the question they are
all asking: is the service healthy from inside the environment the service
runs in. Outages have an inconvenient habit of being facts about that
environment.

The domains that get held in common

It is worth naming them individually, because most setups eliminate one or two
and quietly keep the rest.

The host. Covered above, and still the most common arrangement there is.

The network. A security group change, a firewall rule, a route table, a
misapplied network policy. Internal traffic between your monitor and your app
often takes a completely different path from a visitor's traffic — private
subnet, service mesh, cluster DNS. The check can succeed over the path that
still works while the path the public uses is severed.

DNS. This is the one that catches careful teams. Your internal check
resolves api.internal or hits a service IP directly, or has the record in a
local cache with a long TTL. A visitor resolves the public name through public
resolvers. When a zone update goes wrong, when a registrar's nameserver
delegation lapses, or when a DNSSEC signature expires, the internal check
continues to pass with total confidence. Nothing is wrong with the server. The
name simply no longer points at it.

The certificate. A check that connects over plain HTTP inside the cluster,
or with verification disabled because the internal name does not match the
certificate, cannot see an expired or misissued certificate on the public
edge. TLS is terminated at a load balancer or a CDN that the internal check
never touches. The socket a browser connects to is a different socket.

The cloud region. When a region's load balancer control plane, its managed
database, or its object storage degrades, it takes the workload and everything
you deployed alongside it — including the Prometheus that was going to tell you
about it. This is the case people plan for on paper and rarely test, because
testing it means already having something outside the region.

The account. The one that rarely makes it onto the diagram. A billing failure, a
suspended account, an expired card, a compromised credential that gets
everything disabled, an IAM policy change applied a bit broadly. When the
account goes, every service in it goes, and that includes the alerting.

What an outside check sees that an inside one cannot

An external check is a request from a machine that has nothing in common with
yours: a different network, a different resolver, no credentials, no privileged
path, no knowledge of your topology. That poverty is the feature.

It resolves your public hostname the way a visitor does, so a broken delegation
or an expired DNSSEC signature is a failed check rather than an invisible one.
It completes a real TLS handshake against the public endpoint, so
ssl-cert-expiry and cert-chain-trust read the certificate that was actually
presented — not the file on disk, and not the internal certificate. It follows
the redirect chain a browser follows, through the CDN and the load balancer and
whatever else sits in front, so a loop introduced between two correctly
behaving components shows up as a loop. It carries no cookie and no session, so
a page that only works for someone already logged in fails, which is usually
what you wanted to know.

And when your infrastructure is entirely gone, it keeps running, because it was
never part of it. That is the point worth stating plainly: in the minutes
when every tool inside your environment has stopped reporting, a check outside
it is still in a position to answer. It has its own ways of failing — a
provider outage, a routing change, an expired credential — and those are mostly
not your ways of failing. Mostly, not entirely: if the check runs in the same
region as the site, a regional event still takes both. Independence is a thing
you get more or less of, and the amount you get is the whole benefit.

Be honest about what it gives up

External observation buys independence by giving up detail, and pretending
otherwise would be dishonest.

An outside check sees a 500, not the exception that caused it. It cannot tell
you which of four backends is failing, that the connection pool is exhausted,
that a queue is backing up, or that a disk will be full in six hours. It has no
per-request tracing, no logs, no memory profile. Its sample rate is a schedule,
not every request, so a failure affecting one visitor in fifty may not land in
its window — availability-sample exists to narrow that gap by probing
repeatedly, and narrowing is not eliminating.

It is also blind to everything behind an authenticated boundary. Whatever your
logged-in users see, an unauthenticated check does not.

So this is not an argument against internal instrumentation. Metrics, logs and
traces are how you find out why, and nothing outside your network can replace
them. The argument is narrower and firmer than that: the signal that tells you
whether, and the alert that has to fire when everything is broken, cannot
be hosted on the thing it is watching.

Two different tools, two different jobs. HarpyWatch is the outside one: the
checks run from our infrastructure against your public hostnames, on a
schedule, and they keep running when yours does not. If your alerting today
would have gone quiet in any of the six failure domains above, that is worth
fixing first, whoever you fix it with.

---

## The deploy succeeded. That is not the same as the deploy working

URL: https://harpywatch.com/blog/the-deploy-succeeded-and-the-site-is-down
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: Deployment, Monitoring

A pipeline that goes green asserts five things. The image built. The image was pushed.
The orchestrator accepted the new revision. The new containers reached the
state the orchestrator calls ready. The old ones stopped.

Every one of those is a statement about your release machinery, and not one of
them is a statement about whether a person can use your website. The pipeline
is not wrong. It answered the question it was asked, and nobody ever pointed it
at the one you actually have.

What a successful deploy is compatible with

This is the useful exercise: hold the pipeline green and ask what could still
be true.

An empty database. The migration step ran against the wrong connection
string, or ran against a fresh instance, or the seed step was skipped in this
environment. The application starts perfectly — it has no opinion about how
many rows exist. Every page renders its empty state, which in a well-built
product looks like a design decision rather than a disaster.

A missing environment variable. A new setting was added to the code and to
the local .env and not to the deployed secret store. If it is read at startup
with a default, the process starts and behaves subtly wrongly. If it is read
lazily, the process starts and the first request that touches that code path
throws — which is to say, the process is healthy and the feature is dead.

A certificate that did not renew. The deploy has nothing to do with the
certificate. The renewal has been failing since a DNS challenge broke, the
notification goes to an alias nobody reads, and the release you just shipped
lands behind a TLS handshake that browsers now refuse. Deployment succeeded.
The site is unreachable.

A CDN serving the previous build. The origin has the new bundle. The edge
has a cached copy of the old HTML with long Cache-Control, and it is serving
that to everyone. Your deploy is live and no visitor is receiving it. The
nastier variant is a partial one: new HTML, cached old JavaScript, hashed asset
names that no longer match, and a page that loads and then does nothing.

A health endpoint returning 200 while every real route 500s. This one
deserves the most attention, because it is the mechanism the rest of the system
trusts. A readinessProbe pointed at a /healthz that returns a static OK
proves the HTTP server is listening. It does not touch the database, the
template engine, the session store, the object storage or a single line of your
own code. So the pods are marked ready, the service starts routing to them, the
previous revision is retired and the rollout reports success — while /,
/pricing and /login all throw. Nothing malfunctioned. The probe was told to
check the wrong thing, and it checked it perfectly.

A rollout that only half happened. With maxUnavailable set, a rollout is
declared complete once enough replicas report ready — the rest can be
crash-looping behind the same service. Traffic is load-balanced across the
survivors and the failures, so the site is broken for a fraction of requests
rather than all of them. Intermittent is worse than total: whoever checks once
and lands on a working instance reports that it is fine.

None of these are exotic, and they share one property: no part of the release
process can detect them, because in every case the release process did its
job.

The gap is structural, not a gap in tooling

The instinct is to add a better health check. Make /healthz query the
database. Have it render a template. Add a smoke test to the pipeline.

Those are improvements and you should make them. They do not close the gap, for
a reason that does not go away with effort: a check that runs inside the
deployment inherits the deployment's context. It runs on the cluster network,
so it never traverses the CDN or the public load balancer. It usually connects
over plain HTTP internally, so it never performs the TLS handshake that is
broken. It resolves an internal name or a service IP, so a public DNS record
still pointing at the old load balancer is invisible to it. And it runs with
the environment the deploy provides, which is by definition the environment
that looked correct to whoever configured it.

Most of the failures above live in the space between the container and the
visitor. Nothing that stays inside that boundary can see them.

There is also a timing problem. A pipeline smoke test runs once, at the moment
of the deploy. A CDN that will serve stale HTML for six hours is not stale yet
when the test runs. A certificate expiring on Thursday passes on Tuesday.
Deploy-time verification is a snapshot, and several of these failures are
functions of time rather than of the release.

The only honest confirmation

The confirmation that a deploy worked is an unprivileged request from outside,
to the public hostname, made by something that shares nothing with your
infrastructure — and repeated, because the answer changes without you.

That is not a philosophy. It is a list of specific requests, and it maps
directly onto the failures above:

| What could be wrong | What settles it from outside |
| --- | --- |
| Every real route 500s behind a green /healthz | http-uptime against the routes people use, not the health path |
| The page is up and the content is a stack trace or an empty state | dom-content asserting a string that only appears when it worked |
| The certificate did not renew | ssl-cert-expiry and cert-chain-trust on the presented certificate |
| The CDN is serving the previous build | cache-policy on the HTML document, and browser-render on a page that needs its bundle |
| The public name points at the old load balancer | dns-resolution |
| Half the replicas are crash-looping | availability-sample — repeated probes distinguish flapping from down |

What every row has in common: the request carries no credentials, no session
and no cluster network. It is the request your visitors make, which is the only
one whose answer is the thing you wanted to know.

Where the line is

An external check will not tell you why. It sees a 500, not the exception; a
timeout, not the exhausted connection pool. It runs on a schedule, so there is
a window between a deploy going wrong and the check noticing. It cannot see
anything behind a login. Your logs, metrics and traces remain the tools for
diagnosis, and nothing outside your network substitutes for them.

But diagnosis is the second question. The first is whether the site your
customers are looking at right now is the site you think you shipped — and
that one is settled by making a request from outside, or it is not settled at
all. HarpyWatch is one way to make it, on a schedule, with the same limits
above. What matters is that something makes it.

---

## The agent shipped it and nobody read it

URL: https://harpywatch.com/blog/the-agent-shipped-it-and-nobody-read-it
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: AI Agents, Reliability

An agent finishes a session with a summary. Eleven files changed, three routes
added, the build passes, the dev server returns 200 on every page it visited.
The summary is accurate. Every sentence in it is true.

Then somebody who was not in that session opens the site in a browser they did
not configure, on a host that is not localhost, without the session's
environment, and gets a 500.

Nothing lied. The agent checked what it could reach: the routes it had just
touched, from the machine it was working on, in the state that machine was
already in. That is a much smaller set of conditions than a stranger arrives
with, and the difference between the two sets is where the defects now live.

What the difference actually contains

These are not exotic failures. They are the ordinary consequence of writing
code in a session that holds state a visitor does not have.

Pages that render for the author and 500 for everyone else. The agent hit
the route while a record it had just created was still in the database, while a
feature flag was still on, while it was still authenticated from an earlier
step. The page is a function of that context. Delete the context and the
function throws.

Links to routes that were renamed mid-session. An agent working through a
long task renames things as its understanding improves — that is a virtue, not
a bug. But the rename lands in the router and in nine of the eleven templates
that referenced it. The two it missed are the ones that were not open at the
time. A 404 does not fail the build.

Forms that post nowhere. The markup is correct, the fields are labelled,
the submit button is styled, and the action points at /api/contact while
the handler was registered at /api/v1/contact. Or the handler exists and only
accepts POST from an origin the deployed hostname is not on. The form looks
finished in every way a screenshot can show, and the failure only happens after
somebody types into it.

Assets referenced at a path that only exists locally. An image at
/uploads/hero.png that lives in the working tree and was never part of the
build output. On the developer's machine it resolves. In the container it is a
404, which most browsers render as a broken layout rather than an error.

A redirect loop between the framework and the proxy. The application router
is configured to add a trailing slash and 301s /pricing to /pricing/. nginx
has a rewrite that strips it and 301s back. Each component is doing exactly
what it was configured to do; together they never terminate. A check that
follows redirects and reports the final status code has nothing to report until
its hop limit runs out.

There is a common shape here. In every case the code is defensible, the tests
that exist pass, and the failure requires an environment nobody who wrote it
was standing in.

Why review does not close the gap

The obvious answer is to read the diff. Two things get in the way.

The first is arithmetic. A session can produce more changed lines than
a person will read carefully in an afternoon, and it can do that again before
lunch. Reviewing capacity did not grow when writing capacity did, and no amount
of discipline closes a ratio.

The second is that human review, even done properly, is aimed at a different
target. Code
review is good at finding logic that is wrong, structure that will not survive
the next change, and decisions that need discussing. It is quite bad at
noticing that the third link in a footer points at a path that no longer
exists, or that a page depends on a session variable that a first-time visitor
does not have. Those are not judgement calls. They are facts about the deployed
site, and they are only observable by making a request to it.

Verification has to become automatic because authorship already did

If code is now written at machine speed, then the only check that keeps up is
one that also runs at machine speed, and the only useful vantage point is
outside.

The difference matters more than it sounds. A test suite runs in an environment
built to make it pass — fixtures loaded, environment variables set, network
stubbed. That is the correct design for a test suite, and it is exactly the
environment that hides all five failures above. An unauthenticated HTTP request
from another machine has none of that context, which is precisely why it is
worth making.

Of the checks HarpyWatch runs, a handful are aimed squarely at this class of
defect:

| Check | What it catches that a session cannot |
| --- | --- |
| http-uptime | The route answers at all, from outside, with no session |
| dom-content | The page is up and the content is not a stack trace |
| broken-links | The nine templates that were updated, and the two that were not |
| redirect-chain | The loop between the framework and the proxy |
| browser-render | Pages that only assemble once JavaScript runs, and do not |
| mixed-content | Subresources the browser will silently refuse to load |

These are the same requests a visitor makes, made on a schedule by something
that carries none of the session's context.

What this does not do

An external check will not tell you the code is good. It has no opinion on your
architecture, it cannot see that a function is quietly O(n²), and it will not
catch a bug that requires a specific sequence of user actions to reach. It
observes surfaces.

It is also a thing you have to configure and keep correct. A dom-content
check asserting a string that legitimately changed is a false alarm, and an
alert that cries wolf gets muted, which is the same as not having it.

It cannot tell you that a page is wrong in the semantic sense. A
dom-content check knows whether a string you nominated is present. It does
not know that the pricing table now shows last quarter's numbers. Somebody who
knows what the numbers should be still has to look.

What it does is remove an entire category of failure from the list of things a
human has to hold in their head — the category where the site is broken in a
way that any request would have revealed, and no request was made. That
category is small per incident and enormous in aggregate, and it grows in
direct proportion to how fast you are shipping.

The honest version of the rule

You do not have to trust the agent less. The summary at the end of the session
was true, and being suspicious of it is not a strategy — you cannot re-read
your way out of a volume problem.

You have to make the site prove itself to something that was not in the room.
Continuously, because the next session starts in twenty minutes, and from
outside, because the inside is where all the assumptions live.

That does not cover everything, and the section above says what it misses. It
covers the part that scales with your shipping rate, which is the part that has
stopped being manageable by hand. HarpyWatch runs those requests on a schedule
and tells you when the answer changes.

---

## Knowing before your customers do is the whole product

URL: https://harpywatch.com/blog/knowing-before-your-customers-do
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: Monitoring, Product, Reliability

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.

---

## Diagnose before you deploy, not after

URL: https://harpywatch.com/blog/diagnose-before-you-deploy
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: Deployment, Monitoring

A redirect chain that ends in a loop is a five-minute fix on a Tuesday
afternoon. The same loop, discovered because the traffic arrived, costs a
rollback, an incident channel and an apology.

The defect is identical in both cases. Only the timing changed — and the loop
never needed a visitor to be visible. It was there on the staging hostname,
answering requests, waiting for anyone to make one.

What a URL will tell you before anyone visits it

Redirect behaviour, headers, certificates, crawl policy and page weight are all
decided by the response itself rather than by the load, which means one request
settles each of them. Send that request to staging.example.com and you
learn:

The redirect chain. How many hops, in what order, whether it terminates,
and whether the scheme or host changes on the way. A chain that goes HTTP →
HTTPS → www → trailing slash is four requests before a byte of content, and a
chain where two components each redirect to the other never terminates at all.
Loops survive in production for a long time, because a client that follows
redirects and reports the final status has nothing to report until it gives
up.

The headers. Whether Strict-Transport-Security is set, whether the
Content-Security-Policy is the permissive staging one, whether cookies carry
Secure and HttpOnly and SameSite, whether Cache-Control on an HTML
document will cause a CDN to serve today's deploy for a week. Headers are
configuration, and configuration is exactly the thing that differs between
environments and gets copied from the wrong one.

The certificate chain. Not just expiry — the chain, in order, to a trusted
root. The classic failure here works in the browser you tested with, because it
has cached the intermediate from some other site, and fails in a freshly
installed client or a payment processor's callback. You do not need traffic to
see it. You need a handshake from a machine that has never visited you before.

The robots policy. Whether the file you are about to publish says
Disallow: /, which is the correct thing for a staging host and a catastrophe
on a production one. This one is worth catching here more than any other on the
list, because it produces no error, no exception and no complaint — just
traffic that stops weeks later, long after anyone would connect it to a
deploy.

The sitemap. Whether it parses, and whether the URLs in it exist and belong
to the hostname that is about to be live. A sitemap generated in staging lists
staging URLs. Shipped as-is, it is a document telling crawlers your site lives
somewhere that will shortly stop answering.

Page weight and content. Total transferred bytes, and whether the rendered
DOM contains what it should. An unminified bundle, a source map shipped by
accident, a 4MB hero image nobody compressed. And a page that returns 200 while
displaying a database error is up by every measure except the one that matters.

Broken links. Every internal link resolved. This is the check that catches
the routes renamed halfway through a session, where the router and nine
templates agree and two do not.

Every item on that list is a fact about a response. Not one of them needs a
real visitor.

Why later is more expensive than it looks

The cost of finding a defect after DNS moves is not mainly the fix. It is
everything the fix has to travel through.

The change now needs a deploy under pressure, with someone watching, rather
than a deploy nobody is timing. If a
CDN is in front, the wrong response is cached and the fix does not take effect
when you make it — it takes effect when the cache expires, or when someone
finds the purge button. If a crawler already read the wrong robots file or the
wrong canonical tag, the damage is now in a system you do not control and
cannot purge, and the recovery is measured in weeks. If customers saw it, the
cost includes the conversation about why.

None of that applies to a hostname nobody has heard of. On staging, the same
defect is a config line and a redeploy that nobody notices.

What we actually have, and what we do not

Here is the honest shape of it. HarpyWatch has no CI integration. There is
no build step you can add, no GitHub Action, no CLI that fails a pipeline, and
no one-click "diagnose this URL" form. If you were hoping to gate a merge on
this, that does not exist today.

What exists is that a monitor is a hostname and a schedule, and nothing about
that requires the hostname to be in production.

So the workable pattern is this one:

1. Add your staging hostname as a monitored asset, alongside your
production one. Same checks, different host.
2. Deploy the release to staging and let the checks run against it. The
redirect chain, headers, certificate chain, robots policy, sitemap, page
weight and links are all evaluated against the build that is about to go
live.
3. Read the grid before you move DNS. The cells that are red on staging are
the cells that will be red in production, because they follow from the
configuration and the content rather than from the traffic.
4. Keep the staging monitor. It is not a one-off. It stays as the place
where the next release's configuration errors show up first.

The awkward part of that pattern deserves saying: it is a schedule, not a
trigger. The checks run when they are due, so there is a window between
deploying to staging and the results being fresh, and you have to actually go
and look. It is a person reading a grid at the right moment rather than a
pipeline refusing to proceed. That is a genuine difference and we are not going
to pretend otherwise.

The part that does not transfer

Be careful about what a staging result proves. Some findings belong to the
environment rather than the release, and those will differ:

- The certificate on staging is not the certificate on production. Chain
problems caused by the issuer's configuration transfer; problems caused by
one host's renewal not reloading do not.
- Anything behind a CDN that only fronts production is untested on staging, and
cache policy is exactly where the two diverge.
- If staging is password-protected or IP-restricted, many checks will see the
gate rather than the site, and the result is about the gate.
- Performance numbers from a smaller staging box are not production numbers.
ttfb-budget on staging tells you about a gross regression, not a budget.

So a clean staging grid is not a promise. It removes one specific, large and
boring set of failures — a staging robots file, a permissive CSP, a stale
canonical, an unreloaded cache header — before they can reach anybody. Everything on that list costs a config line and
a redeploy while the hostname is still private, and a rollback once it is not.

---

## Your agent built a single-page app and the AI crawlers see an empty div

URL: https://harpywatch.com/blog/an-empty-div-to-the-crawler
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: AI Agents, Monitoring, SEO

Run this against your own marketing site:

curl -s https://example.com/ | head -c 2000

You are looking for one thing: is your actual copy in there? The headline, the
paragraphs, the product names. If what comes back is a <head>, a couple of
script tags, and <div id="root"></div>, then that is what the AI crawlers see
when they ask for your page.

Not a browser. A client. The distinction matters more every month.

Why the page came out this way

Ask an agent for a landing page and you will very often get React, or Next, or
Vite with a client-side router. That is not mysterious: those are the stacks
with the most public code, the most tutorials and the most StackOverflow
answers, so they are the stacks a model has seen most. It is a reasonable
default too — the patterns are well documented and the result works when a
person loads it.

The prompt was "build me a landing page". The answer was a component tree that
assembles itself in the browser. Nobody in that exchange made a decision about
rendering — it arrived as the shape of the answer — and the review that followed
happened in a browser, where the difference does not show.

What actually reads HTML now

Here is the mechanism, stated as precisely as we can without overclaiming.

Googlebot renders JavaScript. It has done for years. Pages go into a
rendering queue, get executed in a headless Chromium, and the rendered content
is indexed. This is real and it works. Two caveats survive: rendering happens on
a delay after the initial fetch, and it is subject to a budget — a large site
that is entirely client-rendered is asking for a great deal more crawl resource
than one that ships HTML. For a small site the delay is usually the only cost.

The AI crawlers largely do not — and this is an observation about what they
fetch, not a claim about how they are built, because nobody outside those teams
knows that. GPTBot, ClaudeBot, PerplexityBot and CCBot (Common Crawl, a major
input to open training corpora and to several retrieval pipelines) request a URL
and generally do not follow it with the pattern of subresource requests a
browser makes. If the server sends a shell that needs
JavaScript to become a page, the shell is what gets stored.

This is not a fixed law and we would not want to state it as one. Some of these
operators run a rendering step for some requests, retrieval products often fetch
a page live at query time with different machinery from their training crawler,
and none of it is announced when it changes. Which is the argument: do not
assume execution, and do not assume it stays the same. Measure what your server
sends.

The consequence is not a ranking penalty. It is simpler and worse. Your page
exists in these systems as a document with no content in it. When someone asks
an assistant what your product does, whatever it says came from somewhere else —
a directory listing, a competitor's comparison page, a forum thread.

The same failure, three other places

Client-only rendering breaks more than crawlers, and the other cases are useful
because they are easier to test.

- Link previews. Slack, WhatsApp, iMessage and LinkedIn unfurl links by
fetching HTML and reading meta tags. If the title and description are set by
JavaScript after mount, the preview is blank or shows the framework default,
so every link anyone shares to your site looks broken.
- Fetch-and-parse clients generally. Feed readers, archive crawlers and many
security scanners fetch and parse without executing. Some archive and scanning
tools do drive a browser; most of the long tail does not.
- The first paint for a real person on a bad connection. A shell plus a
bundle plus a data fetch is three round trips before there are words on the
screen. This is a user experience problem before it is anything else.

What to check, and how

The useful question is not "does my site work" — it does — but "do these two
things agree":

1. What the server sends on a plain HTTP request.
2. What exists after a browser has run the JavaScript.

If they differ substantially, the gap is exactly the content that does not exist
for a non-executing client.

You can do this by hand with curl, and you should, once, right now, for your
most important three pages. curl -s <url> | grep -i "<your headline>" is a
five-second answer to a question most teams have never asked.

Doing it continuously is what monitoring is for. We build one, so the two checks
below are ours — the point is the pairing, which you could assemble from curl
and a headless browser yourself:

dom-content fetches the URL as an HTTP client and asserts on what came
back — a string is present, a selector matches, a phrase you expect is in the
document. No JavaScript is executed. That is the point: it is a measurement of
what a client that does not execute JavaScript receives.

browser-render loads the page in a real browser and asserts against the
result after scripts have run.

Running both against the same URL turns an invisible architectural decision into
a visible one. browser-render green and dom-content red is not two failures.
It is a single sentence: this page only exists if you execute JavaScript.
Sometimes that is fine — an authenticated dashboard has no crawler audience.
For a pricing page it is a problem you would want to have chosen deliberately.

What we did about our own

This blog is server-rendered. The rest of HarpyWatch's front end is an Angular
application, because it is an authenticated grid of check results that no
crawler will ever see. Same codebase, two rendering strategies, because the two
surfaces have different audiences.

That is not a clever trick; it is the ordinary answer. It is worth mentioning
only because the question has to be asked per surface, and the failure happens
when one answer gets applied to everything by default.

The code change is smaller than the decision

Most frameworks that produce this problem also solve it. Next has server
components and static generation; Nuxt, SvelteKit, Remix and Astro all ship HTML
without needing a client to assemble it. Angular has SSR. Nobody has to leave
their stack.

That is not the same as free. Turning on server rendering in an application that
was not written for it brings hydration mismatches, code that assumed window
existed, a Node process to run and cache, and a new set of things that can be
stale. For a page whose job is to display text, this is
usually contained. For an application with third-party scripts and an
authenticated shell, it is a project, and the scripts are where it hurts.

What has to change is that the decision gets made. An agent asked to build a
page will not ask you whether search engines and language models should be able
to read it, because that is not a coding question — it is a question about who
the page is for. That one is still yours.

Then check that the answer stayed true. A rendering strategy is a thing an agent
can quietly change in a refactor six weeks later, and the only symptom is that
curl gets shorter.

---

## Why certificates still lapse, twelve years after Let's Encrypt

URL: https://harpywatch.com/blog/why-certificates-still-lapse
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: Reliability, TLS

An expired TLS certificate is the most embarrassing outage available. It is
total — every browser refuses, loudly, with an interstitial that says your site
is dangerous. It is entirely predictable, months in advance, to the second. And
it is still happening, constantly, at organisations that automated renewal
years ago.

The interesting question is not "why don't people automate renewal". They did.
The interesting question is why that turned out not to be the same thing as
"certificates don't expire".

The renewal is not the delivery

certbot running on a cron is a program that obtains a certificate and writes
it to disk. That is the whole of its job, and it is very good at it.

What takes a site down is everything downstream of that write:

- The renewal ran, wrote a new certificate, and nothing reloaded. nginx is
still holding the old one in memory. The file on disk is perfect. The socket
serves an expired certificate for as long as that process lives.
- The renewal ran on one host of three. The load balancer serves the fresh
one two times out of three, so the failure is intermittent, which is worse
than total: monitoring that checks once and gets lucky reports green.
- The certificate was renewed where it is terminated, which is not where
anyone was looking. A CDN, an ingress controller and an origin can each hold
their own copy, and only one of them faces the browser.
- The renewal wrote a valid leaf and the chain got shorter. The site
works in every browser the person testing it owns, and fails in the older
client, the Java service, or the payment processor's callback that does not
carry the intermediate in its trust store.
- The domain's DNS-01 challenge broke months ago, renewal has been failing
silently since, and the email about it goes to an alias nobody reads.

Every one of these is a certificate that is, on the machine that generated it,
completely fine. Checking your renewal automation tells you nothing about any
of them.

Watch the socket, not the pipeline

The single most useful correction is to move where you observe from.

A certificate's expiry is a fact about the bytes a client receives on a TLS
handshake to a particular hostname and port, from outside your network, with
no privileged access and no knowledge of how it got there. That measurement is
indifferent to which of the failures above happened, because all of them
produce the same observable: the thing on the wire is not the thing you think
you renewed.

This is why HarpyWatch runs ssl-cert-expiry as a check against the address a
visitor uses, rather than reading a file. The check connects, completes a
handshake, and reads the certificate that was actually presented. If nginx was
never reloaded, the file on disk is irrelevant — the socket tells the truth.

Expiry is the symptom, not the check

Once you are looking at the handshake, expiry is only the most obvious of
several things that will take a site down, and it is not the one that will
surprise you.

cert-chain-trust verifies the chain the server actually sends, in order, up
to a trusted root. A missing intermediate is the classic version of this: it
works in Firefox, which caches intermediates it has seen, and fails in a
freshly installed client, which does not. The bug reproduces only on machines
nobody develops on.

tls-handshake looks at the negotiation itself — protocol versions and cipher
suites. A server quietly still offering TLS 1.0 is a compliance finding waiting
to happen; a server that has just dropped 1.2 in the name of hardening is an
outage for whatever embedded client has not been updated since.

domain-expiry watches the registration underneath all of it, which is worth
saying out loud because it fails in exactly the same way for exactly the same
reason. It is a renewal, on a long clock, whose reminders go to a mailbox that
belonged to somebody who has left. When it lapses, the certificate is
irrelevant — there is no name left to present it for.

Two numbers, both of which matter

For expiry specifically, there are two useful thresholds and most setups only
have one.

The first is the alert you can act on: far enough out that a human can
schedule work. Thirty days is conventional and reasonable, and if your renewal
is automated it should essentially never fire.

The second is the one people skip: the alert that says automation has already
failed. If renewal is meant to happen at sixty days and you are inside
fourteen, the thirty-day warning has not just fired, it has fired and been
ignored or missed, and something is wrong with the process rather than the
certificate. That should be a different, louder signal, because it means the
mechanism you were relying on is not working and nobody noticed.

The gap between those two numbers is the actual subject. A certificate does not
expire because nobody knew the date. It expires because the date was known, the
renewal was automated, the automation reported success, and no one ever checked
what a browser gets when it connects.

---

## Two nulls are not zero

URL: https://harpywatch.com/blog/two-nulls-are-not-zero
Author: The HarpyWatch team
Published: 2026-09-02
Kind: article
Tags: Design, Reliability

There is a category of bug that no test catches, no alert fires for, and no
customer reports — because from the outside it looks like the system working.
The screen is populated. The numbers are round. Nothing is red.

It is the bug where a dashboard renders "I don't know" as a number.

Three different nothings

Take a single row on a monitoring screen: one site, one kind of check, one
count of open incidents. That count can be absent for at least three distinct
reasons, and they are not the same reason.

- Nobody has asked yet. The request is in flight, or the screen was drawn
before the query returned.
- The question cannot be answered here. The endpoint does not exist in this
deployment, or the caller has no permission to ask it.
- The answer is genuinely none. It was asked, it was answered, and the
answer is that there are no open incidents.

Only the third of these is a zero. The other two are the absence of a fact.
And the distance between them is the whole value of a monitoring product: one
means everything is fine, and the other two mean you have learned nothing,
and you should not go back to bed yet.

Why it always collapses the same way

The collapse is almost never a decision. It is a default.

A column is nullable in the database. A field is Option<i64> in the API. It
becomes number | null in the client. And then somewhere near the end, in a
template, someone writes the most reasonable-looking line of code in the file:

{{ openIncidents ?? 0 }}

Every step in that chain preserved the distinction faithfully. The last one
threw it away, in five characters, to avoid rendering an empty cell.

The same pressure applies at every layer. A schema wants a NOT NULL DEFAULT 0 so that queries are simpler. An aggregation wants COALESCE so that a sum
is not poisoned by a missing row. A chart library wants a number so that a line
can be drawn. Each of these is locally sensible. Together they manufacture
confidence that nobody ever measured.

What it costs

The cost is not the wrong pixel. It is that the wrong pixel is reassuring.

A missing value drawn as a zero is not a neutral error; it always fails in the
same direction. Unknown uptime becomes 0% — or, more often, an unknown outage
count becomes zero outages, which reads as perfect health. A certificate whose
expiry could not be fetched shows no warning, which is indistinguishable from a
certificate that is fine. A check that has never run reports no failures, which
is exactly what a passing check reports.

Every one of those is a screen that answers "is my site up?" with a confident
yes on the strength of no evidence whatsoever. If you are going to be wrong,
being wrong in the direction of "go and look" is survivable. Being wrong in the
direction of "everything is fine" is the failure people buy monitoring to
prevent.

The rule we hold ourselves to

Inside HarpyWatch this is written down as three sentences, and they are
load-bearing enough that they sit at the top of the codebase's own
documentation:

Missing data never renders as healthy. Stale never renders as fresh. And a
fixture must never answer a question about a real fleet.

In practice that means a handful of things that are slightly annoying to build
and worth it every time:

A limit of null is unlimited. A usage of null is unmeasured. These are
opposites, and both of them are the absence of a number. A plan with no cap on
monitors and a plan whose usage we failed to read must not look the same.

An unchecked bucket draws hollow, not green. On an uptime timeline, a
period with no result is a gap. It is not filled in, and it is never
interpolated across — the line does not connect the two known points through a
region nobody observed, because the resulting picture is a claim about time
that was never measured.

A result past twice its expected interval is stale, and says so. A check
that should run every minute and last ran forty minutes ago is not reporting
"up". It is reporting "up, forty minutes ago", which during an incident is a
completely different sentence. So it is dimmed, it is marked, and nothing
derived from it is asserted.

A number the screen has not asked for refuses rather than guesses. There is
a counter in our own product's top bar that returns nothing at all on a build
whose API cannot answer it, rather than showing the fixture's zero. An empty
space with a reason beside it is honest. A zero is not.

The awkward part

All of this makes screens uglier. Hollow cells, dimmed rows, em dashes where a
figure would look tidier, and the occasional sentence explaining why a panel is
empty. There is a real design cost, and the pressure to smooth it over is
constant and comes from good instincts — nobody sets out to build a dashboard
full of holes.

But a monitoring tool's only product is a true statement about someone else's
system. A gap in that statement is information. It says: here is a thing we
did not observe, and you should decide whether that matters.

Filling the gap in with a zero does not remove the uncertainty. It just moves
it from the screen, where somebody could act on it, to three o'clock in the
morning, where they cannot.

---

## Thirty-one checks, one grid

URL: https://harpywatch.com/blog/thirty-one-checks-one-grid
Author: The HarpyWatch team
Published: 2026-09-02
Kind: news
Tags: Product, Reliability

Most uptime monitoring answers one question: does the front page return a 200?
That is a real question and it is worth answering. It is also the smallest
possible fraction of the ways a website is broken while returning a 200.

HarpyWatch runs thirty-one distinct kinds of check. Each one is a separate
executable with its own idea of what it is looking at, its own configuration,
and its own way of being wrong. This is the complete list.

Is it there at all

- http-uptime — the classic. A request, a status code, a response time.
- availability-sample — repeated probes over a window, so a flapping
endpoint is distinguishable from a down one. One request cannot tell those
apart, and they need different responses from you.
- tcp-port — a connection, no protocol assumed. For the things that are
not web servers.
- ttfb-budget — time to first byte against a budget you set. Slow is a
kind of down, on a long enough timescale.
- dns-resolution — resolution itself, which is upstream of everything
else here and fails independently of your servers.

Is the connection trustworthy

- ssl-cert-expiry — the certificate actually presented on the wire, not
the one on disk.
- cert-chain-trust — the whole chain, in order, to a trusted root. A
missing intermediate works in the browser you tested and fails in the client
that matters.
- tls-handshake — protocol versions and cipher suites, in both
directions: too old is a compliance finding, too new is an outage for an
embedded client.
- domain-expiry — the registration underneath the certificate, on a much
longer clock, with reminders going to a mailbox somebody has left.
- mixed-content — HTTPS pages loading HTTP subresources, which browsers
block silently and which nothing in your logs will mention.

Does it say what it should

- dom-content — the rendered content, for the case where the page is up
and the content is a database error.
- browser-render — a real browser, for pages that are only assembled once
JavaScript runs.
- json-api — an endpoint's response body, not just its status.
- json-schema — that body against a schema, so a field quietly changing
type is caught where it happens rather than three services downstream.
- feed-freshness — an RSS or Atom feed that has stopped updating, which
is a pipeline failure wearing a 200.
- broken-links — links that no longer resolve.

Will a search engine and a crawler see it

- robots-policy — the robots file, because a Disallow: / shipped by
accident is an outage that takes weeks to show up and months to recover from.
- sitemap-health — the sitemap parses, and points at pages that exist.
- redirect-chain — the full chain of hops, its length, and whether it
terminates. A redirect loop is invisible to a check that follows redirects
and reports the final status.
- open-redirect — a redirect that will send a visitor wherever a query
parameter says. A phishing vector and a ranking problem at once.
- page-weight — total transferred bytes.
- core-web-vitals — the metrics that are actually a ranking input.

Is it configured safely

- security-headers — the standard set, present and sane.
- csp-policy — Content-Security-Policy specifically, which is long enough
and subtle enough to deserve its own check.
- cors-policy — who your API says may call it from a browser. A
wildcard here is a bad afternoon.
- cookie-flags — Secure, HttpOnly, SameSite.
- http-headers — arbitrary header assertions, for the ones specific to
you.
- cache-policy — cache headers, where the two failures are opposites: an
asset that cannot be cached is slow forever, and an HTML document that is
cached serves last week's deploy.
- compression — whether responses are actually compressed.
- third-party-data-flow — which third parties a page contacts. This one
is a privacy and compliance check as much as a technical one: the answer
changes when a marketing tag is added by someone who does not deploy.
- websocket-handshake — the upgrade, for products where the interesting
traffic is not request/response.

Why one grid

Thirty-one checks across a fleet of sites is a large number of facts, and the
temptation is to give each kind its own screen. We do not, for one reason: the
question you have during an incident is never about one check.

It is "what else changed at the same time". A certificate warning next to a
redirect chain that got longer next to a TTFB that doubled is not three
findings — it is one deploy, and the shape is only visible if they are drawn
together. Split across three tabs, they are three separate mild concerns that
nobody correlates until afterwards.

So every asset is a row, every check is a cell, and the whole fleet is one
picture. When something moves, the things that moved with it are adjacent.

A note on the number, because we would rather be exact than round. Writing this
piece turned up our own documentation saying "thirty checks" while the registry
that actually runs them held thirty-one. The registry wins, the prose has been
corrected, and the count on our /llms.txt and in the site's structured data is
now read from the registry itself rather than typed out — so the next check to
land will update it without anybody remembering to.

---