How to Monitor Website Downtime? Methods for Online Status and Real-Time Alerts

The real problem with website downtime is often not how long it takes for the server to recover, but how long it takes for someone to notice the failure. If a corporate website experiences connection timeouts in the early morning without continuous monitoring, it might not be discovered until the next business day. An e-commerce site's order API returns 500, but the homepage still loads fine; operations staff only realize the checkout process is broken when traffic drops. Some failures are even more subtle: Shanghai Telecom users access the site normally, but Guangzhou Mobile users keep timing out. Technicians test locally and find no issues, while users have already reported the site is unreachable. So, "the server is still running" does not necessarily mean the website is healthy.

DNS resolution errors, CDN node issues, SSL certificate problems, carrier line failures, and application API errors can all produce results that look very similar to a server outage. To catch these issues early, you can't rely on user reports or occasional manual checks. Instead, you need a continuous website status monitoring and real-time alerting system. Let's look at how to determine if a website is down, how to monitor it, and the proper troubleshooting sequence from an operations perspective.

1. What Counts as Website Downtime?

When people hear "website downtime," they often think of a server being powered off or a data center losing connectivity. In reality, actual website failures are much more complex. From a user experience perspective, if users cannot complete access or critical operations, it's already an availability anomaly, just with varying severity.

1.1 Entire Site Completely Inaccessible

This is the most typical downtime scenario. For example, monitoring requests to the site consistently show:

Connection Timeout
Connection Refused
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

If detection nodes across different regions and carriers show the same issue, you should focus on the origin server, load balancer, CDN, data center network, and application services. This type of failure is usually easier to detect because the impact is widespread and user reports are concentrated.

1.2 Only Some Regions Inaccessible

This problem is harder to diagnose. For example, the same website shows the following results at the same time:

Accessing the website from an office in Shanghai works perfectly, but Guangzhou Mobile users can't open it. This could be related to carrier lines, DNS routing, CDN regional nodes, BGP routes, or even network reachability of specific IPs. It cannot be simply attributed to "server down." Therefore, website status monitoring should not rely on a single detection location.

1.3 Homepage Online, but Core Business Unavailable

Another easily overlooked scenario is when the website doesn't appear to be down.

For example:

Homepage                  200 OK
Product Detail Page       200 OK
/api/login                200 OK
/api/order                500
/checkout                 Timeout

If the monitoring system only checks the homepage, it will always show the website as healthy. But for an e-commerce site, users can't place orders; for a SaaS platform, if login or core APIs fail, it's equally a severe outage. So, determining whether a website is down shouldn't just ask "Can the homepage load?" but also: Can users complete their most critical business processes?

2. How Is Website Downtime Detected?

The principle of website monitoring is not complicated. Simply put, it involves having probe nodes located on the external network actively access the website at fixed intervals and record the results of each access.

For example, requesting once every minute:

https://example.com/

Under normal conditions, you might get:

HTTP/1.1 200 OK
Response Time: 183ms

If the website has issues, it might return:

HTTP/1.1 503 Service Unavailable

Or directly:

Connection Timeout

The monitoring system continuously records these results and triggers alerts once abnormal conditions are met.

In practice, monitoring typically focuses on several basic signals:

• Whether the website can establish a connection;

• Whether HTTP/HTTPS returns normally;

• Whether HTTP status codes are abnormal;

• Whether response time suddenly spikes;

• Whether DNS resolves correctly;

• Whether SSL/TLS handshake is normal;

• Whether the page returns expected content;

• Whether core APIs respond normally.

There's an important distinction here: A single failed access doesn't necessarily mean the website is truly down. The public internet inherently has brief packet loss, route flapping, and node anomalies. If a monitoring node times out once and immediately sends a downtime alert, it can generate many false positives. A more reliable approach is continuous detection with secondary confirmation, for example:

First detection fails
        ↓
Retry after 30 seconds
        ↓
Still fails
        ↓
Other nodes verify simultaneously
        ↓
Confirm anomaly scope
        ↓
Trigger alert

This way, you can detect failures quickly while reducing interference from occasional network jitter.

3. Why Can't You Monitor a Website with Just One Node?

Having a single server doesn't mean users access the website through a single path. A user in Beijing accessing a website hosted in Hong Kong might go through the Unicom backbone; a Guangzhou Mobile user accessing the same site will go through a completely different carrier network and egress. With CDN, requests might even be routed to different edge nodes.

