Website Monitoring: Monitor Availability and Outages

A website can go down at any time—even if it was working without any problems just a few minutes prior. Server issues, faulty updates, DNS disruptions, expired certificates, or problems with an application can cause visitors to suddenly no longer be able to reach a website.

If you only visit your own website occasionally, you might not notice such issues until hours later or when alerted by customers.

Website monitoring automates this check. An external monitoring service regularly calls a website and checks whether it is accessible and how the monitored endpoint responds.

In this article, we explain how website monitoring works, what testing methods are available, how to distinguish false positives from real outages, and what limitations a simple uptime check has.

Briefly explained: Website monitoring checks your website automatically at regular intervals. If a defined error is detected, the monitoring can trigger an alert so that you notice a disruption without having to constantly check the website yourself.

What is website monitoring? #

Website monitoring involves regularly checking a website or a specific service using an external system.

For example, a simple process looks like this:

Monitoring System
        ↓
calls website
        ↓
server responds
        ↓
response is evaluated
        ↓
everything is okay?
   ↙              ↘
  yes             no
  ↓                ↓
next           re-check /
check          alerting

These tests run automatically and can be carried out around the clock.

Why is external monitoring useful? #

A website cannot reliably determine on its own that it is no longer reachable from the outside.

For example, if the entire server, the network, or DNS resolution fails, a monitoring system running within the same infrastructure can also be affected.

External monitoring, on the other hand, views the website from the perspective of a system outside the monitored infrastructure.

Practical Tip: To monitor public accessibility, at least one check should be performed from outside the actual hosting infrastructure.

What can website monitoring monitor? #

The term website monitoring encompasses different types of checks.

Depending on the monitoring system, examples of what can be monitored include:

HTTP and HTTPS reachability

HTTP status code

Response time

Specific page content

SSL/TLS certificate

DNS resolution

TCP port

Ping

Individual API endpoints

More complex user workflows

Not every monitor needs to perform all of these tasks. Which checks make sense depends on what you actually want to monitor.

The classic HTTP or HTTPS monitor #

For a normal website, an HTTP or HTTPS monitor is usually the most important check.

For example, the monitoring calls the following URL:

https://example.com

and evaluates the answer.

A successful request can, for example, be answered with the following HTTP status:

200 OK

If the website instead responds with a server error, the monitoring can evaluate the check as failed.

We explain the most important HTTP responses at HTTP status codes explained: 200, 301, 404, 403, and 500.

A successful HTTP status does not automatically mean that everything is working #

A website can be 200 OK respond and still have a functional problem.

For example, the home page could be delivered, while:

a contact form does not work

the shopping cart has an error

a database function fails

a login does not work

images or JavaScript are missing

an external service does not respond

A simple HTTP monitor therefore initially only confirms that the monitored HTTP endpoint responds according to the defined criteria.

Content check instead of just status code #

Advanced monitoring can additionally check whether a specific string appears in the returned content.

Assuming the following heading should always be present on a page:

Welcome to Example

The monitor could not only on 200 OK but also check whether this text is actually included in the response.

This allows the detection of certain errors where the web server responds with technical success, but does not deliver the expected content.

What is a keyword or content monitor? #

During a content inspection, a search is conducted for a defined text or pattern.

Simplified:

URL reachable?
      ↓
200 OK?
      ↓
expected text present?
      ↓
yes → test successful

no → possible disruption

The selected character string should be as stable as possible.

For example, a constantly changing price, a date, or a dynamic username would often be unsuitable.

Redirect monitoring #

Many websites automatically redirect certain URL variants.

For example:

http://example.com/

        ↓ 301

https://example.com/

Depending on the configuration, a monitoring system can automatically follow redirects.

It is still useful to know which URL you are actually monitoring and what response is expected.

Otherwise, an accidental forwarding loop or incorrect forwarding destination can lead to a disruption.

You can find more about permanent redirects at Set up a 301 redirect: Permanently redirect URLs.

Which URL should be monitored? #

For a simple corporate website, the homepage is an obvious starting point.

Example:

https://example.com

However, for more important applications, the home page alone may not be sufficient.

