Monitoring website uptime and downtime alerts

When your website goes down for a few minutes, the first person who should find out is you, not the user or the sales manager. A delay in learning about an outage means lost sales, trust, and SEO. Uptime Monitoring was built precisely for this: periodically checking website availability and notifying you immediately when a problem occurs. But if you configure the tool incorrectly, instead of helping, it becomes a source of stress; false alerts at midnight, unnecessary notifications, and ultimately the team losing trust in the alerting system. In this guide, you'll learn how to set up uptime monitoring correctly, choose the optimal check interval, and minimize false alerts.

Why Does Uptime Monitoring Seem Simple but Often Goes Wrong?

The core idea is simple: an external service sends an HTTP request to your website every few minutes, and if it doesn't receive a response, it notifies you. But the problem starts when "doesn't receive a response" lacks a precise definition. Does it mean a timeout? An HTTP 500 error? Excessive slowness? Each of these can have different meanings, and if you don't clarify the definition, your system will either be overly sensitive or so slow that it's practically useless.

The Difference Between Real Downtime and Temporary Disruption

Real downtime means the site is completely unavailable for several minutes or more. But a temporary disruption could be a response that took 3 seconds, or a 503 error returned by the CDN that was immediately resolved. An uptime monitoring tool must be able to distinguish between the two. If you alert on every transient error, your team will quickly learn to ignore notifications — and that's exactly what shouldn't happen.

Choosing the Check Interval; Balancing Speed and Cost

The most common question in uptime monitoring is: "How often should I check?" The short answer: it depends on your budget and needs. The technical answer: usually between 30 seconds and 5 minutes.

30 Seconds to 1 Minute Interval

This interval is suitable for critical sites such as payment gateways, API services with strict Service Level Agreements (SLAs), or high-traffic online sales platforms. Advantage: you'll find out about outages almost immediately. Disadvantage: higher cost (because more traffic is sent to your server) and a higher chance of false alerts if settings aren't correct.

2 to 5 Minutes Interval

For most corporate sites, blogs, and medium-sized online stores, a 2 to 5 minute interval is perfectly reasonable. In this range, if the site is down for 10 minutes, you'll be notified at most 5 minutes after the outage begins. This is usually sufficient for a timely response and keeps costs and noise low.

More Than 5 Minutes Interval

For non-critical sites where a few minutes of downtime doesn't create a crisis, you can choose a 10 or 15 minute interval. But remember: if your site is down for 20 minutes and you find out 15 minutes later, many users will have already seen that the site isn't working.

Uptime Monitoring Tools; From Simple to Advanced

There are many tools for uptime monitoring. Your choice depends on your budget, the number of sites, and the need for integration with other tools.

Public Cloud Services

Services like UptimeRobot, Pingdom, and StatusCake are among the most well-known. UptimeRobot has a free tier with a 5-minute check interval and up to 50 monitors, which is great for getting started. Pingdom offers more features like speed checks and more detailed reports, but its cost is higher. These services check from various servers in different locations worldwide, which is a big advantage: if a data center in Europe has an issue, the monitor from the US will still see your site and won't send a false alert.

Setting Up a Dedicated Monitor with a Simple Script

If you want full control and don't want to pay extra, you can run a simple script on a separate server (not on the same server as your site!). The example below works with Bash and curl:

#!/bin/bash
URL="https://example.com"
EXPECTED_CODE=200
TIMEOUT=10

HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" --max-time $TIMEOUT "$URL")

if [ "$HTTP_CODE" != "$EXPECTED_CODE" ]; then
    echo "ALERT: $URL returned $HTTP_CODE at $(date)" >> /var/log/uptime-alerts.log
    # Send message via Telegram API or email
    curl -s -X POST "https://api.telegram.org/botYOUR_TOKEN/sendMessage" \
        -d chat_id=YOUR_CHAT_ID \
        -d text="⚠️ Site outage: $URL (HTTP $HTTP_CODE)"
fi

Run this script with cron:

*/2 * * * * /usr/local/bin/check-uptime.sh

Advantage of this method: zero cost, full control over alerting logic. Disadvantage: you're only checking from a single point, so if your own monitoring server has a problem, you'll get false alerts.

Avoiding False Alerts; The Most Important Part of Uptime Monitoring

A false alert means the system tells you the site is down when it isn't. This happens more often than you think, and the main reason is incorrect configuration. In this section, we'll review three practical techniques to reduce false alerts.

1. Using an Error Threshold Instead of a Single Error

