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

Simply put, a false positive is an alarm even though the monitored service did not actually fail from the perspective of the relevant users.

For example, only the network path of a single monitoring location might have been disrupted.

That is why retakes and multiple locations are helpful for more important systems.

What is a false negative? #

Conversely, a monitor can evaluate a service as available even though a relevant problem exists for visitors.

For example:

Homepage returns 200 OK

but:

Checkout does not work

The simple homepage monitor continues to report Up, although a business-critical function is disrupted.

This shows a central limitation of all monitoring: it can only check what it has been configured for.

Monitoring does not replace backups #

Website monitoring and backups solve completely different problems.

Monitoring
→ detects a fault

Backup
→ enables recovery
  of data or system states

A monitor can inform you, for example, that a website is unreachable. However, this does not automatically mean it possesses a usable copy of your website.

Monitoring does not replace security monitoring #

A website can be technically reachable and still have been compromised.

A standard HTTP monitor does not automatically detect:

malware
tampered files
stolen credentials
unauthorized administrators
hidden redirects
data exfiltration

Uptime monitoring is therefore only one component of more comprehensive technical monitoring.

Monitoring does not replace performance analysis #

A website can be 100 percent available during the measured time and still be unbearably slow.

Conversely, a very fast website can have occasional outages.

Therefore, availability and performance should be measured separately.

If your website is accessible but slow, you can find it under Slow website: systematically finding the causes a diagnostic procedure.

Evaluate monitoring data over a longer period of time #

The true value of monitoring does not come solely from individual alerts.

Over a longer period, patterns can become visible.

For example:

Outages always at night?

Problems always during backups?

Timeouts only on a specific page?

Errors only from a specific region?

Response times noticeable at specific times?

Recurring 5xx errors?

Such patterns can be much more helpful in root cause analysis than a single isolated alarm.

Status pages #

For larger services, an additional public or internal status page can also be useful.

For example, it can display:

Website

API

Customer Center

Email Services

Additional Systems

However, a status page should ideally not depend entirely on the exact same infrastructure whose outage it is meant to communicate.

What should good basic monitoring achieve? #

For a standard business website, basic monitoring should at least be able to clearly answer:

Which URL is being checked?

How often is the check performed?

Which status is considered a success?

How long is the timeout for a response?

Is an error confirmed?

When is an alert sent?

When is the website considered UP again?

Who receives the alert?

Only when these parameters are known can the measured values be meaningfully interpreted.

How to document monitoring correctly #

For important websites, a short documentation of the monitoring is worthwhile.

For example:

Monitor:
Website Home page

URL:
https://example.com/

Type:
HTTPS

Interval:
5 minutes

Expectation:
HTTP 200

Alert:
after confirmed error

Recipient:
responsible person

This also makes it possible to trace later what the monitor actually checked.

A typical monitoring workflow #

Define website
        ↓
Select important endpoint
        ↓
Determine testing method
        ↓
Set testing interval
        ↓
Define success criteria
        ↓
Configure alerting
        ↓
Start monitoring
        ↓
Error detected?
        ↓
Control check
        ↓
Alert
        ↓
Reproduce issue
        ↓
Isolate error
        ↓
Fix cause
        ↓
Check recovery
        ↓
Monitoring confirms UP
        ↓
Document incident

Common mistakes in website monitoring #

only use ping

equate 200 OK with a fully functioning website

confuse response time with complete load time

monitor only an irrelevant endpoint

trigger an alarm immediately upon every single timeout

configure too many unimportant monitors

document no timestamps

fail to account for scheduled maintenance

treat monitoring as a backup

treat monitoring as a security solution

equate UP with "everything is working"

equate DOWN with "server is powered off"

Checklist: Setting up website monitoring effectively #

What should be monitored?
        ↓
determine public URL
        ↓
use HTTP or HTTPS
        ↓
define expected status
        ↓
check content if appropriate
        ↓
set check interval
        ↓
choose reasonable timeout
        ↓
enable verification check
        ↓
use multiple locations if applicable
        ↓
define alert recipients
        ↓
perform test alert
        ↓
consider maintenance windows
        ↓
regularly review monitoring data
        ↓
analyze recurring errors

Summary #

Website monitoring automatically checks whether a website or a specific service is accessible and meets the defined success criteria.

For normal websites, an external HTTPS monitor is a sensible starting point. Depending on the use case, additional content checks, further endpoints, or checks from multiple regions may be useful.

However, a monitoring alert does not automatically mean that the entire server has failed. A timeout, DNS issue, HTTP error, certificate problem, or a malfunctioning application can also cause an alert.

Conversely, a green one proves Up-status does not ensure that every function of a website works properly. For example, a simple homepage monitor cannot evaluate a complete ordering process.

Furthermore, monitoring does not replace backups, security monitoring, or performance analysis. These systems answer different technical questions.

Monitoring becomes especially valuable through continuous measurements, precise timestamps, and sensible alerting. In the case of sporadic problems, this data can help identify recurring patterns and specifically evaluate server or application logs for the affected period.

Good website monitoring therefore does not mean setting up as many checks as possible. The key is to monitor the right endpoints with clearly defined criteria and, in the event of a deviation, quickly get the information needed for a real diagnosis.