{"id":22919,"date":"2026-08-30T09:38:48","date_gmt":"2026-08-30T07:38:48","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22919"},"modified":"2026-08-30T09:38:49","modified_gmt":"2026-08-30T07:38:49","password":"","slug":"website-monitoring-availability","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/en\/hilfe\/seo-monitoring\/website-monitoring-erreichbarkeit\/","title":{"rendered":"Website Monitoring: Monitor Availability and Outages"},"content":{"rendered":"

A website can go down at any time\u2014even 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.<\/p>\n\n\n\n

If you only visit your own website occasionally, you might not notice such issues until hours later or when alerted by customers.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\n

Briefly explained:<\/strong> 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.<\/p>\n<\/blockquote>\n\n\n\n

What is website monitoring?<\/h2>\n\n\n\n

Website monitoring involves regularly checking a website or a specific service using an external system.<\/p>\n\n\n\n

For example, a simple process looks like this:<\/p>\n\n\n\n

Monitoring System\n        \u2193\ncalls website\n        \u2193\nserver responds\n        \u2193\nresponse is evaluated\n        \u2193\neverything is okay?\n   \u2199              \u2198\n  yes             no\n  \u2193                \u2193\nnext           re-check \/\ncheck          alerting<\/code><\/pre>\n\n\n\n
These tests run automatically and can be carried out around the clock.<\/p>\n\n\n\n
Why is external monitoring useful?<\/h2>\n\n\n\n
A website cannot reliably determine on its own that it is no longer reachable from the outside.<\/p>\n\n\n\n
For example, if the entire server, the network, or DNS resolution fails, a monitoring system running within the same infrastructure can also be affected.<\/p>\n\n\n\n
External monitoring, on the other hand, views the website from the perspective of a system outside the monitored infrastructure.<\/p>\n\n\n\n
\n
Practical Tip:<\/strong> To monitor public accessibility, at least one check should be performed from outside the actual hosting infrastructure.<\/p>\n<\/blockquote>\n\n\n\n
What can website monitoring monitor?<\/h2>\n\n\n\n
The term website monitoring encompasses different types of checks.<\/p>\n\n\n\n
Depending on the monitoring system, examples of what can be monitored include:<\/p>\n\n\n\n
HTTP and HTTPS reachability\n\nHTTP status code\n\nResponse time\n\nSpecific page content\n\nSSL\/TLS certificate\n\nDNS resolution\n\nTCP port\n\nPing\n\nIndividual API endpoints\n\nMore complex user workflows<\/code><\/pre>\n\n\n\n
Not every monitor needs to perform all of these tasks. Which checks make sense depends on what you actually want to monitor.<\/p>\n\n\n\n
The classic HTTP or HTTPS monitor<\/h2>\n\n\n\n
For a normal website, an HTTP or HTTPS monitor is usually the most important check.<\/p>\n\n\n\n
For example, the monitoring calls the following URL:<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
and evaluates the answer.<\/p>\n\n\n\n
A successful request can, for example, be answered with the following HTTP status:<\/p>\n\n\n\n
200 OK<\/code><\/p>\n\n\n\n
If the website instead responds with a server error, the monitoring can evaluate the check as failed.<\/p>\n\n\n\n
We explain the most important HTTP responses at HTTP status codes explained: 200, 301, 404, 403, and 500<\/a>.<\/p>\n\n\n\n
A successful HTTP status does not automatically mean that everything is working<\/h2>\n\n\n\n
A website can be 200 OK<\/code> respond and still have a functional problem.<\/p>\n\n\n\n
For example, the home page could be delivered, while:<\/p>\n\n\n\n
a contact form does not work\n\nthe shopping cart has an error\n\na database function fails\n\na login does not work\n\nimages or JavaScript are missing\n\nan external service does not respond<\/code><\/pre>\n\n\n\n
A simple HTTP monitor therefore initially only confirms that the monitored HTTP endpoint responds according to the defined criteria.<\/p>\n\n\n\n
Content check instead of just status code<\/h2>\n\n\n\n
Advanced monitoring can additionally check whether a specific string appears in the returned content.<\/p>\n\n\n\n
Assuming the following heading should always be present on a page:<\/p>\n\n\n\n
Welcome to Example<\/code><\/p>\n\n\n\n
The monitor could not only on 200 OK<\/code> but also check whether this text is actually included in the response.<\/p>\n\n\n\n
This allows the detection of certain errors where the web server responds with technical success, but does not deliver the expected content.<\/p>\n\n\n\n
What is a keyword or content monitor?<\/h2>\n\n\n\n
During a content inspection, a search is conducted for a defined text or pattern.<\/p>\n\n\n\n
Simplified:<\/p>\n\n\n\n
URL reachable?\n      \u2193\n200 OK?\n      \u2193\nexpected text present?\n      \u2193\nyes \u2192 test successful\n\nno \u2192 possible disruption<\/code><\/pre>\n\n\n\n
The selected character string should be as stable as possible.<\/p>\n\n\n\n
For example, a constantly changing price, a date, or a dynamic username would often be unsuitable.<\/p>\n\n\n\n
Redirect monitoring<\/h2>\n\n\n\n
Many websites automatically redirect certain URL variants.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
http:\/\/example.com\/\n\n        \u2193 301\n\nhttps:\/\/example.com\/<\/code><\/pre>\n\n\n\n
Depending on the configuration, a monitoring system can automatically follow redirects.<\/p>\n\n\n\n
It is still useful to know which URL you are actually monitoring and what response is expected.<\/p>\n\n\n\n
Otherwise, an accidental forwarding loop or incorrect forwarding destination can lead to a disruption.<\/p>\n\n\n\n
You can find more about permanent redirects at Set up a 301 redirect: Permanently redirect URLs<\/a>.<\/p>\n\n\n\n
Which URL should be monitored?<\/h2>\n\n\n\n
For a simple corporate website, the homepage is an obvious starting point.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
However, for more important applications, the home page alone may not be sufficient.<\/p>\n\n\n\n
Additionally, central endpoints can be monitored, for example:<\/p>\n\n\n\n
Home page\n\nImportant landing page\n\nShop\n\nLogin\n\nAPI endpoint\n\nStatus or health endpoint<\/code><\/pre>\n\n\n\n
However, you should not indiscriminately monitor every single subpage. The key is to focus on those endpoints whose failure indicates a significant disruption.<\/p>\n\n\n\n
Website reachable, but WordPress is broken<\/h2>\n\n\n\n
A web server can theoretically be reachable while WordPress itself causes an error.<\/p>\n\n\n\n
For example, a request with:<\/p>\n\n\n\n
500 Internal Server Error<\/code><\/p>\n\n\n\n
or:<\/p>\n\n\n\n
503 Service Unavailable<\/code><\/p>\n\n\n\n
be answered.<\/p>\n\n\n\n
An HTTP monitor can detect such an error even though the network and web server are basically still reachable.<\/p>\n\n\n\n
Why a single ping is not enough<\/h2>\n\n\n\n
A ping test does not check if your website is working correctly.<\/p>\n\n\n\n
It uses ICMP and answers a different question than an HTTP or HTTPS call.<\/p>\n\n\n\n
Simplified:<\/p>\n\n\n\n
Ping\n\u2192 does a host respond to ICMP?\n\nHTTP monitor\n\u2192 does the web service\n  respond to an HTTP request?\n\nContent monitor\n\u2192 does the page also\n  deliver the expected content?<\/code><\/pre>\n\n\n\n
A server can respond to a ping while the website is down.<\/p>\n\n\n\n
Conversely, a website can be reachable even though ICMP packets are blocked or not answered.<\/p>\n\n\n\n
\n
Important:<\/strong> Do not use ping as sole proof that a website is working.<\/p>\n<\/blockquote>\n\n\n\n
What does the test interval mean?<\/h2>\n\n\n\n
A monitoring system checks a website at specific intervals.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
08:00 Test successful\n\n08:05 Test successful\n\n08:10 Test failed\n\n08:15 Test failed\n\n08:20 Test successful<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
The interval thus influences the temporal resolution of your measurement.<\/p>\n\n\n\n
Shorter intervals detect disruptions faster<\/h2>\n\n\n\n
By checking every minute, a failure can usually be detected faster than with a check every 15 minutes.<\/p>\n\n\n\n
However, a shorter interval also means more monitoring requests.<\/p>\n\n\n\n
Which interval is appropriate depends on the importance of the monitored service.<\/p>\n\n\n\n
For a mission-critical online store, faster detection may be more important than for a small information site.<\/p>\n\n\n\n
Do not raise an alarm immediately for every single error<\/h2>\n\n\n\n
A single failed request does not necessarily mean the website is actually down.<\/p>\n\n\n\n
Possible short-term causes can be, for example:<\/p>\n\n\n\n
brief network interruption\ntemporary packet loss\nshort timeout\nissue at a monitoring location\ntemporary overload\nbrief maintenance phase<\/code><\/pre>\n\n\n\n
Professional monitoring systems can therefore confirm a failed check before an outage is reported.<\/p>\n\n\n\n
Why control audits are important<\/h2>\n\n\n\n
Assuming a monitoring location cannot reach your website once.<\/p>\n\n\n\n
Instead of triggering an alarm immediately, the system can perform a re-evaluation or use a second location.<\/p>\n\n\n\n
Test failed\n        \u2193\nControl test\n        \u2193\nstill error?\n   \u2199             \u2198\n no             yes\n  \u2193                \u2193\nno            Fault\nalarm         likely<\/code><\/pre>\n\n\n\n
This reduces unnecessary false alarms.<\/p>\n\n\n\n
Multi-location monitoring<\/h2>\n\n\n\n
A monitoring service can perform checks from different geographical regions.<\/p>\n\n\n\n
This helps to distinguish between a global outage and a regional network issue.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Z\u00fcrich      \u2192 Error\nFrankfurt   \u2192 OK\nAmsterdam   \u2192 OK<\/code><\/pre>\n\n\n\n
This indicates a different situation than:<\/p>\n\n\n\n
Zurich      \u2192 Error\nFrankfurt   \u2192 Error\nAmsterdam   \u2192 Error<\/code><\/pre>\n\n\n\n
Multiple locations therefore provide additional context during fault diagnosis.<\/p>\n\n\n\n
What is a timeout?<\/h2>\n\n\n\n
A monitoring system does not wait indefinitely for a response.<\/p>\n\n\n\n
If a sufficient response is not received within a specified time, the test can be considered a timeout.<\/p>\n\n\n\n
However, a timeout does not automatically mean:<\/p>\n\n\n\n
Server completely offline<\/code><\/p>\n\n\n\n
It means first of all:<\/p>\n\n\n\n
expected response was not received within the specified time<\/code><\/p>\n\n\n\n
The cause must then be diagnosed.<\/p>\n\n\n\n
Response time is not the same as loading time<\/h2>\n\n\n\n
Many monitoring systems display a response time.<\/p>\n\n\n\n
This number must not automatically be equated with the complete loading time of a website.<\/p>\n\n\n\n
A simple HTTP check might not load the same resources and run the same browser processes as a real visitor.<\/p>\n\n\n\n
Therefore, you should use other measurement methods to analyze the actual website performance.<\/p>\n\n\n\n
We explain how to meaningfully investigate loading times at Measure website loading time and evaluate it correctly<\/a>.<\/p>\n\n\n\n
Website monitoring and PageSpeed measure different things<\/h2>\n\n\n\n
Both tools are occasionally confused with each other.<\/p>\n\n\n\n
Website Monitoring<\/th>Performance analysis<\/th><\/tr><\/thead>
regularly checks availability and defined conditions<\/td>examines the charging and usage experience<\/td><\/tr>
runs continuously<\/td>is evaluated on a spot-check basis or based on collected user data<\/td><\/tr>
can alert about failures<\/td>shows performance issues and optimization potential<\/td><\/tr>
answered \u201eIs the service reachable?\u201c<\/td>answers \u201eHow performant is the page?\u201c<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For a technical analysis with Google PageSpeed Insights, you can find our guide at How to use Google PageSpeed Insights correctly<\/a>.<\/p>\n\n\n\n
What is uptime?<\/h2>\n\n\n\n
Uptime describes the proportion of a considered time period in which a service was measured as available.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
99.9 % Availability<\/code><\/p>\n\n\n\n
does not mean that a website must never go down.<\/p>\n\n\n\n
Even with very high percentage values, a specific possible or measured downtime results mathematically.<\/p>\n\n\n\n
How to properly interpret these values is covered in detail under Uptime and Availability: What 99.9 % Really Means<\/a>.<\/p>\n\n\n\n
Monitoring defines for itself what \u201eavailable\u201c means<\/h2>\n\n\n\n
An important special feature: An uptime value depends on the measurement method used.<\/p>\n\n\n\n
For example, a monitor could specify:<\/p>\n\n\n\n
HTTP 200\n= available\n\nTimeout\n= unavailable\n\nHTTP 500\n= unavailable<\/code><\/pre>\n\n\n\n
Another monitor could accept redirects or perform additional content checks.<\/p>\n\n\n\n
Therefore, uptime values of different systems are not necessarily directly comparable.<\/p>\n\n\n\n
A monitoring result is a measurement, not an absolute truth.<\/h2>\n\n\n\n
Every measurement takes place from a specific location, at a specific time, and with specific rules.<\/p>\n\n\n\n
This means:<\/p>\n\n\n\n
Monitoring location\n\nNetwork path\n\nCheck interval\n\nTimeout\n\nExpected status\n\nConfirmation checks<\/code><\/pre>\n\n\n\n
influence the result.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
What can trigger a monitoring alert?<\/h2>\n\n\n\n
An alarm can have numerous causes.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Web server unreachable\n\nApplication responds with error\n\nPHP error\n\nDatabase problem\n\nDNS issue\n\nNetwork problem\n\nFirewall rule\n\nTimeout\n\nMaintenance work\n\nFaulty redirect\n\nSSL\/TLS issue\n\nExternal service disrupted<\/code><\/pre>\n\n\n\n
The alarm is therefore the beginning of the diagnosis\u2014not automatically the diagnosis itself.<\/p>\n\n\n\n
What should you do first after a failure alarm?<\/h2>\n\n\n\n
First, check if you can reproduce the issue yourself.<\/p>\n\n\n\n
Open the monitored URL and check what is actually happening.<\/p>\n\n\n\n
If possible, also check using another internet connection or a different network.<\/p>\n\n\n\n
After that, you should narrow down the type of error.<\/p>\n\n\n\n
Monitoring reports error\n        \u2193\nAccess website yourself\n        \u2193\nIs error reproducible?\n        \u2193\nCheck HTTP status\n        \u2193\nCheck DNS resolution\n        \u2193\nCheck SSL\/HTTPS\n        \u2193\nOnly one page or\nentire website affected?\n        \u2193\nInvestigate hosting \/ application \/\nnetwork further<\/code><\/pre>\n\n\n\n
Document browser error message<\/h2>\n\n\n\n
If you see a fault yourself, document the exact error message.<\/p>\n\n\n\n
A screenshot can be helpful.<\/p>\n\n\n\n
Also note:<\/p>\n\n\n\n
Time\n\naffected URL\n\nHTTP status, if known\n\nDuration of the outage\n\naffected features\n\nnetwork used\n\nreproducible or sporadic?<\/code><\/pre>\n\n\n\n
This information greatly facilitates subsequent technical analysis.<\/p>\n\n\n\n
Check HTTP status during an outage<\/h2>\n\n\n\n
An HTTP status can provide an important first clue.<\/p>\n\n\n\n
Examples:<\/p>\n\n\n\n
403 Forbidden\n\u2192 Access denied\n\n404 Not Found\n\u2192 requested URL not found\n\n500 Internal Server Error\n\u2192 server-side error\n\n502 Bad Gateway\n\u2192 problem between participating services\n\n503 Service Unavailable\n\u2192 service currently unavailable\n\n504 Gateway Timeout\n\u2192 upstream response\n  not received in time<\/code><\/pre>\n\n\n\n
However, a status code alone does not always name the specific cause.<\/p>\n\n\n\n
Detect DNS problems<\/h2>\n\n\n\n
If a domain name cannot be resolved correctly, the website cannot be reached via its domain name even if the web server is working.<\/p>\n\n\n\n
A monitoring alarm can therefore also be caused by DNS issues.<\/p>\n\n\n\n
Typical questions during diagnosis are:<\/p>\n\n\n\n
Is the domain resolving?\n\nWhat IP address is being returned?\n\nAre the authoritative name servers reachable?\n\nHave DNS records been changed recently?\n\nIs only one resolver or one region affected?<\/code><\/pre>\n\n\n\n
However, DNS should not automatically be assumed to be the cause of every website outage.<\/p>\n\n\n\n
Detect SSL\/TLS problems<\/h2>\n\n\n\n
On an HTTPS website, a certificate or TLS connection issue can cause a monitor to report the check as failed.<\/p>\n\n\n\n
Possible causes can be:<\/p>\n\n\n\n
Certificate expired\n\nCertificate not yet valid\n\nHostname does not match\n\nCertificate chain invalid\n\nTLS connection failed<\/code><\/pre>\n\n\n\n
How we systematically check HTTPS and certificates is covered under Check SSL Certificate and HTTPS: Identify Common Errors<\/a>.<\/p>\n\n\n\n
Website inaccessible only for individual visitors<\/h2>\n\n\n\n
Not every reported unreachability is a global website outage.<\/p>\n\n\n\n
If only a single visitor is affected, there may be local causes, for example:<\/p>\n\n\n\n
Internet connection\n\nlocal DNS resolver\n\nbrowser\n\nVPN\n\nfirewall\n\ncorporate network\n\nrouting between networks<\/code><\/pre>\n\n\n\n
External monitoring from multiple locations helps determine whether the website is down generally or only via specific network paths.<\/p>\n\n\n\n
Website only sporadically slow or unavailable<\/h2>\n\n\n\n
Intermittent issues are among the hardest bugs to fix because the website is often working again by the time manual testing is performed.<\/p>\n\n\n\n
Possible causes can include, for example:<\/p>\n\n\n\n
short-term load peaks\nresource bottlenecks\nslow database queries\nexternal API calls\ncron or background processes\nbackup processes\nnetwork issues\nsporadic application errors<\/code><\/pre>\n\n\n\n
The actual cause cannot be determined from the monitoring alarm alone.<\/p>\n\n\n\n
We explain a systematic performance and error diagnosis at Slow website: systematically finding the causes<\/a>.<\/p>\n\n\n\n
Why timestamps are so important<\/h2>\n\n\n\n
With sporadic faults, the exact timing is often crucial.<\/p>\n\n\n\n
If monitoring reports, for example:<\/p>\n\n\n\n
DOWN: 14:37:22\n\nUP:   14:41:08<\/code><\/pre>\n\n\n\n
server, application, or other technical logs can be specifically examined for this time period.<\/p>\n\n\n\n
Without an exact time specification, searching for the cause is significantly more difficult.<\/p>\n\n\n\n
\n
Practical Tip:<\/strong> In the event of recurring disruptions, always keep the exact time of the monitoring alarm. \u201eThe website was slow sometime yesterday\u201c is much less helpful for a technical diagnosis than a specific time window.<\/p>\n<\/blockquote>\n\n\n\n
What does DOWN mean?<\/h2>\n\n\n\n
A monitoring service often refers to a check as DOWN<\/code>, if the defined success criteria are not met.<\/p>\n\n\n\n
That does not necessarily mean that the entire server was shut down.<\/p>\n\n\n\n
Depending on the monitor, for example, it can already:<\/p>\n\n\n\n
HTTP 500\n\nTimeout\n\nDNS error\n\nSSL error\n\nmissing expected content<\/code><\/pre>\n\n\n\n
as DOWN<\/code> to be counted.<\/p>\n\n\n\n
What does UP mean?<\/h2>\n\n\n\n
Up<\/code> This means accordingly that the current examination meets the defined success criteria.<\/p>\n\n\n\n
This also applies here:<\/p>\n\n\n\n
UP \u2260 guaranteed that every function of the website works<\/code><\/p>\n\n\n\n
For example, a simple monitor can confirm that the homepage 200 OK<\/code> delivers. Whether the complete checkout of an online shop works has not been tested with that yet.<\/p>\n\n\n\n
Online shop monitoring<\/h2>\n\n\n\n
In an online shop, functions other than the homepage can also be mission-critical.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Shop page\n\nProduct page\n\nCart\n\nCheckout\n\nPayment gateway\n\nOrdering process<\/code><\/pre>\n\n\n\n
However, a simple uptime monitor cannot automatically determine whether the entire purchasing process is working.<\/p>\n\n\n\n
This would require more advanced synthetic transaction checks or functional tests.<\/p>\n\n\n\n
Do not blindly monitor the checkout with normal requests<\/h2>\n\n\n\n
Dynamic processes such as shopping carts, checkouts, logins, or forms should not be tested thoughtlessly with simple monitoring calls.<\/p>\n\n\n\n
Such pages can use sessions, cookies, CSRF protection, dynamic tokens, or other application logic.<\/p>\n\n\n\n
For functional transaction checks, the test must therefore be specifically designed for the respective application.<\/p>\n\n\n\n
WordPress monitoring<\/h2>\n\n\n\n
For a WordPress website, the public homepage is a useful basic check.<\/p>\n\n\n\n
Depending on the importance of the website, additional public pages can be monitored.<\/p>\n\n\n\n
On the other hand, you should not simply burden the administration area with automated login attempts.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
View frontend and backend separately<\/h2>\n\n\n\n
For example, a WordPress website can show the following situation:<\/p>\n\n\n\n
Frontend\n\u2192 works\n\n\/wp-admin\/\n\u2192 very slow<\/code><\/pre>\n\n\n\n
or vice versa:<\/p>\n\n\n\n
Web server\n\u2192 reachable\n\nWordPress\n\u2192 Error 500<\/code><\/pre>\n\n\n\n
Therefore, a monitoring result should always be interpreted in the context of the actually monitored endpoint.<\/p>\n\n\n\n
Caching can affect monitoring results<\/h2>\n\n\n\n
A cached homepage can still be delivered very quickly, even though there is a problem in a dynamic area of the website.<\/p>\n\n\n\n
Conversely, an uncached endpoint may show different response times than the public home page.<\/p>\n\n\n\n
This does not mean that caching makes monitoring \u201ewrong.\u201c The monitor simply measures the endpoint you gave it.<\/p>\n\n\n\n
Therefore, the selection of representative tests is crucial.<\/p>\n\n\n\n
CDN and Monitoring<\/h2>\n\n\n\n
If a website is delivered via a content delivery network or a reverse proxy, an external monitor may initially see this upstream infrastructure.<\/p>\n\n\n\n
This can lead to situations where:<\/p>\n\n\n\n
CDN accessible\n\u2193\nOrigin server has problem\n\u2193\nCached content partially still accessible<\/code><\/pre>\n\n\n\n
or:<\/p>\n\n\n\n
Origin works\n        \u2193\nCDN \/ Proxy has outage\n        \u2193\nVisitor still cannot reach website normally<\/code><\/pre>\n\n\n\n
Therefore, during diagnosis, you should consider what infrastructure lies between the visitor and the actual web server.<\/p>\n\n\n\n
Monitoring and maintenance work<\/h2>\n\n\n\n
Scheduled maintenance work can intentionally lead to temporary unavailability.<\/p>\n\n\n\n
Good monitoring systems therefore allow maintenance windows or the temporary pausing of alarms.<\/p>\n\n\n\n
This avoids unnecessary notifications during a known scheduled maintenance.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Which notifications are useful?<\/h2>\n\n\n\n
Depending on the provider, a monitoring system can support different alert channels.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Email\n\nPush notification\n\nSMS\n\nMessenger\n\nWebhook\n\nIncident system<\/code><\/pre>\n\n\n\n
What is crucial is not so much the number of channels, but rather whether a relevant message is actually noticed by a responsible person.<\/p>\n\n\n\n
Too many alarms are counterproductive<\/h2>\n\n\n\n
When a monitoring system constantly sends irrelevant warnings, alarm fatigue occurs.<\/p>\n\n\n\n
Important messages might then be overlooked.<\/p>\n\n\n\n
Therefore, configure:<\/p>\n\n\n\n
meaningful check intervals\nrealistic timeouts\nconfirmation checks\nrelevant endpoints\nappropriate alarm recipients\nmaintenance windows<\/code><\/pre>\n\n\n\n
with a view to the actual intended use.<\/p>\n\n\n\n
What is a false positive?<\/h2>\n\n\n\n
Ein False Positive ist vereinfacht ein Alarm, obwohl der \u00fcberwachte Dienst aus Sicht der relevanten Nutzer nicht tats\u00e4chlich ausgefallen war.<\/p>\n\n\n\n
Beispielsweise k\u00f6nnte nur der Netzwerkweg eines einzelnen Monitoring-Standorts gest\u00f6rt gewesen sein.<\/p>\n\n\n\n
Deshalb sind Wiederholungspr\u00fcfungen und mehrere Standorte bei wichtigeren Systemen hilfreich.<\/p>\n\n\n\n
Was ist ein False Negative?<\/h2>\n\n\n\n
Umgekehrt kann ein Monitor einen Dienst als verf\u00fcgbar bewerten, obwohl f\u00fcr Besucher ein relevantes Problem besteht.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Startseite liefert 200 OK\n\naber:\n\nCheckout funktioniert nicht<\/code><\/pre>\n\n\n\n
Der einfache Startseitenmonitor meldet weiterhin Up<\/code>, obwohl eine gesch\u00e4ftskritische Funktion gest\u00f6rt ist.<\/p>\n\n\n\n
Das zeigt eine zentrale Grenze jedes Monitorings: Es kann nur pr\u00fcfen, wof\u00fcr es konfiguriert wurde.<\/p>\n\n\n\n
Monitoring ersetzt keine Backups<\/h2>\n\n\n\n
Website-Monitoring und Backups l\u00f6sen v\u00f6llig unterschiedliche Probleme.<\/p>\n\n\n\n
Monitoring\n\u2192 erkennt eine St\u00f6rung\n\nBackup\n\u2192 erm\u00f6glicht Wiederherstellung\n  von Daten oder Systemzust\u00e4nden<\/code><\/pre>\n\n\n\n
Ein Monitor kann dich beispielsweise dar\u00fcber informieren, dass eine Website nicht erreichbar ist. Er besitzt dadurch aber nicht automatisch eine verwendbare Kopie deiner Website.<\/p>\n\n\n\n
Monitoring ersetzt keine Sicherheits\u00fcberwachung<\/h2>\n\n\n\n
Eine Website kann technisch erreichbar sein und trotzdem kompromittiert worden sein.<\/p>\n\n\n\n
Ein normaler HTTP-Monitor erkennt nicht automatisch:<\/p>\n\n\n\n
Schadcode\n\nmanipulierte Dateien\n\ngestohlene Zugangsdaten\n\nunerlaubte Administratoren\n\nversteckte Weiterleitungen\n\nDatenabfluss<\/code><\/pre>\n\n\n\n
Uptime-Monitoring ist deshalb nur ein Bestandteil einer umfassenderen technischen \u00dcberwachung.<\/p>\n\n\n\n
Monitoring ersetzt keine Performance-Analyse<\/h2>\n\n\n\n
Eine Website kann 100 Prozent der gemessenen Zeit erreichbar und trotzdem unertr\u00e4glich langsam sein.<\/p>\n\n\n\n
Umgekehrt kann eine sehr schnelle Website gelegentliche Ausf\u00e4lle besitzen.<\/p>\n\n\n\n
Deshalb sollten Verf\u00fcgbarkeit und Performance getrennt gemessen werden.<\/p>\n\n\n\n
Wenn deine Website zwar erreichbar, aber langsam ist, findest du unter Slow website: systematically finding the causes<\/a> einen Diagnoseablauf.<\/p>\n\n\n\n
Monitoring-Daten \u00fcber l\u00e4ngere Zeit auswerten<\/h2>\n\n\n\n
Der eigentliche Wert eines Monitorings entsteht nicht nur durch einzelne Alarme.<\/p>\n\n\n\n
\u00dcber l\u00e4ngere Zeit k\u00f6nnen Muster sichtbar werden.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Ausf\u00e4lle immer nachts?\n\nProbleme immer w\u00e4hrend Backups?\n\nTimeouts nur bei bestimmter Seite?\n\nFehler nur aus bestimmter Region?\n\nAntwortzeiten zu bestimmten\nZeiten auff\u00e4llig?\n\nwiederkehrende 5xx-Fehler?<\/code><\/pre>\n\n\n\n
Solche Muster k\u00f6nnen bei der Ursachenanalyse wesentlich hilfreicher sein als ein einzelner isolierter Alarm.<\/p>\n\n\n\n
Statusseiten<\/h2>\n\n\n\n
Bei gr\u00f6\u00dferen Diensten kann zus\u00e4tzlich eine \u00f6ffentliche oder interne Statusseite sinnvoll sein.<\/p>\n\n\n\n
Sie kann beispielsweise anzeigen:<\/p>\n\n\n\n
Website\n\nAPI\n\nKundencenter\n\nE-Mail-Dienste\n\nweitere Systeme<\/code><\/pre>\n\n\n\n
Eine Statusseite sollte jedoch m\u00f6glichst nicht vollst\u00e4ndig von genau derselben Infrastruktur abh\u00e4ngen, deren Ausfall sie kommunizieren soll.<\/p>\n\n\n\n
Was sollte ein gutes Basis-Monitoring leisten?<\/h2>\n\n\n\n
F\u00fcr eine normale gesch\u00e4ftliche Website sollte ein Basis-Monitoring mindestens klar beantworten k\u00f6nnen:<\/p>\n\n\n\n
Welche URL wird gepr\u00fcft?\n\nWie h\u00e4ufig wird gepr\u00fcft?\n\nWelcher Zustand gilt als Erfolg?\n\nWie lange wird auf Antwort gewartet?\n\nWird ein Fehler best\u00e4tigt?\n\nWann wird alarmiert?\n\nWann gilt die Website wieder als UP?\n\nWer erh\u00e4lt den Alarm?<\/code><\/pre>\n\n\n\n
Nur wenn diese Parameter bekannt sind, lassen sich die gemessenen Werte sinnvoll interpretieren.<\/p>\n\n\n\n
Monitoring richtig dokumentieren<\/h2>\n\n\n\n
Bei wichtigen Websites lohnt sich eine kurze Dokumentation der \u00dcberwachung.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Monitor:\nWebsite Startseite\n\nURL:\nhttps://example.com\/\n\nTyp:\nHTTPS\n\nIntervall:\n5 Minuten\n\nErwartung:\nHTTP 200\n\nAlarm:\nnach best\u00e4tigtem Fehler\n\nEmpf\u00e4nger:\nzust\u00e4ndige Person<\/code><\/pre>\n\n\n\n
Dadurch ist auch sp\u00e4ter nachvollziehbar, was der Monitor tats\u00e4chlich gepr\u00fcft hat.<\/p>\n\n\n\n
Ein typischer Monitoring-Ablauf<\/h2>\n\n\n\n
Website definieren\n        \u2193\nwichtigen Endpunkt w\u00e4hlen\n        \u2193\nPr\u00fcfmethode bestimmen\n        \u2193\nPr\u00fcfintervall festlegen\n        \u2193\nErfolgskriterien definieren\n        \u2193\nAlarmierung konfigurieren\n        \u2193\nMonitoring starten\n        \u2193\nFehler erkannt?\n        \u2193\nKontrollpr\u00fcfung\n        \u2193\nAlarm\n        \u2193\nSt\u00f6rung reproduzieren\n        \u2193\nFehler eingrenzen\n        \u2193\nUrsache beheben\n        \u2193\nWiederherstellung pr\u00fcfen\n        \u2193\nMonitoring best\u00e4tigt UP\n        \u2193\nVorfall dokumentieren<\/code><\/pre>\n\n\n\n
H\u00e4ufige Fehler beim Website-Monitoring<\/h2>\n\n\n\n
nur Ping verwenden\n\n200 OK mit vollst\u00e4ndig\nfunktionierender Website gleichsetzen\n\nAntwortzeit mit kompletter\nLadezeit verwechseln\n\nnur einen irrelevanten\nEndpunkt \u00fcberwachen\n\nbei jedem einzelnen Timeout\nsofort Alarm ausl\u00f6sen\n\nzu viele unwichtige\nMonitore konfigurieren\n\nkeine Zeitstempel dokumentieren\n\ngeplante Wartungen\nnicht ber\u00fccksichtigen\n\nMonitoring als Backup betrachten\n\nMonitoring als Sicherheitsl\u00f6sung betrachten\n\nUP mit \"alles funktioniert\"\ngleichsetzen\n\nDOWN mit \"Server ausgeschaltet\"\ngleichsetzen<\/code><\/pre>\n\n\n\n
Checkliste: Website-Monitoring sinnvoll einrichten<\/h2>\n\n\n\n
Was soll \u00fcberwacht werden?\n        \u2193\n\u00f6ffentliche URL bestimmen\n        \u2193\nHTTP oder HTTPS verwenden\n        \u2193\nerwarteten Status definieren\n        \u2193\nfalls sinnvoll Inhalt pr\u00fcfen\n        \u2193\nPr\u00fcfintervall festlegen\n        \u2193\nTimeout sinnvoll w\u00e4hlen\n        \u2193\nKontrollpr\u00fcfung aktivieren\n        \u2193\nggf. mehrere Standorte nutzen\n        \u2193\nAlarmempf\u00e4nger festlegen\n        \u2193\nTestalarm durchf\u00fchren\n        \u2193\nWartungsfenster ber\u00fccksichtigen\n        \u2193\nMonitoring-Daten regelm\u00e4\u00dfig pr\u00fcfen\n        \u2193\nwiederkehrende Fehler analysieren<\/code><\/pre>\n\n\n\n
Summary<\/h2>\n\n\n\n
Website-Monitoring \u00fcberpr\u00fcft automatisch, ob eine Website oder ein bestimmter Dienst erreichbar ist und die definierten Erfolgskriterien erf\u00fcllt.<\/p>\n\n\n\n
F\u00fcr normale Websites ist ein externer HTTPS-Monitor ein sinnvoller Ausgangspunkt. Je nach Anwendungsfall k\u00f6nnen zus\u00e4tzliche Inhaltspr\u00fcfungen, weitere Endpunkte oder Pr\u00fcfungen aus mehreren Regionen sinnvoll sein.<\/p>\n\n\n\n
Ein Monitoring-Alarm bedeutet jedoch nicht automatisch, dass der komplette Server ausgefallen ist. Ein Timeout, DNS-Problem, HTTP-Fehler, Zertifikatsproblem oder eine gest\u00f6rte Anwendung kann ebenfalls einen Alarm verursachen.<\/p>\n\n\n\n
Umgekehrt beweist ein gr\u00fcner Up<\/code>-Status nicht, dass jede Funktion einer Website einwandfrei arbeitet. Ein einfacher Startseitenmonitor kann beispielsweise keinen vollst\u00e4ndigen Bestellprozess beurteilen.<\/p>\n\n\n\n
Monitoring ersetzt au\u00dferdem weder Backups noch Sicherheits\u00fcberwachung oder Performance-Analyse. Diese Systeme beantworten unterschiedliche technische Fragen.<\/p>\n\n\n\n
Besonders wertvoll wird Monitoring durch kontinuierliche Messungen, genaue Zeitstempel und eine sinnvolle Alarmierung. Bei sporadischen Problemen k\u00f6nnen diese Daten helfen, wiederkehrende Muster zu erkennen und Server- oder Anwendungslogs gezielt f\u00fcr den betroffenen Zeitraum auszuwerten.<\/p>\n\n\n\n
Gutes Website-Monitoring bedeutet deshalb nicht, m\u00f6glichst viele Checks einzurichten. Entscheidend ist, die richtigen Endpunkte mit klar definierten Kriterien zu \u00fcberwachen und bei einer Abweichung schnell die Informationen zu erhalten, die f\u00fcr eine echte Diagnose ben\u00f6tigt werden.<\/strong><\/p>","protected":false},"excerpt":{"rendered":"
Eine Website kann jederzeit ausfallen \u2013 auch wenn sie wenige Minuten zuvor noch problemlos funktioniert hat. Serverprobleme, fehlerhafte Updates, DNS-St\u00f6rungen, abgelaufene Zertifikate oder Probleme mit einer Anwendung k\u00f6nnen dazu f\u00fchren, dass Besucher eine Website pl\u00f6tzlich nicht mehr erreichen. Wer die eigene Website nur gelegentlich selbst aufruft, bemerkt solche St\u00f6rungen m\u00f6glicherweise erst Stunden sp\u00e4ter oder durch […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[85],"doc_tag":[],"class_list":["post-22919","docs","type-docs","status-publish","hentry","doc_category-seo-monitoring"],"year_month":"2026-09","word_count":3699,"total_views":"4","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/en\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"SEO & Monitoring","term_url":"https:\/\/www.curiaweb.ch\/en\/hilfe-kategorie\/seo-monitoring\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22919","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/comments?post=22919"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22919\/revisions"}],"predecessor-version":[{"id":22921,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22919\/revisions\/22921"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/media?parent=22919"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/doc_category?post=22919"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/doc_tag?post=22919"}],"curies":[{"name":"WP","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}