This leads to a very common phenomenon: The website isn't entirely down; a specific access path is broken. For example, during a website anomaly:

Shanghai Telecom     82ms      Normal
Beijing Unicom      103ms      Normal
Chengdu Telecom      97ms      Normal
Guangzhou Mobile     Timeout   Anomaly
Shenzhen Mobile      Timeout   Anomaly
Hong Kong            71ms      Normal

If your monitoring server happens to be in Shanghai, the monitoring dashboard might show "Online" throughout the entire incident.

But for some Mobile users in Guangzhou and Shenzhen, the website is actually unavailable.

Therefore, website monitoring should cover the main regions where real users are located and include different carriers as much as possible.

For domestic business, especially focus on: China Telecom, China Unicom, China Mobile + major provincial nodes.

If you also have cross-border business, add nodes in Hong Kong, Singapore, Japan, the US, or other major markets to get results closer to real user access.

4. How to Determine if a Website Is Truly Down Using Multiple Nodes?

After receiving reports of "website unreachable," the first thing you should do is not rush to restart the server, but confirm the scope of the failure.

This can be quickly done using Chahu's multi-node detection. Use Chahu Website Monitoring to observe the website status from different regions and carriers. Chahu's current network detection system supports viewing by China Telecom, China Unicom, China Mobile, as well as Hong Kong, Macau, Taiwan, and overseas nodes. After obtaining multi-node results, you can generally judge based on the following scenarios.

Scenario 1: Most Nodes Fail Simultaneously

If Telecom, Unicom, Mobile, and overseas nodes all show connection timeouts or 5xx errors, the likelihood of a complete website outage is high.

In this case, focus on checking: whether the server is running normally, whether the web service is started, whether CDN is properly fetching from the origin, whether firewall policies are incorrectly blocking, whether the domain resolves correctly, and whether the data center network has issues.

Scenario 2: Only One Carrier Is Affected

Don't rush to upgrade server specs; it's not a performance issue. Focus on the carrier's lines, DNS routing, and whether the routing toward that carrier is correct.

Scenario 3: Only One Region Is Affected

It's likely a regional network link issue, or these nodes have been incorrectly routed by CDN to the same faulty edge node.

Scenario 4: Website Accessible but Response Time Significantly Abnormal

A page that normally loads in 100ms suddenly takes 2-3 seconds for over ten minutes. This is a warning sign before a complete outage. Before it becomes fully paralyzed, check database pressure, origin server CPU load, and network bandwidth.

5. How Should Real-Time Alerts Be Configured?

If monitoring only logs events without sending notifications, it's just a cold statistical report. Effective online monitoring should proactively alert operations staff when problems arise, extinguishing failures before users complain en masse. To make alerts truly useful, several key points matter:

5.1 Don't Alert on a Single Failure

If you send SMS alerts for every occasional timeout, operations staff will become desensitized and eventually mute notifications. A reasonable approach is to set a "buffer mechanism": determine the number of consecutive failures based on business criticality. For example, a regular corporate website can alert after 2-3 consecutive failures; for core business, you can increase detection frequency and use cross-validation from multiple regional nodes, sending notifications only after confirming the issue.

5.2 Don't Only Set "Site Offline" Alerts

In real operations, a completely unreachable website is just the ultimate form of failure; many issues show signs before collapse. Besides basic connectivity, these metrics are also worth monitoring:

One important note: Don't use a one-size-fits-all response time threshold. An API that normally takes 150ms suddenly spiking to 1.5 seconds is definitely a problem, even if it hasn't timed out. But a report page requiring complex calculations might take 2 seconds and be perfectly normal. The safest approach is to let monitoring run for a few days to establish normal baselines for each endpoint, then set reasonable warning thresholds.

5.3 Alerts Must Be Severity-Based

Not every trivial issue warrants waking someone up in the middle of the night.

For example, an SSL certificate expiring in 15 days can be handled with an email or a DingTalk group message; a brief fluctuation in an edge node can be logged for observation. But if multiple core nodes are unreachable simultaneously, you must immediately trigger high-priority alerts via phone or SMS.

Also, clearly define team roles for handling different severity levels. Otherwise, a truly critical issue might be ignored among daily noise, which would be the biggest disaster.

6. What Is the Correct Troubleshooting Sequence After a Website Outage?