Instead of telling the service "alert if you see a single error," say "alert if you see 3 consecutive errors." Most professional tools have this capability. In UptimeRobot, this setting is called "Max Retries" or "Attempts." This way, a transient error (e.g., due to network fluctuation) won't trigger an alert, but a real outage lasting several minutes will definitely alert you.

2. Checking from Multiple Geographic Locations

If your service only checks from one location and that location (e.g., a data center in Frankfurt) experiences a network issue, you'll get a false alert. Professional tools allow you to specify that at least 2 or 3 out of 5 locations must see an error for an alert to be issued. This significantly reduces the likelihood of false alerts.

3. Setting a Smart Timeout

Many false alerts occur due to a short timeout. If your site typically responds in 2 seconds but sometimes takes 5 seconds due to processing a heavy report, don't set the timeout to 3 seconds. A value of 10 to 15 seconds is reasonable for most sites. Remember: the goal of uptime monitoring is to detect complete outages, not slowness. For slowness, a separate tool like Performance monitoring is needed.

Configuring Alerts; To Whom, Via What Channel, With What Content?

A good alert means the right message, to the right person, at the right time. If you send the alert to everyone, no one takes responsibility. If you send it to only one person and they're unavailable, the entire system becomes useless.

Alert Channels

• Telegram or SMS: For immediate alerts that require a response. Telegram is free and easily connected via Bot API. SMS costs money but is worth it for critical outages.
• Email: For periodic reports and non-urgent alerts. Don't use email for real outages because it might not be seen for hours.
• Ticketing system (like Slack or Rocket.Chat): For recording alerts and team follow-up. Don't consider this channel as the primary outage alert channel because its notifications might be turned off.

Alert Content

A good alert should include the following:

1. Name of the site or service (e.g., "Main Store" not just example.com)
2. The received HTTP error code (e.g., 500 or 503)
3. The exact time the problem started (in local time)
4. The location that observed the error (e.g., Frankfurt)
5. A direct link to the monitoring dashboard for real-time status checking

Example of a good message:

⚠️ Service Outage: Main Store (shop.example.com)
Error Code: HTTP 503
Start Time: 2025-06-15 14:32:10 (UTC+3:30)
Error Source: Frankfurt, Germany
Current Status: Rechecking (attempt 2 of 3)
Dashboard: https://status.example.com

Real Health Checks; Going Beyond the HTTP Response

Uptime monitoring doesn't just mean the site returns a 200 status code. A site can return a 200 code but display a PHP error on the homepage or have its database disconnected. For real monitoring, you need to check the response content as well.

Keyword Checking

Most uptime monitoring tools allow you to search for specific text in the response. For example, you can say "alert if the phrase 'Login' is not on the homepage." This prevents false alerts caused by minor errors and ensures the site is actually working, not just returning a white error page with a 200 code.

# Check for the presence of a key phrase in the response
if curl -s --max-time 10 "$URL" | grep -q "ورود به حساب"; then
    echo "OK"
else
    echo "ALERT: keyword not found"
fi

Monitoring Different Layers

For a complete website, it's better to have three separate monitors:

• HTTP Monitor: Checks the availability of the homepage (2-minute interval)
• API Monitor: Checks a critical endpoint like /api/health (1-minute interval)
• DNS Monitor: Checks that the site's DNS records respond correctly (15-minute interval)

This separation helps you troubleshoot faster when a problem occurs. If DNS is working correctly but HTTP is returning errors, the problem is with the web server, not DNS.

Summary; Final Checklist for Setting Up Uptime Monitoring

To ensure your uptime monitoring works correctly from day one, follow these steps in order:

1. Choose the check interval based on site importance (2 minutes for critical sites, 5 minutes for others)
2. Set the timeout to at least 2 times your site's average response time
3. Set the error threshold to 3 consecutive attempts
4. Enable checking from at least 2 geographic locations
5. Add a content monitor (Keyword) for the homepage
6. Choose Telegram or SMS as the primary alert channel, not email
7. Send alerts only to responsible individuals, not the entire team
8. Create a separate monitor for the API or critical path of the site
9. Run the monitoring script or service on a server separate from the main site
10. Review the settings once a month and update them if your infrastructure changes

Uptime monitoring is a small investment with a large return. With the right settings, you'll not only be informed of outages sooner, but you'll also maintain your team's trust in the alerting system. If you're looking for a solution that doesn't require managing monitoring infrastructure, cloud monitoring services offered by hosting companies like ServerNet can be a good option. But in any case, the principles we've reviewed in this guide — check interval, error threshold, and content checking — are the same regardless of which tool you choose.