How I monitor 40 websites for free

Northwind builds and hosts sites for clients, and clients notice downtime before we do. That is an embarrassing way to find out a server has fallen over — I wanted to be the one telling the client, not the other way round.

The obvious answer was a paid monitor like Pingdom, but the honest answer was the maths. For 4 sites a paid tool is free or close to it; for 40 sites the same tier costs around $50/mo, which is $600 a year for something Apps Script does for nothing. The work itself is trivial — an HTTP request and a status code — and the free quota fits 40 checks every ten minutes comfortably. Paying for it felt like paying for a calculator.

So I built the scrappy, free uptime monitor that now watches 40 sites every ten minutes. It does one job well: notice when a site stops responding, and tell me before the client does.

How it works

The monitor is deliberately small. It is a Sites sheet with one row per URL, a Quiet hours sheet for scheduled maintenance windows, and a time-based trigger that checks every site every ten minutes. There is no dashboard, no graphs, no historical charts — just the alert, which is the only part that actually matters at 11pm.

Each cycle runs as a simple chain:

1. A trigger fires every ten minutes and reads the list of URLs.
2. For each site, the script makes an HTTP request and records the status.
3. A single failure is ignored, and the result is stored.
4. On a second consecutive failure, the script emails me an alert.
5. When the site responds again, it emails a short “recovered” note.

The core ping logic is the same as Monitor website uptime and response time, which is where I started before adapting it to handle 40 sites at once.

False positives and alert fatigue

The ping was never the hard part. The hard part was making sure I still read the alerts when they arrived, and two different problems threatened that.

The first was false positives. A single 503 does not mean a site is down — it might mean a slow deploy, a brief load spike, or a network blip between Google and the server. So the script requires two consecutive failures before it alerts. That one rule killed almost all the noise without meaningfully slowing detection, because the second check is only ten minutes later anyway.

The second problem was scheduled maintenance. In the first week, planned work triggered alerts, I learned to ignore them, and then I nearly ignored a real one. So I added the Quiet hours sheet: anyone can add a site and a time window before planned work, the monitor stays silent for that site during that window, and outside the window it alerts as normal. An alert you trust is worth ten you have trained yourself to skim past.

Was it worth it

Plainly, yes:

• 40 sites monitored every ten minutes for £0, against $50/mo for a paid tool.
• I now hear about downtime before the client does, most of the time.
• The two-consecutive-failure logic means real alerts, not noise.

Monitoring is not hard — it is just relentless. Apps Script is good at relentless and bad at nothing else here, which makes it the right tool: the free quota does the boring part, and a Quiet hours sheet keeps the alerts worth reading.