How to Set Up Uptime Monitoring for Your Websites

What uptime monitoring actually checks

Uptime monitoring works by having a service outside your network repeatedly request your website — usually every one to five minutes — and alert you the moment it stops getting a healthy response back. That is the whole mechanism: an external check, from outside your infrastructure, confirming your site is actually reachable from the internet, not just running.

That "external" part matters. A server can be fully up — CPU idle, disk fine, every service running — and still be unreachable to visitors because of a DNS misconfiguration, a firewall rule that got tightened too far, a routing issue upstream of your provider, or the entire VM being unreachable. None of that shows up if you are only watching server-side metrics like CPU and RAM from inside the box. Uptime monitoring exists specifically to catch the class of failure your own server cannot see about itself.

It is easy to conflate uptime monitoring with server monitoring, but they answer different questions. Server monitoring (CPU, memory, disk, process health) tells you whether the machine is healthy. Uptime monitoring tells you whether a visitor typing your domain into a browser gets a working page back. A server can be "up" in every metric that matters to a sysadmin and still serve a 500 error, a blank white screen, or nothing at all if a web server process crashed and did not restart. You need both, but if you can only set up one first, set up the one that matches what your customers actually experience.

Choosing a monitoring approach

You have two realistic options: a third-party external uptime service, or a self-hosted cron-plus-curl check — and for anything customer-facing, the third party wins.

Third-party services like UptimeRobot, Better Uptime, or Pingdom run checks from multiple points around the world — different regions, different networks, different backbone providers. That matters because a single network path can develop a routing problem that makes your site look down to some visitors and fine to others. A multi-region check distinguishes "the site is actually down" from "there is a blip between one specific network and my server," and most of these services only alert once several regions agree the site is unreachable, which cuts down on noise.

A self-hosted check — a cron job that curls your homepage every minute and emails you on a non-200 response — is trivial to set up and costs nothing, but it has one structural blind spot: it only ever checks from one location, over one network path. If that server, or the network between it and your target, has a problem, you get either a false alarm or, worse, silence when you actually needed the alert. It is a fine supplementary check for something internal or low-stakes, but it should not be the only thing standing between you and finding out your production site is down.

For anything customer-facing — your marketing site, your app, a client's website — use a third-party service as the primary monitor. Save the cron-based check, if you use one at all, for a secondary sanity check or for internal tools nobody outside your team touches.

Setting up your first HTTP check

Setting up your first check comes down to four decisions: what URL to hit, how often, how long to wait before giving up, and what counts as "success." Get those four right and you have covered most of what matters.

Point the monitor at your homepage or, better, a dedicated health endpoint (more on that below) — not an admin login page or anything behind auth that will always fail the check. For the interval, 1-5 minutes is the right range for anything customer-facing; checking every 30 seconds mostly just burns through your plan's check quota faster without meaningfully improving detection time, while checking hourly means an outage can run most of a business day before anyone notices.

Set a timeout that reflects reality, not the tool's default. Many services default to something short, like 5-10 seconds, which is too aggressive for a page that legitimately takes a few seconds to render under load — you will get alerted for slowness that is not actually downtime. 10-30 seconds is a more realistic timeout for most WordPress and application sites; go shorter only once you have confirmed your page reliably responds fast.

Finally, and this is the detail people skip: require a specific expected status code, 200, rather than accepting "any response." A server throwing a 500 error, or a misconfigured proxy returning a 502, still sends back a response — just not the one you want. If your monitor is configured to treat "got something back" as success, a broken site can sit in an error state for hours while your monitor reports green the entire time.

Writing a lightweight health endpoint

Monitoring your homepage is not always enough, because a CDN or page cache can keep serving a stale 200 response even after the application behind it has broken. If Cloudflare, Varnish, or a WordPress caching plugin is serving a cached copy of your homepage, your uptime monitor will happily report "up" while the actual app — and the database it depends on — is completely unresponsive.

The fix is a dedicated health endpoint that bypasses the cache and actually exercises the part of the stack that tends to fail: the database connection. For a Node app, that is typically a route like /healthz that runs a real, if trivial, query. For a WordPress or plain PHP site, a small standalone PHP file that attempts a database connection and returns 200 only if it succeeds works just as well, and it is a five-minute job to add.

Here is a minimal version for a PHP/MySQL stack:

Point your monitor at this endpoint instead of, or in addition to, your homepage, and exclude it from any caching layer so every check hits the real application. This one change catches an entire category of outage — "the page loads but the app is actually broken" — that a homepage check alone will miss.

Getting alerted the right way

Email alone is the wrong primary channel for anything business-critical, because email is slow and easy to miss — it can sit in an inbox for twenty minutes before anyone glances at it, and by then you have already lost the response window and probably a few customers. For anything customer-facing, pair email with a faster channel: SMS, a phone call, or a Slack or Discord webhook that lands in a channel your team actually watches. Most uptime services support at least one of these natively; if yours only does email, that is worth switching for.

Just as important as the channel is the trigger condition. Do not alert on a single failed check. A dropped packet, a momentary network blip between the monitor's region and your server, or a few seconds of slowness during a deploy can all trigger one failed check without your site actually being down. Configure your monitor to require 2-3 consecutive failures — from the same or different regions, depending on the service — before it fires an alert. That small delay, usually a minute or two, is a worthwhile trade against waking your team up for a non-event, and most services let you tune it per monitor.

Avoiding false positives and your next step

The last piece is what happens after the alert fires — knowing what was actually happening on the server at that exact moment, not just that the site was unreachable. An uptime alert alone tells you "down," which is a start but not an explanation. You still have to open a terminal, pull logs, and check server metrics by hand to figure out why, and by the time you do that, the trail can be cold.

This is where CloudStick's Server Stats and Web Application Logs, available on every plan, do the correlation work for you. When an uptime alert comes in, you can pull up the CPU, memory, and disk graphs for that server and immediately see whether the outage lines up with a CPU spike, a memory exhaustion event, or a disk that filled up — then cross-reference that against the Web Application Logs to see the exact error the application was throwing at that timestamp. Instead of "the site was down for six minutes," you get "the site was down for six minutes because PHP-FPM ran out of workers during a traffic spike," which is the difference between guessing at a fix and actually applying one.

Set the monitor up before you need it, not after your first outage — a health endpoint, a sane interval and timeout, multi-channel alerts with a failure threshold, and a way to see what your server was actually doing at the moment things broke. That combination is what turns "the site went down" from a mystery into a five-minute diagnosis.