Monitor the site nobody is looking at yet

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.