Additionally, central endpoints can be monitored, for example:

Home page

Important landing page

Shop

Login

API endpoint

Status or health endpoint

However, you should not indiscriminately monitor every single subpage. The key is to focus on those endpoints whose failure indicates a significant disruption.

Website reachable, but WordPress is broken #

A web server can theoretically be reachable while WordPress itself causes an error.

For example, a request with:

500 Internal Server Error

or:

503 Service Unavailable

be answered.

An HTTP monitor can detect such an error even though the network and web server are basically still reachable.

Why a single ping is not enough #

A ping test does not check if your website is working correctly.

It uses ICMP and answers a different question than an HTTP or HTTPS call.

Simplified:

Ping
→ does a host respond to ICMP?

HTTP monitor
→ does the web service
  respond to an HTTP request?

Content monitor
→ does the page also
  deliver the expected content?

A server can respond to a ping while the website is down.

Conversely, a website can be reachable even though ICMP packets are blocked or not answered.

Important: Do not use ping as sole proof that a website is working.

What does the test interval mean? #

A monitoring system checks a website at specific intervals.

For example:

08:00 Test successful

08:05 Test successful

08:10 Test failed

08:15 Test failed

08:20 Test successful

With a check interval of five minutes, in this example you do not know to the exact second when the outage started between 08:05 and 08:10 or ended between 08:15 and 08:20.

The interval thus influences the temporal resolution of your measurement.

Shorter intervals detect disruptions faster #

By checking every minute, a failure can usually be detected faster than with a check every 15 minutes.

However, a shorter interval also means more monitoring requests.

Which interval is appropriate depends on the importance of the monitored service.

For a mission-critical online store, faster detection may be more important than for a small information site.

Do not raise an alarm immediately for every single error #

A single failed request does not necessarily mean the website is actually down.

Possible short-term causes can be, for example:

brief network interruption
temporary packet loss
short timeout
issue at a monitoring location
temporary overload
brief maintenance phase

Professional monitoring systems can therefore confirm a failed check before an outage is reported.

Why control audits are important #

Assuming a monitoring location cannot reach your website once.

Instead of triggering an alarm immediately, the system can perform a re-evaluation or use a second location.

Test failed
        ↓
Control test
        ↓
still error?
   ↙             ↘
 no             yes
  ↓                ↓
no            Fault
alarm         likely

This reduces unnecessary false alarms.

Multi-location monitoring #

A monitoring service can perform checks from different geographical regions.

This helps to distinguish between a global outage and a regional network issue.

For example:

Zürich      → Error
Frankfurt   → OK
Amsterdam   → OK

This indicates a different situation than:

Zurich      → Error
Frankfurt   → Error
Amsterdam   → Error

Multiple locations therefore provide additional context during fault diagnosis.

What is a timeout? #

A monitoring system does not wait indefinitely for a response.

If a sufficient response is not received within a specified time, the test can be considered a timeout.

However, a timeout does not automatically mean:

Server completely offline

It means first of all:

expected response was not received within the specified time

The cause must then be diagnosed.

Response time is not the same as loading time #

Many monitoring systems display a response time.

This number must not automatically be equated with the complete loading time of a website.

A simple HTTP check might not load the same resources and run the same browser processes as a real visitor.

Therefore, you should use other measurement methods to analyze the actual website performance.

We explain how to meaningfully investigate loading times at Measure website loading time and evaluate it correctly.

Website monitoring and PageSpeed measure different things #

Both tools are occasionally confused with each other.

Website Monitoring	Performance analysis
regularly checks availability and defined conditions	examines the charging and usage experience
runs continuously	is evaluated on a spot-check basis or based on collected user data
can alert about failures	shows performance issues and optimization potential
answered „Is the service reachable?“	answers „How performant is the page?“

For a technical analysis with Google PageSpeed Insights, you can find our guide at How to use Google PageSpeed Insights correctly.

What is uptime? #

Uptime describes the proportion of a considered time period in which a service was measured as available.

For example:

99.9 % Availability

does not mean that a website must never go down.

Even with very high percentage values, a specific possible or measured downtime results mathematically.

