cPanelOps · Hosting guides for site operators
cPanelOpsv2.2.0
Plain-English cPanel help from the team behind FirstResponderHost
26 guides live
CpanelOps / PageOps

Home › Guides

Reliability

Uptime monitoring: know your site is down before your readers tell you

What to monitor, how to set up a check that catches real failures and ignores blips, and what to do when the alert arrives.

Sites rarely go down while you are looking at them. An expired certificate at midnight, a full disk on a holiday, a plugin update that breaks the front page: the first you hear of it is a message from a reader, hours later. An outside monitor that loads your site every few minutes and tells you when it fails closes that gap. Basic monitoring is free and takes ten minutes to set up.

Why the check must come from outside

A script on your own server cannot tell you the server is unreachable; it goes down with it. Monitoring has to run somewhere else. Several established services offer a free tier that checks a handful of addresses every five minutes and sends an email on failure, which is enough for a small site.

What to monitor

CheckWhat it catches
Home page returns 200Server down, DNS broken, account suspended, fatal error on the front page.
Home page contains a known phraseThe page loads but shows the wrong thing: a database error, a blank template, a hacked page, the host's default page.
A deep page, such as a recent articleBroken rewrite rules, where the home page works and everything else returns 404.
Certificate expiryA renewal that silently failed. Alerts you days ahead.
Domain expiryA lapsed registration, the most complete outage there is.
A key function, such as the sign-up form's addressThe feature that earns money being broken while the pages look fine.

The phrase check is the one people leave out, and it matters. A site showing "Error establishing a database connection" often still returns status 200 through a cache or proxy. Choose a few words that appear on the healthy page and nowhere on an error page, such as your site's tagline.

Settings that avoid false alarms

  • Interval: five minutes is a good default. One minute is rarely worth it for a small site.
  • Confirm before alerting: require two or three failed checks in a row, or a failure from more than one location. A single failed request is usually a blip on the network between the monitor and you.
  • Timeout: around 20 to 30 seconds. A page that takes that long is down as far as a visitor is concerned.
  • Recovery notice: turn it on, so you know when it came back without checking.

An alert that cries wolf gets muted, and a muted monitor is no monitor. Tune it until every alert is real.

Where alerts should go

Not only to a mailbox on the same domain you are monitoring. If the hosting account is down, its email is down too, and the alert has nowhere to land. Send alerts to an address at a separate provider, and to your phone by text or app notification if the service offers it. If someone else can act when you cannot, add them as well.

Make sure your own defences let the monitor in

A firewall, a bot challenge at a proxy, or a country block can turn the monitor away and produce a permanent false alarm. Monitoring services publish the addresses they check from; allow those. Test by pausing your site's page on purpose, for instance by renaming the index file for a few minutes, and confirming the alert arrives.

When the alert arrives

  1. Confirm it. Load the site on your phone using mobile data, not your home connection.
  2. Read the status code. It tells you where to look; the status code guide lists each.
  3. Check the host's status page. If the whole server is down there is nothing for you to fix, only to wait and tell readers.
  4. If it is only your site, open the error log and look at the last few lines. Then ask: what changed most recently? An update, an edited file, a new plugin. Undo that first.
  5. Tell people. A short post on your social page, saying the site is down and you are on it, stops the flood of messages and costs nothing.

Use the history

Monitors keep a record of every outage and of response times. Two uses for it:

  • Patterns. Brief outages at the same time every night point at a backup or scheduled job overloading the account.
  • Evidence. If the record shows frequent outages you did not cause, it is the basis for a conversation with your host, or for moving.

A slowly rising response time is also an early warning. It often shows a growing database or a failing cache weeks before anything actually breaks.

What monitoring will not tell you

It sees what a visitor with no account sees on the pages you listed. It does not notice a broken page you did not list, a problem that only affects signed-in users, or email that has stopped arriving. For those, a monthly five-minute walk through your own site, as a visitor would use it, is still worth doing.

Common questions

Will the monitor's visits distort my statistics or cost me bandwidth?

A check every five minutes is under 300 small requests a day, which is negligible. Analytics that rely on a script in the page do not count monitors, because monitors do not run scripts.

What is a realistic uptime figure?

Good shared hosting achieves around 99.9 percent, which still allows roughly 45 minutes of downtime a month. Short outages for maintenance are normal; repeated unexplained ones are not.

Should I have a public status page?

For most small sites a pinned post on a social page does the job. A status page is worth it once people depend on the site for work.

Spotted a mistake, or a step that has changed?

cPanel's screens differ a little between versions and hosts. Tell us at info@firstresponderhost.com and we will correct the guide.

More guides