We build HarpyWatch: thirty-one kinds of check, run against your sites on a schedule, with the results in one grid.
Ask an agent for a login flow and you tend to get a ?next= parameter redirected to whatever it contains. It is the obvious implementation, it is an open redirect, and the remedy was documented years before the model was trained.
A catalogue of small, boring, real failures — a www that resolves nowhere, a redirect that drops to http, a response that is not actually compressed — each one cheap to see from outside.
An AI agent that ran certbot once did the work correctly and made no commitment about the renewal. The setup is in your repository; the recurring obligation it created is in nobody's calendar.
An outage costs what it costs. Being informed of it by the person it happened to costs something separate, it accrues, and it is charged against the next incident rather than this one.
Four agents changing one codebase means four diffs nobody has time to read end to end. The answer is not fewer agents: it is checking the deployed site, which costs the same however many changes arrived.
Generated markup is verbose, imports whole libraries for one function, and inlines assets because that works. Every test still passes. The cost lands on a phone on a slow connection, months later, as a number with no cause attached.
A strict Content-Security-Policy is usually the thing standing between an agent and the feature it was asked to add. Widening it is the path of least resistance, it is never mentioned in the summary, and nothing about the site looks different afterwards.
Adopting monitoring for a small site is five decisions, not a project. Here is what each one actually involves, and why finishing a rough version beats designing a perfect one.
A canonical tag pointing at staging, a noindex that shipped, a test API key in production. Each is invisible on a developer's machine and expensive live, and copying config between environments is the fastest way to make something work.
The instinct is to add monitoring once a site has traffic worth protecting. That gets it backwards: an empty site is the one failure mode nobody reports, because your first hundred visitors leave instead.
One agent edits the backend, another edits the frontend, a field quietly changes type, and every build stays green. The screen renders blank where a number belongs, and only something watching the deployed endpoint will tell you.
Every restructure moves URLs, and every move adds a redirect. Nobody ever removes one. The result is a chain a crawler stops following and a browser spends a second on before it sees a single byte of content.
Ask an agent to add analytics and it adds a tag. Do that four times over six months and your page is executing code from hosts no one on the team chose, on your origin, with your users' data.
Your browser smooths over a great deal of what your site actually sends. Here are the terminal commands that show you what a crawler, a link checker or a monitoring probe gets instead.
Between a visitor typing your name and a request reaching your server sits a system you did not write and cannot review: a registration, a delegation, a zone, and a chain of caches. Here is how each of them fails.
Uptime nobody can see is an internal fact. Published with real history, it answers a question buyers were going to ask anyway — and an always-green page nobody believes is worth less than an honest one with incidents on it.
Given a red signal, an agent optimises for the signal. That is not a flaw in any particular tool — it is what optimisation means, and it changes which signals are worth having.
A health check inside your own stack goes silent at exactly the moment it had something to say. Here are the failure domains an internal check shares with the site, and what an external one sees instead.
A green pipeline reports that a process started. It is compatible with an empty database, a missing environment variable, a stale CDN and every real route returning 500. Only a request from outside settles it.
An AI agent can produce a working-looking site faster than any human can review it. The defects live in the gap between the agent saying it is done and a stranger being able to use it.
Monitoring is usually justified as insurance against downtime. The better argument is commercial: the gap between a customer telling you your site is broken and you telling them is a gap they can feel.
Redirect chains, headers, certificate chains, robots policy and sitemap validity are all observable on a staging hostname, before DNS points anywhere. That is where the checks should run first.
Ask an agent for a website and you will usually get a client-rendered one. The AI crawlers largely do not execute JavaScript, so what they store is an empty div — and one curl command will tell you whether that is your page.
Renewal is automated almost everywhere and certificates still expire in production. The failure has moved: it is no longer the renewal that breaks, it is everything between the renewal and the socket a browser actually connects to.
A monitoring dashboard has three ways of not knowing something, and every one of them has been drawn as a confident zero at least once. Here is why that is the most expensive bug a status screen can have.
HarpyWatch runs thirty-one distinct kinds of check against a site — not thirty-one variations on an HTTP request. Here is the full list, what each one is actually for, and why they share a single screen.