Website Uptime Monitoring Tools

What an uptime check actually does

An uptime monitor requests your URL from somewhere outside your network, on a timer, and records what came back: the status code, the time it took, and whether the page contained the text it expected. When the answer is wrong, it alerts you. Nothing about it lives on your server, which is the point.

That distance is what makes the alert trustworthy. A plugin inside WordPress cannot report the failure when PHP is the thing that is down, and a check from your own laptop cannot tell a server fault from your broadband.

• Probe location: where the request came from. A monitor in Frankfurt says little about a visitor in Mumbai.
• Status code: 200 is healthy; 301, 403, 500 and a timeout are all failures of different kinds.
• Response time: a page that answers in nine seconds is up and still losing customers.

The three checks worth configuring

Most tools offer a dozen check types. Three justify the setup, and the rest are decoration until you have those in place.

1. HTTP status on the homepage and on one deep page, such as a product or contact page.
2. A keyword check on that deep page: the monitor looks for a phrase that only appears when the page rendered, so a 200 with a database error still fails.
3. SSL expiry on the domain, with a warning at 21 days, so a certificate does not lapse over a weekend.

Add a DNS check only if you change hosts often. Keep the list short: every extra check is another alert you have to decide about.

Choose an interval and an alert path

One minute is fine for a shop taking orders. Five minutes is enough for a brochure site. Below one minute, a monitor starts reporting your own CDN's hiccups as outages.

The alert path decides whether monitoring is worth anything. Email to a shared inbox is not an alert path; it is a record. Send to a phone, use the tool's SMS or push channel, and name the person who responds at 2 a.m. If nobody is named, the monitor only tells you what you find out at 9 a.m. anyway.

Hosted tools, self-hosted and what they cost

Hosted monitors are the default because they check from outside and need nothing installed. Sentry checks URLs every minute and ties an outage to the error trace behind it. Cronitor checks from more than a dozen locations and covers scheduled jobs as well as URLs. RunCloud's August 2026 comparison lists eleven tools with free tiers and paid plans, and each vendor prices on its own page, so no figure is repeated here.

A self-hosted monitor such as Uptime Kuma runs on your own VPS and costs whatever that machine costs. It gives you full control and one new thing to keep patched, and it cannot warn you when the machine hosting it goes down. Run two: one hosted, one self-hosted, on different networks.

Run a manual check from your own machine

Before you blame the host, get the status code and the time from a terminal. This works on macOS, Linux and Windows with curl installed.

1. Run curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://yourdomain.com/.
2. Read the pair: 200 0.842 means the page answered in under a second. 000 means the connection failed before a response.
3. Repeat against the server IP with a Host header to bypass DNS: curl -I http://SERVER-IP -H "Host: yourdomain.com".
4. Check DNS separately with dig +short yourdomain.com and compare it with the IP in cPanel.

If the terminal gets 200 and the monitor gets 403, the problem is between the monitor and your site, not in the site. That is the first thing to check before you email anyone.

Prove the alert fires before you trust it

An untested monitor is a dashboard, not an alert. Create a path that fails on purpose, point a check at it, and watch the whole chain.

1. Create a page or a redirect that returns a 500, or pause the site briefly on a staging domain.
2. Add that URL as a monitor with the same alert contacts as the real site.
3. Wait for one interval plus the tool's confirmation count, which is often two failed checks.
4. Confirm the alert reached the phone, not only the inbox.
5. Remove the test check, and write down who responds and what they do first.

WebJi® publishes its own cluster history on the network status page with 90 days of records. When your monitor says the site is down, check that page before you assume the fault is yours; if the cluster shows an incident, the answer is a support email with the timestamp.

The four causes of false alarms

Most "down" alerts are not outages. These four account for the majority, and each has a different fix.

• Bot protection: the monitor gets a 403 because a firewall or challenge page treats it as a bot. Allowlist the monitor's IPs.
• CDN and redirects: a 301 to a challenge or a country redirect reads as a failure. Follow redirects in the check, or check the final URL.
• Cache or maintenance mode: a purged cache or a plugin in maintenance mode returns 503 for a few minutes.
• DNS flapping: a recent nameserver change with a long TTL makes some probes see the old IP.

Read the response body the monitor recorded, not only the status. A 403 page naming a firewall tells you more in one line than an hour of guessing.

Reading the numbers: what 99.9% allows

A 99.9% target allows about 43 minutes of downtime in a 30-day month. A 99.95% target allows about 21 minutes. A 99.99% target allows roughly four minutes, which is shorter than most incident responses.

Those figures assume the monitor measures the same thing the promise measures. A host's uptime figure usually covers the network and the web server, not your plugin conflict or your expired certificate. When someone quotes a percentage, ask what was measured and from where.

Keep the monthly report. Three months of data tells you whether the problem is a recurring 3 a.m. backup window or a one-off migration.

When to email support

Email support@webji.services with the URL, the exact time including the timezone, the probe location and the status the monitor recorded. Support is 24/7 by email in Hindi and English, and the average first reply is under 60 minutes.

If the site is up for you and down for a monitor in another country, say so in the first line. It changes which log the desk reads. For anything about the account itself, contact reaches the same team.