How to properly interpret these values is covered in detail under Uptime and Availability: What 99.9 % Really Means.

Monitoring defines for itself what „available“ means #

An important special feature: An uptime value depends on the measurement method used.

For example, a monitor could specify:

HTTP 200
= available

Timeout
= unavailable

HTTP 500
= unavailable

Another monitor could accept redirects or perform additional content checks.

Therefore, uptime values of different systems are not necessarily directly comparable.

A monitoring result is a measurement, not an absolute truth. #

Every measurement takes place from a specific location, at a specific time, and with specific rules.

This means:

Monitoring location

Network path

Check interval

Timeout

Expected status

Confirmation checks

influence the result.

For a reliable diagnosis in the event of a malfunction, you should therefore not only look at the red monitoring alarm, but subsequently check the cause from a technical perspective.

What can trigger a monitoring alert? #

An alarm can have numerous causes.

For example:

Web server unreachable

Application responds with error

PHP error

Database problem

DNS issue

Network problem

Firewall rule

Timeout

Maintenance work

Faulty redirect

SSL/TLS issue

External service disrupted

The alarm is therefore the beginning of the diagnosis—not automatically the diagnosis itself.

What should you do first after a failure alarm? #

First, check if you can reproduce the issue yourself.

Open the monitored URL and check what is actually happening.

If possible, also check using another internet connection or a different network.

After that, you should narrow down the type of error.

Monitoring reports error
        ↓
Access website yourself
        ↓
Is error reproducible?
        ↓
Check HTTP status
        ↓
Check DNS resolution
        ↓
Check SSL/HTTPS
        ↓
Only one page or
entire website affected?
        ↓
Investigate hosting / application /
network further

Document browser error message #

If you see a fault yourself, document the exact error message.

A screenshot can be helpful.

Also note:

Time

affected URL

HTTP status, if known

Duration of the outage

affected features

network used

reproducible or sporadic?

This information greatly facilitates subsequent technical analysis.

Check HTTP status during an outage #

An HTTP status can provide an important first clue.

Examples:

403 Forbidden
→ Access denied

404 Not Found
→ requested URL not found

500 Internal Server Error
→ server-side error

502 Bad Gateway
→ problem between participating services

503 Service Unavailable
→ service currently unavailable

504 Gateway Timeout
→ upstream response
  not received in time

However, a status code alone does not always name the specific cause.

Detect DNS problems #

If a domain name cannot be resolved correctly, the website cannot be reached via its domain name even if the web server is working.

A monitoring alarm can therefore also be caused by DNS issues.

Typical questions during diagnosis are:

Is the domain resolving?

What IP address is being returned?

Are the authoritative name servers reachable?

Have DNS records been changed recently?

Is only one resolver or one region affected?

However, DNS should not automatically be assumed to be the cause of every website outage.

Detect SSL/TLS problems #

On an HTTPS website, a certificate or TLS connection issue can cause a monitor to report the check as failed.

Possible causes can be:

Certificate expired

Certificate not yet valid

Hostname does not match

Certificate chain invalid

TLS connection failed

How we systematically check HTTPS and certificates is covered under Check SSL Certificate and HTTPS: Identify Common Errors.

Website inaccessible only for individual visitors #

Not every reported unreachability is a global website outage.

If only a single visitor is affected, there may be local causes, for example:

Internet connection

local DNS resolver

browser

VPN

firewall

corporate network

routing between networks

External monitoring from multiple locations helps determine whether the website is down generally or only via specific network paths.

Website only sporadically slow or unavailable #

Intermittent issues are among the hardest bugs to fix because the website is often working again by the time manual testing is performed.

Possible causes can include, for example:

short-term load peaks
resource bottlenecks
slow database queries
external API calls
cron or background processes
backup processes
network issues
sporadic application errors

The actual cause cannot be determined from the monitoring alarm alone.

We explain a systematic performance and error diagnosis at Slow website: systematically finding the causes.

Why timestamps are so important #

With sporadic faults, the exact timing is often crucial.

If monitoring reports, for example:

DOWN: 14:37:22

