Why you're getting downtime alerts (and why they matter)

You’ve probably had this experience: an email lands from mySites.guru telling you a site is down, you open it in your browser, and it loads perfectly. Frustrating.

But think about it from the other direction. Our server tried to reach your site three separate times and couldn’t. If we can’t get through, there’s a decent chance your visitors couldn’t either during that window.

How do the monitoring checks work?

Every 5 minutes, our custom-built monitoring engine checks each of your connected sites. We don’t fire off an alert on the first failed request. Instead, we run three checks before we tell you anything:

1. We send a HEAD request to your site with a 45-second timeout. If it responds with a success code, we mark it as up and move on.

2. If the first check fails, we wait 10 seconds and send another HEAD request. This catches momentary blips like a slow database query or a brief resource spike.

3. If the second check also fails, we wait another 10 seconds and send a full GET request. Some servers handle HEAD and GET differently, so the final check switches methods to rule that out.

We only send a downtime alert if all three checks fail.

In the worst case, where each request hits the full 45-second timeout, we’ve spent over two minutes trying to reach your site before alerting you. In practice, failed requests usually fail fast (connection refused, DNS error), so the whole thing takes well under a minute.

When your site comes back, we pick that up on the next check cycle and send you a recovery notification.

Why do you get alerts when your site “seems fine”?

You check from your browser and it loads. So why are we saying it’s down? There are a few common causes.

Your host is blocking our IP address

This is the most common one. Hosting providers run firewalls and intrusion detection systems (ModSecurity, Fail2Ban, Imunify360) that automatically block IP addresses making repeated requests. If your sites are behind a corporate firewall, the same thing can happen. Our monitor hits your site every 5 minutes from the same IP, and some security tools decide that’s suspicious and block us.

The block might be temporary, lasting a few minutes to a few hours, or permanent until someone removes it manually. If you see your site going down and coming back up in a pattern, a temporary block is almost certainly what’s happening.

Your server is briefly overloaded

Servers have finite resources. During traffic spikes, heavy cron jobs, backup processes, or plugin updates, there may not be enough capacity to handle new requests for a few seconds. If our check lands during that window, all three attempts can fail.

This is especially common on shared hosting where your sites compete with other customers for the same resources. A full disk partition can cause the same kind of failure.

DNS resolution failures

If your domain’s DNS servers are slow or temporarily unavailable, we can’t resolve your domain to an IP address, and the check fails before it even reaches your server. Less common, but it happens, particularly with budget DNS providers.

SSL/TLS handshake failures

An expired or misconfigured SSL certificate, or an overloaded TLS stack, will cause the secure connection to fail before any page content gets exchanged. We treat that as a failed check.

Why you might NOT get an alert when a site briefly went down

Sometimes a server reboots or briefly chokes, and you check the dashboard expecting to see a DOWN event, and there’s nothing. No email, no log entry, no record at all.

That’s the 5-minute cadence at work.

Each site is checked once every 5 minutes. The 3-step verification (HEAD, HEAD, GET) all happens inside that single check, not across three separate checks 5 minutes apart. So if your server is unreachable for, say, 90 seconds and then comes back, two things determine whether we see it:

• Did our 5-minute check happen to land during that 90-second window? If not, the site was unreachable but we weren’t looking at that moment, so nothing gets recorded.
• If the check did land in the window, did all three attempts (HEAD, HEAD, GET) fall inside it? If even one attempt got a successful response, the check passes and nothing gets recorded.

For a fast server reboot, the kind that finishes in 60 to 90 seconds, you can easily end up with no DOWN events recorded for any of the sites on that server, even though every site was technically unreachable for a minute. Most 5-minute checks either land before or after the reboot window, or land during it but catch a successful HEAD or GET before the window closes.

Why we don’t check more often

5 minutes is a trade-off, and for an agency tool it’s the right one.

If you manage 500 sites across a handful of servers, a 1-minute check interval would mean:

• Five times more traffic from our monitoring IP hitting your hosts
• Five times more chances of triggering firewalls, rate limiters, or “this IP looks suspicious” rules
• When a shared server hiccups, you get five times more emails for the same event

Most agencies don’t need to know about a 60-second blip on a single site. They need to know when something stays broken: a site that won’t come back, an SSL cert that’s expired, a hack signature that’s appeared. The 5-minute cadence catches sustained outages while keeping the noise floor low.

If you need 1-minute detection

If you have specific sites where a 60-second outage actually costs you money, run a dedicated uptime service alongside mySites.guru. Plenty of tools are built for exactly that use case and check at 1-minute or 30-second intervals. Use them for the handful of business-critical sites, and let mySites.guru handle the long tail.

mySites.guru is built for agencies managing hundreds of sites where the realistic outage scenarios are server-level, not single-site. Flooding you with emails about every brief blip would be worse than the problem it’s trying to flag.

What happens when all your sites go down at once?

If you manage dozens or hundreds of sites and they all show as offline at the same time, it’s almost never a coincidence.

