Website monitoring — who finds out first, you or your customer

Website monitoring answers one question: who finds out about an outage first — you or your customer. Everything else, from choosing a tool to how often it checks, is either an answer to that question or a distraction from it.

The simplest monitor asks the server for a page every few minutes and checks whether the response carries a 200 code, meaning "OK". If it does, it concludes the site works. But a 200 code only says that the server sent something back — not that it sent what it should.

We have proof of this on our own site. We checked what our site returns for an address that does not exist. It sends a page titled "404 — page not found" — with a 200 code. A person sees an error. A monitor that checks only the code sees a working page. Google calls this a soft 404 in its documentation and warns that such error pages can end up in the index.

For us it is a deliberate trade-off, not an oversight. Our pages are sent to the browser as a stream, in chunks, so that content appears sooner — and the Next.js documentation explains that the server then has to confirm "200" before it knows whether the address exists. In exchange, it adds a noindex tag to the error page, so Google will not index it. That is enough for the search engine. It is not enough for a monitor, because a monitor does not read the tag. And that is exactly why asking "does the site respond" is not enough.

What a monitor actually checks

The word "monitoring" covers four different checks. They differ in what they ask the site — and therefore in which failures they are able to see.

Status code. The monitor fetches an address and checks whether the server answered with 200. It catches a server that does not respond at all, and server errors. It does not catch anything the server serves with a 200 — an error page, an empty page, a page that has lost half its content. This check exists in every tool and is usually the first one set up, so it is worth knowing what it cannot see.

Page content. The monitor fetches the page and looks for a specific piece of text on it — the company name in the footer, a heading, a phone number. If the text is missing, it raises an alarm even with a 200 code. It is one extra setting, and it closes the biggest gap in the first check. Choose a text that does not change with every content update, and one that does not appear on the error page.

Full journey. The monitor does what a customer does: opens a form, fills it in, submits it and checks the confirmation — or adds a product to the basket and goes through to payment. It is the only check that sees the site "working" while the business receives no enquiries. It is more expensive, harder to maintain and needs updating every time the form changes, so it makes sense where that one journey is a source of revenue.

Expiry dates. A certificate and a domain do not degrade gradually — they stop working on a specific day you know in advance. A monitor that only checks the current state will notice the problem on the day of the outage. A monitor that checks the date will warn you a week earlier.

For a typical company website, a sensible set is the code and the content on the home page and the contact page, plus the certificate date and the domain date. The full journey makes sense for a shop, and for the form your sales depend on.

Is the site working — who finds out first

The question "is the site working" only makes sense together with a second one: how quickly someone will find out and what they will do. A monitor checking every five minutes will, at worst, notice an outage five minutes after it starts. But that is the shortest segment of the whole story.

A contract guaranteeing 99.9% availability allows 44 minutes of downtime a month — we set out the arithmetic under website maintenance services. Against that background the proportions are clear. Going from five minutes to one saves four minutes. The promise "we respond within an hour" on its own uses more than the whole monthly budget allows. How long an outage lasts is decided not by how often you check, but by what happens after the alert.

That is why the first question when setting up monitoring is not "how often should it check" but "who gets the notification, and can they do anything about it". Frequency matters for a high-traffic shop, where every minute means orders. For a company website, five minutes is enough as long as someone on the other end will respond.

There is one more reason to have your own monitoring, even if an outside company looks after the site with its own. Uptime monitoring tools keep a report: what percentage of the time the site responded in a given month, how many outages there were and how long they lasted. That is your independent measurement of the contract. If the contractor promises 99.9% and your monitor shows two hours of website downtime in a month, you have a number to discuss, not an impression. Without your own measurement, the only source of knowledge about whether the contract was honoured is the report of the party that was supposed to honour it.

Free uptime monitoring — UptimeRobot and others

You do not have to pay to check the status code and the content. One of the best-known tools is UptimeRobot — in the UK its name is searched around 3,400 times a month across two spellings, "uptime robot" and "uptimer robot" — and it is a good reference point for what you get for free and where the paid plan begins.