UP:   14:41:08

server, application, or other technical logs can be specifically examined for this time period.

Without an exact time specification, searching for the cause is significantly more difficult.

Practical Tip: In the event of recurring disruptions, always keep the exact time of the monitoring alarm. „The website was slow sometime yesterday“ is much less helpful for a technical diagnosis than a specific time window.

What does DOWN mean? #

A monitoring service often refers to a check as DOWN, if the defined success criteria are not met.

That does not necessarily mean that the entire server was shut down.

Depending on the monitor, for example, it can already:

HTTP 500

Timeout

DNS error

SSL error

missing expected content

as DOWN to be counted.

What does UP mean? #

Up This means accordingly that the current examination meets the defined success criteria.

This also applies here:

UP ≠ guaranteed that every function of the website works

For example, a simple monitor can confirm that the homepage 200 OK delivers. Whether the complete checkout of an online shop works has not been tested with that yet.

Online shop monitoring #

In an online shop, functions other than the homepage can also be mission-critical.

For example:

Shop page

Product page

Cart

Checkout

Payment gateway

Ordering process

However, a simple uptime monitor cannot automatically determine whether the entire purchasing process is working.

This would require more advanced synthetic transaction checks or functional tests.

Do not blindly monitor the checkout with normal requests #

Dynamic processes such as shopping carts, checkouts, logins, or forms should not be tested thoughtlessly with simple monitoring calls.

Such pages can use sessions, cookies, CSRF protection, dynamic tokens, or other application logic.

For functional transaction checks, the test must therefore be specifically designed for the respective application.

WordPress monitoring #

For a WordPress website, the public homepage is a useful basic check.

Depending on the importance of the website, additional public pages can be monitored.

On the other hand, you should not simply burden the administration area with automated login attempts.

If the public website is working, but the WordPress backend is slow or inaccessible, it may be a different issue than a complete website outage.

View frontend and backend separately #

For example, a WordPress website can show the following situation:

Frontend
→ works

/wp-admin/
→ very slow

or vice versa:

Web server
→ reachable

WordPress
→ Error 500

Therefore, a monitoring result should always be interpreted in the context of the actually monitored endpoint.

Caching can affect monitoring results #

A cached homepage can still be delivered very quickly, even though there is a problem in a dynamic area of the website.

Conversely, an uncached endpoint may show different response times than the public home page.

This does not mean that caching makes monitoring „wrong.“ The monitor simply measures the endpoint you gave it.

Therefore, the selection of representative tests is crucial.

CDN and Monitoring #

If a website is delivered via a content delivery network or a reverse proxy, an external monitor may initially see this upstream infrastructure.

This can lead to situations where:

CDN accessible
↓
Origin server has problem
↓
Cached content partially still accessible

or:

Origin works
        ↓
CDN / Proxy has outage
        ↓
Visitor still cannot reach website normally

Therefore, during diagnosis, you should consider what infrastructure lies between the visitor and the actual web server.

Monitoring and maintenance work #

Scheduled maintenance work can intentionally lead to temporary unavailability.

Good monitoring systems therefore allow maintenance windows or the temporary pausing of alarms.

This avoids unnecessary notifications during a known scheduled maintenance.

You should still interpret the measurement data correctly: A planned outage remains technically a period of limited or missing availability, even if no alarm is necessary for it.

Which notifications are useful? #

Depending on the provider, a monitoring system can support different alert channels.

For example:

Email

Push notification

SMS

Messenger

Webhook

Incident system

What is crucial is not so much the number of channels, but rather whether a relevant message is actually noticed by a responsible person.

Too many alarms are counterproductive #

When a monitoring system constantly sends irrelevant warnings, alarm fatigue occurs.

Important messages might then be overlooked.

Therefore, configure:

meaningful check intervals
realistic timeouts
confirmation checks
relevant endpoints
appropriate alarm recipients
maintenance windows

with a view to the actual intended use.

What is a false positive? #

Ein False Positive ist vereinfacht ein Alarm, obwohl der überwachte Dienst aus Sicht der relevanten Nutzer nicht tatsächlich ausgefallen war.