Once you confirm a website failure, the worst thing is to act like a headless chicken, frantically changing configurations. You might turn a minor network fluctuation into a bigger mess by accidentally breaking things.

The most efficient troubleshooting approach is to peel the onion from the outside in, gradually narrowing down the suspect scope.

Step 1: Assess the Scope of Impact 

Upon receiving reports of unreachability, the first thing is to use Chahu to test from several different regions and carriers. Determine: Is the entire website down, or are only some users affected?

• All national and overseas nodes fail: This likely points to a major issue with the origin server, CDN overall service, or DNS.

• Only specific regions or a particular carrier can't access: Don't touch the origin server; focus on carrier lines, DNS routing, and CDN edge nodes.

Once this is clear, subsequent troubleshooting won't go astray.

Step 2: Check the HTTP Status Code 

As long as the request can connect to the server, look at the error code returned. This helps you directly locate the failure layer:

• 502 Bad Gateway: The front-end proxy (e.g., Nginx or CDN) can't find the upstream origin server. Check if the origin server's service process is still running.

• 503 Service Unavailable: The server is currently overwhelmed, likely due to traffic spikes, database connection pool exhaustion, or scheduled maintenance.

• 504 Gateway Timeout: The front-end gateway sent the request, but the origin server didn't respond in time, often due to database deadlocks or slow backend logic.

• Direct Connection Timeout: If you can't even get a status code, skip the web service and check firewall policies, server port listening, and basic network connectivity.

Step 3: Check DNS Resolution for Issues 

DNS is a frequently overlooked part of troubleshooting. Use a DNS lookup tool to see if the domain resolves to the correct IP and whether results are consistent across regions.

Focus on these points:

• Have A/AAAA records or CNAME been accidentally changed?

• Is it still resolving to an old server IP that should have been decommissioned?

• Is the CDN domain working correctly?

• Is only one carrier getting incorrect resolution results?

A common example: A website just switched to CDN. Shanghai users are already on the new nodes, but DNS in some southern regions is still caching the old IP, causing the strange phenomenon of "some can access, some can't."

Step 4: Run a Few Pings to Check Basic Connectivity 

If DNS resolution is fine, use Chahu's online Ping to test latency and packet loss to the target IP.

Here's a big pitfall: Ping failure doesn't mean the website is down. Many servers and security firewalls block ICMP to prevent scanning. The real value of Ping is to observe:

• Has latency suddenly spiked several-fold?

• Are certain regions experiencing unacceptable packet loss?

• Is only Mobile or Unicom unable to reach the server?

If HTTP requests time out and multiple nodes also show severe packet loss or latency spikes, you can be confident it's a network path issue.

Step 5: Use Traceroute or MTR to Trace the Route 

Once you've determined it's a network layer issue, you need to see which backbone node is the bottleneck.

The path from user to origin server is roughly: User → Local ISP → Provincial backbone → Cross-network/International egress → CDN edge node → Origin fetch link → Origin server

Trace along the path to see where latency suddenly jumps to hundreds of milliseconds or where packet loss becomes severe. Whether it's a congested cross-network interconnection or a broken CDN origin fetch link, you'll find it.

Compared to blindly restarting the server when you see "unreachable," this outside-in, layer-by-layer approach is not only faster but also avoids secondary damage from misoperations.

7. Why Shouldn't You Monitor Only the Homepage?

Many people new to operations or website building configure monitoring with just the homepage URL: https://example.com.

Having monitoring is better than nothing, but for websites that rely on traffic monetization or core business, monitoring only the homepage is turning a blind eye.

In real operations, this scenario is all too common:

https://example.com/ (Homepage)            --> 200 OK (fast)
https://example.com/item/123 (Product)     --> 200 OK (normal)
https://example.com/user/login (Login)     --> 200 OK (no problem)
https://example.com/api/order (Order)      --> 500 Internal Error (backend error)
https://example.com/checkout (Checkout)    --> Timeout (stuck)

At this point, your monitoring dashboard might show a sea of green lights, but the ordering and payment processes that drive revenue are already down. Users can't buy anything, complaints pile up, and you still think the website is running fine.

So, the core principle for setting up monitoring is: Monitor the critical actions users must complete, not just the storefront.

Different types of websites have different priorities:

• Corporate websites: Focus on the homepage, key landing pages, domain DNS resolution, and SSL certificate expiration.

• E-commerce platforms: Besides the homepage and product pages, cover login, cart, order API, and checkout pages end-to-end.