According to UptimeRobot's pricing, the free plan includes 50 monitors checked every 5 minutes, with email notifications. The cheapest paid plan checks every 60 seconds and costs €9 a month when billed annually. One caveat: in the questions section on the same page, the provider describes the free plan as intended for "basic personal monitoring". Before using it for a company website, read the current terms, because the conditions of free plans change more often than price lists do.

The alternative is monitoring you run yourself — for example Uptime Kuma, open-source software under the MIT licence. It has no limit on monitors or on the interval, but it needs a server someone maintains. And here is a trap that applies to all monitoring, not just self-hosted: the monitor must not run on the same server as the site. If the server goes down, whatever was supposed to tell you about it goes down with it.

For the same reason, monitoring should check the site from outside, from the internet, the way a customer does. A server checking itself can report that everything works while nobody can reach it from outside — because DNS, the certificate or the network along the way has failed.

Who gets the alert

An alert nobody reads is a log entry. Most badly working monitoring set-ups do not fail at detection but at notification: alerts go to an inbox someone stopped reading, or to a person with no access to the server.

Three decisions turn monitoring into something that works:

• Name who gets the alert — and during which hours. If an outside company looks after the site, the alert should go both to them and to someone on your side. Then you know about the outage regardless of whether the contractor gets in touch, and you can check how quickly they responded.
• What that person can do. A notification at three in the morning to a business owner with no server access achieves only one thing: they will know in the morning. The escalation path — who gets the alert, who knows how to fix it, who decides on restoring a backup — should be written down before it is needed.
• Confirmation before the alarm. A single failed check is sometimes a momentary network problem on the monitor's side. Tools let you raise the alarm only after confirmation — a repeat check or a check from another location. Without it, after a few false alarms people stop reacting to the real ones, which is worse than having no monitoring, because it creates the impression that someone is watching.

It is also worth deciding what is a log and what is an alarm. A slower server response time is information to review once a week. A site that does not respond is a reason to wake someone up. Whoever gets both on their phone will switch notifications off within a week.

Website down — the first fifteen minutes

An alert came in or a customer phoned: the website is down. Before anyone starts fixing anything, it is worth spending a few minutes establishing what exactly is not working and since when, because that determines whom to call. The order that saves the most time:

1. Is it down only for you? Open the site on a phone, on mobile data, not on the office network. If it works there, the problem lies with your connection or browser, not the server. A monitor checking from outside settles this immediately — without one, a phone is the quickest substitute.
2. What exactly do you see? No response, a 500 error, a certificate warning, a blank white page, the hosting provider's page instead of yours — each points to a different cause. A certificate warning means the certificate. The registrar's page or an expiry notice means the domain. A white page or a 500 is usually the application: a plugin, the theme, the latest change.
3. What changed recently? An update, a new plugin, a change on the server, a DNS move. Most outages are caused by something done in the last twenty-four hours, and undoing that one change is faster than searching for the cause from scratch.
4. Is it the provider? Hosting companies and DNS providers publish status pages for their services. If the outage is on their side, your work ends with a report and a notice for customers.
5. Is there something to go back to? If the cause is not visible and the site has to come back, the question is: from which backup, and how much data since then will be lost. That is the owner's decision, not the contractor's, and it helps if the owner knows the answer before having to make it; how to set up backups so that this decision is simple is covered under backups.

It is worth keeping these five steps in the same place as your access details. A quarter of an hour spent establishing what happened usually shortens an outage more than a faster monitor does.

500 and 503 errors — what the monitor tells you

Two server error codes are the ones you will see most often in alerts, and they mean different things.

500, according to the HTTP specification, means the server encountered "an unexpected condition" that prevented it from fulfilling the request. In other words: something broke and the server does not know what. On a WordPress site it is most often an error in a plugin or theme, frequently right after an update or a PHP version change.

