Website Uptime Monitoring Tools
Website uptime monitoring means an outside service requests your URL every one to five minutes and alerts you when the response is wrong. Set up three checks first — HTTP status, a keyword on a deep page and SSL expiry — then test the alert with a deliberately failing URL before relying on it.
A setup guide for site owners and developers who want an alert they can trust and a quick way to tell a host fault from a local one.
knowledge
- Read time
- 6 min
- Sections
- 10
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026.
What does a website uptime monitor actually check?
A website uptime monitor sends a request to your URL from a server outside your network, on a fixed timer, and records the status code, the response time and whether the expected text came back. When any of those is wrong for long enough, it sends an alert. Nothing is installed on your own server, and that separation is the whole point.
A plugin inside WordPress cannot report an outage when PHP itself has stopped, and a check from your office laptop cannot tell a server fault from a broadband fault. An outside probe sees what a visitor sees. If the terms are new, what uptime means and how it is counted covers the basics.
- Probe location: where the request starts. A probe in Frankfurt says little about a visitor in Mumbai, so pick at least one location in or near India.
- Status code: 200 is healthy. A 403, 500, 503 or a timeout are each a different kind of failure; HTTP status codes explained lists what each one means.
- Response time: a page that answers in nine seconds is technically up and still losing orders.
Which three uptime checks should you configure first?
Configure an HTTP status check, a keyword check on a deep page and an SSL expiry check; together they catch most real failures. Monitoring tools offer a dozen check types, but every extra check is another alert someone has to judge, so start with these and add more only for a reason.
| Check | What it catches | Suggested setting |
|---|---|---|
| HTTP status | Server down, web server crashed, 5xx errors | Homepage plus one product or contact page |
| Keyword on a deep page | A 200 response that is really a database error or blank page | A phrase that only appears when the page fully renders |
| SSL expiry | A certificate that lapses over a weekend | Warn at 21 days before expiry |
The keyword check is the one most site owners skip and the one that matters most for WordPress and WooCommerce. A broken database connection often still returns a page with status 200, so a status-only monitor reports "up" while customers see an error. Add a DNS check only if you change hosts or nameservers often.
How often should the monitor run, and who should get the alert?
Check every one minute for a site that takes orders and every five minutes for a brochure site, and send the alert to a phone that a named person carries. Intervals below one minute start reporting normal CDN and DNS jitter as outages, which trains people to ignore the alerts.
The alert path decides whether monitoring is worth anything. Email to a shared inbox is a record, not an alert. Use the tool's SMS, push or messaging channel, and write down who responds at 2 a.m. If nobody is named, the monitor only tells you at 9 a.m. what a customer already told you.
Most tools also ask for a confirmation count: how many failed checks in a row before an alert goes out. Two is a sensible default. It filters a single dropped packet without hiding a real outage for long.
Hosted or self-hosted uptime monitoring tools?
Start with a hosted monitor because it checks from outside your network and needs nothing installed; add a self-hosted one later if you want full control. Sentry checks URLs every minute and links an outage to the error trace behind it. Cronitor probes from more than a dozen locations and also watches scheduled jobs. RunCloud's August 2026 comparison lists eleven tools with free tiers; each vendor prices on its own page, so no figure is repeated here.
| Attribute | Hosted (Sentry, Cronitor and similar) | Self-hosted (Uptime Kuma and similar) |
|---|---|---|
| Setup | Sign up and add a URL | Install on a server you maintain |
| Probe locations | Several countries, chosen by the vendor | Wherever your server sits |
| Cost | Free tier, then the vendor's plans | The cost of the machine it runs on |
| Blind spot | Limited checks and channels on free tiers | Cannot warn you if its own server goes down |
Uptime Kuma runs comfortably on a small VPS, but it gives you one more machine to patch. The reliable pattern is two monitors on different networks: one hosted, one self-hosted, each watching the other's blind spot.
How do you check uptime manually from a terminal?
Use curl to read the status code and response time, then repeat the request against the server IP to rule out DNS. These commands work on macOS, Linux and Windows 10 or later, where curl ships with the system.
- Get the status and total time:
curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://yourdomain.com/ - Read the pair.
200 0.842means the page answered in under a second.000means the connection failed before any response. - Bypass DNS and hit the server directly over HTTPS:
curl -sI --resolve yourdomain.com:443:SERVER-IP https://yourdomain.com/ - Check what DNS returns with
dig +short yourdomain.comand compare it with the IP shown in your hosting panel.
The --resolve flag keeps the correct certificate name, so it gives a cleaner answer than sending a plain HTTP request to the IP with a Host header. If the terminal gets 200 and the monitor gets 403, the problem sits between the monitor and your site, not in the site.
How do you prove the uptime alert fires before an outage?
Point a monitor at a URL that fails on purpose and confirm the alert reaches a phone; an untested monitor is a dashboard, not an alert. The whole test takes about ten minutes and is the step most setups never do.
- Create a test path that returns a 500, or pause a staging copy of the site.
- Add that URL as a check with the same alert contacts as the live site.
- Wait one interval plus the confirmation count, often two failed checks.
- Confirm the alert arrived on the phone, not only in the inbox.
- Delete the test check, and write down who responds and what they do first.
Why do uptime monitors raise false alarms?
Most "site down" alerts that are not real outages come from four causes: bot protection, redirects, cache or maintenance mode, and DNS changes. Each has a different fix, and the response body the monitor recorded usually names the cause in one line.
| Cause | What the monitor sees | Fix |
|---|---|---|
| Firewall or bot challenge | 403 or a challenge page | Allowlist the monitor's published IP ranges |
| CDN or country redirect | 301 or 302 treated as failure | Follow redirects, or monitor the final URL |
| Cache purge or maintenance plugin | 503 for a few minutes | Pause the monitor during planned work |
| Recent nameserver change | Some probes reach the old IP | Wait out the TTL before judging the alerts |
When the alert is real, the next steps are in what to do when your website is down. WebJi® publishes its cluster history on the network status page with 90 days of records, so check it before assuming the fault is in your own code.
What does 99.9% uptime allow per month?
A 99.9% uptime target allows about 43 minutes of downtime in a 30-day month. A 30-day month has 43,200 minutes, and 0.1% of that is 43.2 minutes; each extra nine cuts the allowance roughly tenfold.
| Uptime target | Downtime allowed |
|---|---|
| 99.0% | 7 hours 12 minutes |
| 99.9% | About 43 minutes |
| 99.95% | About 22 minutes |
| 99.99% | About 4 minutes |
The figures only compare fairly when the monitor measures what the promise measures. A host's target usually covers the network and web server, not a plugin conflict or an expired certificate; the cloud server SLA guide explains how to read that fine print. Keep three months of reports: they show whether the problem is a recurring 3 a.m. backup window or a one-off.
If your monitor and the status page disagree, email support@webji.services with the URL, the exact time with timezone, the probe location and the status code recorded. Support runs 24/7 in Hindi and English with an average first reply under 60 minutes, and saying "up for me, down from abroad" in the first line tells the desk which log to read.
Frequently asked questions
Are free uptime monitoring plans good enough for a small business site?
Often, yes. A free tier usually covers a single URL at a five-minute interval with email alerts. The limits that matter are the number of checks and whether you get a phone alert channel, not the price itself.
Can a WordPress uptime plugin replace an external monitor?
No. A plugin runs inside the site it is watching, so when PHP, the database or the server fails, the plugin fails with it and sends nothing. Use an outside monitor; a plugin is only useful for logging events while the site is running.
Should I monitor from a probe in India?
Yes, if most visitors are Indian. A probe in Europe or the US can miss routing problems that only affect Indian networks, or report problems that Indian visitors never see. Add at least one Asian location alongside the default ones.
Does uptime monitoring also track SSL certificate expiry?
Most tools offer it as a separate check type that you must switch on. Set the warning at about 21 days so a failed auto-renewal leaves time to fix it. WebJi® sells SSL certificates if you need a paid one instead of an auto-renewing free certificate.
Last editorial update: 14 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.