19 JUL 2026

Website monitoring after launch: what to measure every month

Website monitoring after launch: a score wearing down over twelve unwatched months, and the Core Web Vitals thresholds

On delivery day your website was a perfect scorecard: PageSpeed 94, all green, handshakes. Twelve months later it takes five seconds to load, one form no longer sends anything, and nobody noticed — because nobody was watching. Websites don’t break with a bang: they wear out in silence, one plugin update at a time, one 8 MB photo at a time. Website monitoring is the craft of noticing before your customers do. Here’s what to measure every month, with which tools, and when it makes sense to delegate.

Why a fast website stops being fast.

A website is a living system: the CMS and plugins update themselves, the team uploads photos straight off the phone, marketing adds a tracking script “just for one campaign” that stays forever, the shared hosting fills up with neighbours. Each change is small; the sum is not. It’s the same reason a car gets serviced: not because it broke, but because it’s been used.

And a second clock is ticking: Google’s. The metrics change — in 2024 INP replaced FID among the Core Web Vitals — and a site frozen at two-year-old standards slides backwards even if nobody touches a thing. The delivery-day score isn’t a diploma on the wall: it’s a photograph, and photographs age.

The four measures of serious website monitoring.

Four measures, in this order: first “does it exist?”, then “does it work for real people?”, then “does it sell?”, finally “can it be found?”. Monitoring that watches only the speed score is a dashboard with just the fuel light: useful, but it won’t tell you a wheel has come off.

aUptime: does the site respond? Sounds trivial, until you find out it was down on the very night of your campaign. You need an automatic check every few minutes, with an immediate alert.

bCore Web Vitals in the field: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1 — measured on real users (CrUX data aggregated over 28 days), not just in the lab.

cCritical functions: forms, cart, bookings. The real damage isn’t “the site is slow” — it’s “the form hasn’t been sending for three weeks”.

dVisibility: the pages in the index, the errors flagged by Search Console, your positions on the searches that bring you customers.

The four measures of website monitoring: uptime, real-user Core Web Vitals, critical functions and visibility on Google — The four measures, in order: first “does it exist?” (uptime), then “does it work for real users?” (field Core Web Vitals, CrUX over 28 days), then “does it sell?” (forms and cart), finally “can it be found?” (index and rankings). Sources: web.dev and the CrUX documentation (Google).

Lab and real world: why the two numbers don’t match.

Lighthouse — the engine behind PageSpeed Insights — measures the site under controlled conditions: same simulated network, same device. It’s invaluable for diagnosing, but it’s still a lab. Field Core Web Vitals come instead from the Chrome UX Report: real users, real networks, real phones, aggregated over 28 days. The two numbers can diverge — the lab passing and the field failing, or the other way round — and when they diverge, the field is right: that’s where your customers are.

The practical consequence: a one-off check tells you how the site is doing today, in the lab. Only a monthly series tells you whether it’s getting better or worse for the people who actually use it. It’s the difference between a photo and an electrocardiogram.

Core Web Vitals in 2026: what Google actually measures →

The monthly ritual, in twenty minutes.

aRun a full check-up and save the score next to last month’s: what counts is the direction, not the number of the day.

bOpen Search Console: index coverage, new errors, the searches that bring clicks.

cLook at the month’s uptime report: how many minutes of downtime, and at what hours.

dWalk the path that brings you money by hand — form, quote request, cart — from a phone, not from your desk.

eCheck that the latest backup exists and opens: a backup never tested is a hope, not a backup.

Full site check-up: 7 measures in one minute, free →

When to delegate (and what to demand from whoever does it for you).

The twenty-minute ritual works — as long as someone actually does it. Experience says that after the third month the appointment slips, and the site goes back to wearing out unseen. Google’s reliability engineering formalised a principle that holds at small scale too: systems are kept safe by automatic checks and alerts, not by good intentions.

That’s why monitoring is included in our projects with a maintenance plan: our platform keeps an eye on uptime, periodic checks and the real-user Core Web Vitals of the sites we look after, and when a value slips we see it — before you hear about it from customers. The report arrives every month, in human language. If you prefer DIY, the ritual above is yours: what matters is that someone is watching.

Our Monitor live — and try it on a site of yours, free →

Free today, under watch tomorrow: monitoring for clients →

Technical redesign: when the numbers say it’s time →

Sources.

The figures and claims in this article come from here. These are primary sources, not summaries: open them and check for yourself.

web.dev — Core Web Vitals (Google)The official definitions and thresholds of LCP, INP and CLS cited in this article, including the switch from FID to INP in 2024.
Chrome UX Report (CrUX) — documentationThe source of field data: real Chrome users, aggregated over a rolling 28-day window.
Google SRE — Monitoring Distributed SystemsThe Site Reliability Engineering book’s chapter on keeping systems safe: automatic checks and alerts, not good intentions.

Run the full check-up of your website — free →