503 means the server is "currently unable to handle the request due to a temporary overload or scheduled maintenance" — temporarily overloaded or undergoing planned work. This is the code a site should return itself during maintenance, ideally with a Retry-After header saying when to come back.

For the search engine, the difference is smaller than it seems. According to Google, 5xx errors — both of these codes, and 429 — cause Googlebot to slow down crawling temporarily. Indexed addresses stay in the index, but those that return a server error persistently are eventually removed from it. A short outage will not hurt. A site returning 500 for several days because nobody got the alert will.

What each server code means — including 502 and 504, which you will also see in alerts — and whom to call for which, is covered in a separate article on server errors.

Hence the rule for planned work: if the site is going to be unavailable, let it return 503, not an "under construction" page with a 200 code. For Google the latter is new content at that address, and worse than our soft 404 from the start of this article: that one at least carries a noindex tag, while an "under construction" page usually carries nothing.

Failures with a date in the calendar: certificate and domain

Most outages cannot be predicted. Two can — to the day.

The certificate. The maximum validity of website certificates dropped to 200 days in March 2026 and will keep falling — we set out the dates under SSL certificates. With automatic renewal the problem usually does not exist, as long as the automation works. When it stops — because the server, DNS or configuration changed — you will find out on the day browsers start showing visitors a warning. A certificate date monitor turns that into a notification a week in advance.

The domain. An expired domain switches off the site and email at once, and after the redemption period anyone can register it — which we describe under maintenance costs. The most common cause is not a lack of money but a reminder sent to an address nobody reads. A domain date monitor is a second reminder, independent of the registrar.

Both checks are available out of the box in most monitoring tools, and you set them up once.

Server monitoring — what can only be seen from inside

Everything described so far checks the site from outside, the way a customer sees it. Server monitoring looks from inside: at disk space, processor load, memory, errors written to logs and scheduled tasks. On shared hosting, most of this is beyond your reach and the provider is responsible for what happens inside. On your own server or a virtual server, it is your responsibility or the contractor's.

From a site owner's point of view, two things here matter more than the rest, because they are common causes of outages that look sudden from outside:

• Disk space. A log that grows without limit, or backups stored on the same server, can fill a disk within weeks. When space runs out, everything that writes anything stops working — including forms and the database. An alert when usage crosses a set threshold gives you weeks instead of minutes.
• Tasks that silently failed to run. A backup that was not created, a certificate renewal that failed, a notification run that stalled. From outside the site works, and the problem only surfaces when that backup or that certificate is needed. The right set-up raises the alarm on the absence of a success signal, not only on an error.

If a contractor looks after the site, server monitoring is their working tool. For you it is enough to know it exists and to get one sentence from it once a month: did the backups run, and how much space is left.

Performance monitoring is not Core Web Vitals

An uptime monitor also measures server response time, and it is worth watching — a sudden increase is often the first symptom of a problem before the site stops responding. But this is not the data Google looks at.

Google assesses page speed on the basis of Core Web Vitals, measurements from real Chrome users collected as a 28-day average. It is important data, but it is not suitable for alerting: a deterioration appears in it gradually, over the following weeks, not within an hour of the deployment that caused it. Performance monitoring and Core Web Vitals therefore answer two different questions — "has something just broken" and "how does the site perform for users over the last month" — and one does not replace the other.

What this article deliberately leaves out

• Monitoring positions in Google — different tools and a different question; we cover them under SEO and Google indexing.
• Traffic analytics — website analytics tells you who came, not whether the site was working.
• Accessibility in the WCAG sense — accessibility also means meeting standards for people with disabilities; that is a separate topic.
• What to do after an outage — restoring from a backup and agreeing with the contractor who responds and within what time, which is website maintenance services.

The shortest summary: a monitor that asks only for a 200 code will tell you the server is alive — not that the site works. Add a content check, the certificate and domain dates, and for a shop the full purchase journey. And before you choose a tool, write down who gets the alert at three in the morning and what they can do with it, because that segment, not the checking frequency, decides how long an outage lasts.