Beispielsweise könnte nur der Netzwerkweg eines einzelnen Monitoring-Standorts gestört gewesen sein.

Deshalb sind Wiederholungsprüfungen und mehrere Standorte bei wichtigeren Systemen hilfreich.

Was ist ein False Negative? #

Umgekehrt kann ein Monitor einen Dienst als verfügbar bewerten, obwohl für Besucher ein relevantes Problem besteht.

For example:

Startseite liefert 200 OK

aber:

Checkout funktioniert nicht

Der einfache Startseitenmonitor meldet weiterhin Up, obwohl eine geschäftskritische Funktion gestört ist.

Das zeigt eine zentrale Grenze jedes Monitorings: Es kann nur prüfen, wofür es konfiguriert wurde.

Monitoring ersetzt keine Backups #

Website-Monitoring und Backups lösen völlig unterschiedliche Probleme.

Monitoring
→ erkennt eine Störung

Backup
→ ermöglicht Wiederherstellung
  von Daten oder Systemzuständen

Ein Monitor kann dich beispielsweise darüber informieren, dass eine Website nicht erreichbar ist. Er besitzt dadurch aber nicht automatisch eine verwendbare Kopie deiner Website.

Monitoring ersetzt keine Sicherheitsüberwachung #

Eine Website kann technisch erreichbar sein und trotzdem kompromittiert worden sein.

Ein normaler HTTP-Monitor erkennt nicht automatisch:

Schadcode

manipulierte Dateien

gestohlene Zugangsdaten

unerlaubte Administratoren

versteckte Weiterleitungen

Datenabfluss

Uptime-Monitoring ist deshalb nur ein Bestandteil einer umfassenderen technischen Überwachung.

Monitoring ersetzt keine Performance-Analyse #

Eine Website kann 100 Prozent der gemessenen Zeit erreichbar und trotzdem unerträglich langsam sein.

Umgekehrt kann eine sehr schnelle Website gelegentliche Ausfälle besitzen.

Deshalb sollten Verfügbarkeit und Performance getrennt gemessen werden.

Wenn deine Website zwar erreichbar, aber langsam ist, findest du unter Slow website: systematically finding the causes einen Diagnoseablauf.

Monitoring-Daten über längere Zeit auswerten #

Der eigentliche Wert eines Monitorings entsteht nicht nur durch einzelne Alarme.

Über längere Zeit können Muster sichtbar werden.

For example:

Ausfälle immer nachts?

Probleme immer während Backups?

Timeouts nur bei bestimmter Seite?

Fehler nur aus bestimmter Region?

Antwortzeiten zu bestimmten
Zeiten auffällig?

wiederkehrende 5xx-Fehler?

Solche Muster können bei der Ursachenanalyse wesentlich hilfreicher sein als ein einzelner isolierter Alarm.

Statusseiten #

Bei größeren Diensten kann zusätzlich eine öffentliche oder interne Statusseite sinnvoll sein.

Sie kann beispielsweise anzeigen:

Website

API

Kundencenter

E-Mail-Dienste

weitere Systeme

Eine Statusseite sollte jedoch möglichst nicht vollständig von genau derselben Infrastruktur abhängen, deren Ausfall sie kommunizieren soll.

Was sollte ein gutes Basis-Monitoring leisten? #

Für eine normale geschäftliche Website sollte ein Basis-Monitoring mindestens klar beantworten können:

Welche URL wird geprüft?

Wie häufig wird geprüft?

Welcher Zustand gilt als Erfolg?

Wie lange wird auf Antwort gewartet?

Wird ein Fehler bestätigt?

Wann wird alarmiert?

Wann gilt die Website wieder als UP?

Wer erhält den Alarm?

Nur wenn diese Parameter bekannt sind, lassen sich die gemessenen Werte sinnvoll interpretieren.

Monitoring richtig dokumentieren #

Bei wichtigen Websites lohnt sich eine kurze Dokumentation der Überwachung.

For example:

Monitor:
Website Startseite

URL:
https://example.com/

Typ:
HTTPS

Intervall:
5 Minuten