When all your sites live on the same server, they share a single point of failure. If that server has a problem, every site on it goes unreachable at once. Common causes:

• A runaway process or traffic surge eats all available RAM and the web server stops accepting connections
• Heavy background tasks (backups, malware scans, bulk updates) peg the CPU so hard that nothing else gets served
• The server hits its maximum concurrent connections and starts rejecting new ones
• The server’s firewall sees our IP hitting many different domains and decides we’re attacking it, blocking us across the board
• A brief network interruption between our server and yours

These events are usually short - 30 seconds to a couple of minutes - but our 5-minute check interval with 3-step verification means even brief outages get caught and reported.

If all your sites are on one server and they all go offline together, the server is the problem. Talk to your hosting provider about the resource limits on your plan, or consider spreading sites across multiple servers so a problem on one only affects part of your portfolio.

What can you do about it?

1. Whitelist our monitoring IP

Start here. Ask your hosting provider to whitelist this IP address:

Have them add it to their firewall’s allow list so it never gets blocked or rate-limited. This solves the most common cause of false downtime alerts.

If you manage your own server, you can do it yourself. In CSF (ConfigServer Security & Firewall), add the IP to /etc/csf/csf.allow. In Fail2Ban, add it to the ignoreip setting.

2. Check your server resources

Frequent brief downtime across multiple sites on the same server usually means the server is underpowered. Look at your memory usage, CPU load during the times alerts arrive, and disk space. Your hosting control panel usually has graphs for this, or ask their support team.

3. Spread sites across multiple servers

If you have 50+ sites on one server, splitting them across two or three servers means a problem on one only takes down part of your site portfolio. It also makes troubleshooting easier because you can see exactly which server is having issues based on which group of sites goes offline.

4. Review your security software

Check that rate-limiting thresholds on your server or security plugins aren’t set too aggressively. Monitoring traffic from a known IP every 5 minutes is not an attack.

5. Look at the timing

If your alerts cluster around specific times (say, every night at 2 AM), something scheduled on your server is probably eating all available resources during that window. Backups and bulk updates are the usual suspects - consider staggering your schedules.

”My webhost says your monitoring is causing high load”

Every so often a customer forwards us a message from their hosting support team claiming that 165.227.239.229 is hammering the server and causing performance problems. It isn’t.

The monitoring checks work like this: one HEAD request per domain, every five minutes. That’s 12 requests per hour, per site. A HEAD asks for response headers only, not the page body, so on a normally configured site WordPress, Joomla, PHP, and the database never run. The web server returns headers and closes the connection. There is no meaningful CPU, memory, or database cost.

A single real visitor loading your homepage triggers a full GET: PHP boots, the database is queried, the theme renders, images and CSS and JavaScript are served. One visit costs hundreds of times more than a month of our HEAD checks put together.

1,000 sites on one server means 1,000 checks every 5 minutes

If you host 1,000 customer sites on a single server, we’ll make 1,000 HEAD requests against that server every 5 minutes. One per domain. A support associate skimming the access log sees a thousand hits from our IP in a five-minute window and concludes we’re abusing the server.

We aren’t. That’s 1,000 separate sites each receiving exactly one HEAD request every 5 minutes. Per domain, the footprint is tiny. The total only looks large because the server happens to be hosting a lot of domains, and each of those domains is paying for its own uptime monitoring.

Most dedicated uptime monitoring services (UptimeRobot, Pingdom, StatusCake and the rest) run their checks every minute, not every five. So if those services are fine on this server, ours, which generates one-fifth of the traffic, should be too.

If your host really is seeing load from our IP

Two possibilities:

• Your homepage is heavy enough that even one request every 5 minutes is noticeable. The frequency isn’t the issue then, the homepage is. Real visitors are paying that same cost far more often than we are.
• The host is reading access log volume and pattern-matching on the IP without checking what the requests are doing. Ask them to confirm the request method (it’ll be HEAD) and the response body size (it’ll be 0 bytes).

To check for yourself, your server’s access log will have entries like this from our IP:

165.227.239.229 - - [12/May/2026:09:00:00 +0000] "HEAD / HTTP/1.1" 200 0 "-" "mySites.guru Uptime Monitor"

The HEAD method and the 0-byte response are the proof. Send that line to your host if they need convincing.

Why should you take the alerts seriously?

We built the monitoring engine to avoid false positives. Three checks, pauses between each, a different HTTP method on the final attempt. If we send you an alert, our server genuinely could not reach your site after multiple attempts over at least 20 seconds.

If we can’t reach your site, your visitors probably can’t either. Each downtime alert represents a window where real visitors may have hit an error page or a timeout instead of your site.

The alerts aren’t the problem. They’re telling you about it.

Need help?

If you’re still getting frequent alerts after whitelisting our IP, get in touch. We can check the response codes and timing from our end to help narrow down what’s going on.

For the broader monitoring picture, see our complete monitoring and alerting guide.