---
title: "Monitor the site nobody is looking at yet"
description: "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."
url: https://harpywatch.com/blog/monitoring-before-you-have-users
kind: article
author: "The HarpyWatch team"
published: 2026-09-29T09:00:00+00:00
tags: ["AI Agents", "Monitoring", "Reliability"]
publisher: "HarpyWatch"
---

# 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.