Erwartung:
HTTP 200

Alarm:
nach bestätigtem Fehler

Empfänger:
zuständige Person

Dadurch ist auch später nachvollziehbar, was der Monitor tatsächlich geprüft hat.

Ein typischer Monitoring-Ablauf #

Website definieren
        ↓
wichtigen Endpunkt wählen
        ↓
Prüfmethode bestimmen
        ↓
Prüfintervall festlegen
        ↓
Erfolgskriterien definieren
        ↓
Alarmierung konfigurieren
        ↓
Monitoring starten
        ↓
Fehler erkannt?
        ↓
Kontrollprüfung
        ↓
Alarm
        ↓
Störung reproduzieren
        ↓
Fehler eingrenzen
        ↓
Ursache beheben
        ↓
Wiederherstellung prüfen
        ↓
Monitoring bestätigt UP
        ↓
Vorfall dokumentieren

Häufige Fehler beim Website-Monitoring #

nur Ping verwenden

200 OK mit vollständig
funktionierender Website gleichsetzen

Antwortzeit mit kompletter
Ladezeit verwechseln

nur einen irrelevanten
Endpunkt überwachen

bei jedem einzelnen Timeout
sofort Alarm auslösen

zu viele unwichtige
Monitore konfigurieren

keine Zeitstempel dokumentieren

geplante Wartungen
nicht berücksichtigen

Monitoring als Backup betrachten

Monitoring als Sicherheitslösung betrachten

UP mit "alles funktioniert"
gleichsetzen

DOWN mit "Server ausgeschaltet"
gleichsetzen

Checkliste: Website-Monitoring sinnvoll einrichten #

Was soll überwacht werden?
        ↓
öffentliche URL bestimmen
        ↓
HTTP oder HTTPS verwenden
        ↓
erwarteten Status definieren
        ↓
falls sinnvoll Inhalt prüfen
        ↓
Prüfintervall festlegen
        ↓
Timeout sinnvoll wählen
        ↓
Kontrollprüfung aktivieren
        ↓
ggf. mehrere Standorte nutzen
        ↓
Alarmempfänger festlegen
        ↓
Testalarm durchführen
        ↓
Wartungsfenster berücksichtigen
        ↓
Monitoring-Daten regelmäßig prüfen
        ↓
wiederkehrende Fehler analysieren

Summary #

Website-Monitoring überprüft automatisch, ob eine Website oder ein bestimmter Dienst erreichbar ist und die definierten Erfolgskriterien erfüllt.

Für normale Websites ist ein externer HTTPS-Monitor ein sinnvoller Ausgangspunkt. Je nach Anwendungsfall können zusätzliche Inhaltsprüfungen, weitere Endpunkte oder Prüfungen aus mehreren Regionen sinnvoll sein.

Ein Monitoring-Alarm bedeutet jedoch nicht automatisch, dass der komplette Server ausgefallen ist. Ein Timeout, DNS-Problem, HTTP-Fehler, Zertifikatsproblem oder eine gestörte Anwendung kann ebenfalls einen Alarm verursachen.

Umgekehrt beweist ein grüner Up-Status nicht, dass jede Funktion einer Website einwandfrei arbeitet. Ein einfacher Startseitenmonitor kann beispielsweise keinen vollständigen Bestellprozess beurteilen.

Monitoring ersetzt außerdem weder Backups noch Sicherheitsüberwachung oder Performance-Analyse. Diese Systeme beantworten unterschiedliche technische Fragen.

Besonders wertvoll wird Monitoring durch kontinuierliche Messungen, genaue Zeitstempel und eine sinnvolle Alarmierung. Bei sporadischen Problemen können diese Daten helfen, wiederkehrende Muster zu erkennen und Server- oder Anwendungslogs gezielt für den betroffenen Zeitraum auszuwerten.

Gutes Website-Monitoring bedeutet deshalb nicht, möglichst viele Checks einzurichten. Entscheidend ist, die richtigen Endpunkte mit klar definierten Kriterien zu überwachen und bei einer Abweichung schnell die Informationen zu erhalten, die für eine echte Diagnose benötigt werden.