How to monitor your website's uptime

What an uptime monitor does

A website uptime monitor is a service that requests your website at a fixed interval, such as every five minutes, from a computer outside your hosting. If the page does not respond, responds with an error, or responds without the content it should contain, the monitor sends you an alert by email, SMS, an app notification or a chat message.

You need one because you are rarely the first to notice an outage. Without monitoring, the first sign is often a customer calling to say the order page will not load. With it, you know within minutes and have a timestamped record of what happened.

Why your host's uptime figure is not enough

Hosting plans list an uptime figure such as 99.9%. Our guide to hosting terms shows what that allows: about 43 minutes of downtime in a month. That figure is about the host's servers. It cannot tell you whether your site is working, because many outages come from the site itself: an expired domain, an SSL certificate that did not renew, a plugin update that broke the home page, or a full storage quota.

ODHOST note: Every ODHOST plan lists 99.9% uptime as the stated target. An independent monitor is still worth having, because it tells you when something specific to your site has broken and gives you exact times to include if you open a support ticket.

What to monitor

Start with five checks. Each catches a different kind of failure.

Check	What it catches	Example
HTTP check on the home page	Server down, 500 and 503 errors, timeouts	https://yourbusiness.in/ must return status 200
Keyword check on a key page	A page that loads but is broken or blank	/contact/ must contain your phone number
SSL certificate expiry	A certificate that failed to renew	Alert 14 days before expiry
Domain expiry	A domain about to lapse	Alert 30 days before the renewal date
Response time	A site that is up but very slow	Alert if responses take more than 5 seconds

A status code is the three digit number a server returns with every page: 200 means success, 301 and 302 are redirects, 4xx codes such as 404 are client errors and 5xx codes such as 500 or 503 are server errors, as listed on MDN. Make sure the monitor follows redirects to your final https:// address, or it may report the redirect itself as a problem.

For an online store, add a keyword check on a product page and on the cart, because those depend on the database and plugins, not only the web server.

Choosing a tool

Hosted monitoring services

The simplest option is a hosted service: you create an account, enter your URL and choose how to receive alerts. As observed in October 2026, UptimeRobot's free plan included 50 monitors at a five minute interval and was described as being for hobby and non profit projects, so read the terms for business use. Paid plans from most services add shorter intervals, SMS alerts and checks from several locations.

When comparing services, look for:

• Check interval on the plan you will actually use.
• Alert channels your team reads quickly, such as an app, SMS or WhatsApp through an integration.
• Confirmation from a second location before alerting, which cuts false alarms.
• Keyword and SSL checks, not only "is the server up".
• Logs you can export, so you can share them with your host or developer.

Self hosted monitoring

Developers often run Uptime Kuma, an open source monitoring tool you install yourself with Docker or Node.js. Its project page lists HTTP, keyword, TCP, ping and DNS monitors and many notification channels. Run it on a different server from the websites it watches, for example a small VPS for monitoring only, so it keeps working when your main server does not.

A simple script on a VPS

If you already have a Linux VPS, a cron job can check another site. This sends an email when the status code is not 200 (it needs a working mail command on the server):

#!/bin/sh
# check-site.sh: alert if the page does not return HTTP 200
URL="https://yourbusiness.in/"
CODE=$(curl -s -o /dev/null -w "%{http_code}" -L --max-time 15 "$URL")
if [ "$CODE" != "200" ]; then
  echo "$(date '+%F %T %Z') $URL returned $CODE" | mail -s "Website check failed" owner@yourbusiness.in
fi

Schedule it every five minutes with crontab -e:

*/5 * * * * /home/youruser/check-site.sh

A script is fine for one or two sites. For more, a proper tool with history and dashboards saves time.

Setting it up step by step

1. List the pages that matter: home page, contact or enquiry page, and for a store the product, cart and checkout pages.
2. Create an HTTP check for the home page using the full https:// address.
3. Add a keyword check on one key page, using text that only appears when the page works, such as your phone number.
4. Turn on SSL and domain expiry alerts with enough notice to act.
5. Choose alert contacts: at least two people, so a holiday does not leave the site unwatched.
6. Set the alert to trigger after two failed checks in a row, which avoids being woken by a single dropped request.
7. Test the setup by pointing a temporary monitor at a page that does not exist and confirming the alert arrives.

Checking expiry dates yourself

You can check certificate and domain dates from any terminal, which is useful when an alert seems wrong:

# When does the SSL certificate expire?
echo | openssl s_client -servername yourbusiness.in -connect yourbusiness.in:443 2>/dev/null | openssl x509 -noout -enddate

# When does the domain expire? (output format varies by registry)
whois yourbusiness.in | grep -i expir

If the certificate date has passed or is very close, see how SSL certificates work for how renewal normally happens.

What to do when an alert arrives

1. Confirm the problem. Open the site on mobile data and in a private browser window.
2. Read the monitor's log: the status code, the time and the location of the failed check.
3. Match the error to a cause. Our guide to common hosting errors explains what 500, 503, 403 and SSL errors usually mean.
4. Check recent changes: plugin or theme updates, new code, DNS edits or a renewal you may have missed.
5. Raise a ticket if the cause is not on your side. Include the URL, the exact times in IST, the status code, how long it lasted and a screenshot of the monitor log.

Avoid restarting things at random. A clear record of what failed and when is the fastest way to get a precise answer from your host or developer.

Reading your monitoring data over time

Review the monthly report rather than only reacting to alerts:

• Repeated short outages at the same time of day often point to a scheduled task, such as a backup or import, or to bot traffic at that hour.
• Rising response times suggest the site is outgrowing its plan or needs optimisation. See how to improve website speed.
• Outages only from one monitoring location often mean a regional network or DNS issue rather than your server.

Keep a few months of logs. They turn "the site keeps going down" into evidence you can act on.