Diagnose before you deploy, not after

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.