• SaaS platforms: Focus on /login, core business APIs, /api/health checks, WebSocket long connections, and background task queues.

• API services: Don't just check if the port is open. Validate HTTP status codes, response times, and even the structure of returned JSON data.

Some services have an /api/health endpoint that returns 200 OK as long as Nginx is alive, regardless of database health. This fake "health" is meaningless. Once the underlying database or cache fails, business APIs will error out, but simple online checks still think everything is fine. By monitoring these critical paths closely, you can receive notifications the moment business is affected.

8. How Often Should You Monitor a Website?

The frequency depends on how much money you lose per minute of downtime.

• Personal blogs, simple corporate sites: Testing every 1-5 minutes is sufficient; no need to overdo it.

• E-commerce, SaaS platforms, online business systems: Recommend testing every 30 seconds to 1 minute.

• Payment services, core financial APIs: Require high-frequency external monitoring and must be combined with internal server metrics (CPU, memory, logs).

However, don't blindly pursue "test every 10 seconds." If you only have one monitoring node, no matter how high the frequency, a brief network glitch on that node will trigger false alarms. A truly reliable monitoring system is always: Reasonable detection frequency + multi-node cross-validation + consecutive failures before alerting + severity-based notifications. This combination is far more effective than just competing on frequency numbers.

Monitoring website downtime isn't about "occasionally opening a webpage to check." It's about establishing a continuous external detection mechanism to catch anomalies before they affect a large number of users. For regular websites, HTTP status, response time, and core pages are the most basic monitoring content. If you use CDN, overseas servers, or have users distributed across multiple regions, you can't rely on a single node; you should also observe access results from different carriers and regions.

During routine inspections or when anomalies are detected, you can use Chahu Website Monitoring to observe the website's online status from different regions. If only some nodes show anomalies, combine DNS, Ping, and routing information to continue troubleshooting. This usually helps you quickly distinguish between server failures, CDN routing issues, or specific carrier line problems. The purpose of website monitoring is never to look at more numbers, but to turn "users report the site is down" into "users haven't noticed yet, but we're already handling it." That's the real value of continuous monitoring.

Related Q&A

1. The website works locally, but monitoring shows 502 Bad Gateway. Why?

This is usually caused by communication failure between Nginx, a reverse proxy, or CDN and the origin server. Local access might work because you're connecting to a specific node or using an internal network, while external monitoring requests hit an abnormal reverse proxy node. In this case, first check if the origin application process (e.g., PHP-FPM, Node.js instances) crashed under sudden high concurrency, or if the proxy_read_timeout in the gateway layer is too short.

2. Why does only a specific carrier fail to open the website on the public internet?

This is often not a server shutdown but a network transmission link failure. Common causes include: DNS smart resolution assigning an invalid IP to that carrier; congestion or route detours at the carrier's cross-network backbone egress; or a CDN edge node deployed on that carrier being down. You can use Chahu to filter nodes for that specific carrier and run Ping and MTR traces to identify the specific backbone route segment where packets are lost.

3. Can SSL certificate failures cause monitoring systems to judge the website as down?

Yes. Most rigorous HTTP(S) monitoring nodes will terminate the TCP connection and mark an error (like SSL Handshake Failed) when they encounter SSL/TLS handshake failures, expired certificates, domain/certificate mismatches, or missing intermediate certificate chains. To prevent sudden website inaccessibility due to certificate expiration, it's recommended to set a separate medium-risk alert for SSL certificate remaining validity (e.g., less than 15 days).

4. After receiving a website downtime alert, what should be the first step in troubleshooting?

Don't blindly restart the server. The first step is to confirm the scope of the failure: use multi-node monitoring tools to see if it's a nationwide outage or a single region/carrier issue. The second step is to check error status codes: if it's 502/504, look into reverse proxy and origin communication; if it's DNS Lookup Failed, check domain resolution and registrar; if it's Connection Timeout, prioritize checking the origin firewall, security group policies, or data center network disconnection.

5. Since we already have internal server monitoring (e.g., CPU, memory), why do we still need external website monitoring?

Because internal monitoring has a "blind spot." A server CPU usage of 10% only indicates ample hardware resources, but if public DNS resolution is tampered with, CDN nodes fail, SSL certificates expire, or carrier backbone routes are interrupted, internal monitoring won't detect it at all. External monitoring probes from the real user access path perspective, directly reflecting the end-user experience.