TL;DR: Your host's status page reports the health of their infrastructure, not your website. Your server can be running perfectly while your site is broken, and in that situation the status page shows green, which is accurate and useless.
A basic ping check is barely better. It confirms something answered on port 443, which is compatible with a database connection error, a white screen, an expired certificate, a checkout that times out, and a site serving spam pages to search engines. The monitoring worth having checks that the thing your business depends on still works, from outside your own infrastructure, with alerts that reach a person who can act.
What a status page actually tells you
Worth being precise, because the gap between what it reports and what you assume it reports is large.
A hosting provider's status page reports incidents affecting their infrastructure: a data centre problem, a network event, a platform-wide outage, planned maintenance. It is a communication tool for events affecting many customers at once.
What it does not cover:
Your account being throttled for exceeding resource limits, which is the platform working as designed.
Your site being down because of a plugin update, a PHP fatal error, or a broken database connection.
Your certificate expiring.
Your DNS being misconfigured.
Your account being suspended, which is an action rather than an incident.
Your site serving errors to visitors while the server responds normally.
The asymmetry that matters: the status page is green during the large majority of outages that affect an individual site, because those outages are yours rather than theirs. Provider-level incidents are the minority of the downtime a typical small business experiences.
A second limitation: status pages are updated by humans and frequently lag the incident. If you are checking one to find out whether a problem is yours or theirs, the absence of an entry does not answer the question.
What it is genuinely useful for: confirming a suspected platform-wide event, and reading planned maintenance windows. Both worth checking. Neither is monitoring.
Why a ping check is not monitoring
The default free monitoring most people set up, and what it actually verifies.
A basic uptime check requests your homepage every few minutes and alerts if it does not receive a successful response. That confirms one thing: something answered.
States that produce a successful response while your site is broken:
A WordPress database connection error page, which returns content and may return a 200 status depending on configuration.
A maintenance mode page left in place after a failed update.
A cached homepage served while PHP is completely down, which is common on well-cached sites and genuinely confusing when it happens.
A site with a broken layout, missing images or a fatal error confined to interior pages.
A store where the homepage loads and checkout times out.
A compromised site serving spam pages conditionally to search engines while looking normal to a direct request.
States a homepage check misses entirely: email not sending, cron jobs stopped, backups failing, gateway callbacks blocked, admin inaccessible, and search visibility problems.
The characteristic these share: the business is impaired and the check is satisfied. Which means the monitoring reports availability you do not have and creates confidence rather than information.
The upgrade that matters most: check a page that exercises PHP and the database rather than a static asset or a fully cached homepage, and verify the response contains expected content rather than merely arriving.
The outages that pass every basic check
Concrete failures worth designing monitoring around, because each has caught real businesses out.
PHP down, cache serving. Your caching layer serves stored pages while PHP-FPM is dead. Anonymous visitors see the site; nobody can log in, check out, or submit anything. A homepage check reports perfect uptime for hours.
Certificate expired. The server responds; browsers show a full-page warning that stops nearly all traffic. Some monitoring tools follow the connection regardless and report success.
Checkout broken. Homepage and product pages fine, payment step failing. Revenue is zero and availability is 100%.
Gateway callbacks blocked. Payment succeeds, order never records. Nothing about the site is down, and you find out from customers, as covered in the rate limiting guide.
Email stopped. Order confirmations, password resets and contact form notifications not sending. Entirely invisible from the website.
Cron stopped. Scheduled tasks including backups quietly not running. Discovered when you need a backup.
Backups failing. The most expensive silent failure, since the loss only materialises at the worst moment.
Search visibility lost. A noindex left on after staging work, a robots.txt change, or a compromise serving spam to crawlers. Traffic decays over weeks and no availability check notices.
Account approaching resource limits. Not an outage yet, and the warning you could act on before it becomes one.
The pattern: these are business-function failures rather than server failures, and monitoring built around server availability cannot see them.
What to monitor instead
Building coverage that matches how your business actually fails.
A page that exercises the stack. Not a static file, not a fully cached homepage. Something that runs PHP and queries the database, and verify the response contains expected text rather than just returning successfully.
Your critical user journey. For a store, that means reaching checkout, not just the homepage. Synthetic transaction monitoring that walks add-to-cart and checkout catches the failure that costs money, and it is the single highest-value check a store can run.
Certificate expiry, independently of your issuance automation. Automation handles the normal case; monitoring catches the day it silently stops, as the SSL error guide discusses.
Response time, not just availability. A site taking eight seconds is failing commercially while passing every up-or-down check. Alert on degradation, not only on outage.
Disk space, with an alert at 80%. Full disks cause database failures and are entirely predictable.
Memory and resource utilisation trends. Approaching a ceiling is actionable; hitting it is an outage.
Backup success, actively. A backup job that reports failure to a log nobody reads is not monitored.
Cron execution, via a heartbeat: your scheduled job pings a monitoring endpoint on completion, and the absence of that ping raises an alert. This is the only reliable way to detect a task that stopped running.
Email deliverability, at minimum a periodic test send verifying authentication passes.
Domain expiry. Prosaic, and domains lapse and take everything down.
Search Console coverage, checked rather than monitored, for indexing problems that availability checks cannot see.
Monitoring types and what each catches
| Check type | What it verifies | Catches | Misses |
|---|---|---|---|
| Host status page | Provider infrastructure | Platform-wide incidents | Everything specific to your site |
| Ping or port check | Server reachable | Total server failure | Almost everything else |
| Homepage HTTP check | Something responded | Hard outages | Cached pages while PHP is down |
| Content-match check | Expected text present | Error pages, blank output | Failures on other pages |
| Dynamic page check | PHP and database working | Database errors, PHP failures | Checkout-specific problems |
| Synthetic transaction | Full user journey | Broken checkout, forms | Backend jobs |
| Certificate monitor | Expiry approaching | Renewal automation failure | Chain problems on mobile |
| Response time monitor | Performance degradation | Slow-but-up conditions | Functional errors |
| Cron heartbeat | Scheduled jobs ran | Stopped tasks, failed backups | Job succeeded but did nothing |
| Disk and resource alerts | Capacity headroom | Predictable capacity outages | Application faults |
| Email test send | Deliverability and auth | Mail configuration breakage | Reputation decay over time |
Where the monitoring itself must live
An architectural point that invalidates a common setup.
Monitoring hosted on the server it monitors reports nothing when that server fails. This sounds obvious and is a genuinely frequent mistake, particularly among people who self-host a monitoring tool and put it on the same VPS as everything else.
The requirement: checks must originate outside the infrastructure being checked. A hosted monitoring service, or a self-hosted tool on a separate small instance at a different provider.
Also outside your own network. A check running from your office tells you the site is reachable from your office.
Multiple check locations matter if your audience is geographically spread, since a routing problem can make a site unreachable from one region while it works from another. For an India-focused site, at least one Indian check location is the meaningful one.
Avoid false positives from a single location. A brief network problem at your monitoring provider's location produces an alert about your site. Requiring confirmation from a second location before alerting reduces noise considerably, and noise is what makes people ignore alerts.
A note on self-hosting monitoring: it is cheap and capable, and it must live somewhere other than the infrastructure it watches. If you self-host monitoring for a set of servers, that instance needs its own external check, because monitoring that dies silently is worse than none.
Redundancy is proportionate. A small business does not need two monitoring providers. It does need one that is genuinely independent of the thing being monitored.
Alerting people will actually act on
The half of monitoring that determines whether any of it matters.
Alerts must reach a phone. Email to an address checked during working hours means a 2am outage is discovered at 9am. If the outage matters, the alert needs to be intrusive.
Alert on the right things. An alert for every transient blip trains people to ignore alerts, which is worse than no alerting because it creates false confidence. Require a failure to persist across two checks, or confirmation from a second location.
Different severities to different channels. Site down goes to a phone. Disk at 80% goes to email. Response time degraded goes to a dashboard. Treating everything as urgent means nothing is.
A named person and a named backup, with the access and knowledge to act. An alert reaching someone who cannot fix it is a notification, not a response.
Recovery notifications, so you know when it resolved and how long it lasted without watching manually.
A written runbook for the common cases: what to check first, how to restart services, who to contact at the host, where the backups are. Written before the incident, because the middle of one is a poor time to be deciding.
Test the alerting. Deliberately trigger an alert once and confirm it arrives, on the right channel, to the right person. Untested alerting fails silently, which is the theme of this article.
Review alert history monthly. Repeated alerts you keep dismissing indicate either a real recurring problem or a badly tuned threshold. Both warrant action.
The things nobody monitors and should
The gaps that persist even in reasonably monitored setups.
Backup success. Everyone has backups; very few monitor whether the last one succeeded. A backup plugin silently failing for four months is common, and the dashboard shows green because nothing checks the outcome.
Cron execution. Heartbeat monitoring is the fix, and almost nobody implements it. Scheduled tasks stop for mundane reasons and nothing announces it.
Certificate expiry, independently. Automated renewal removes the routine risk; monitoring catches the failure of the automation itself.
Domain expiry. Auto-renew fails when a card expires, and the notification goes to an address nobody reads.
Gateway callback success. For a store, an alert when no orders have recorded in an unusually long window catches a callback failure that produces no error anywhere else.
Search Console coverage errors, which detect indexing problems and, occasionally, a compromise.
Disk usage on a VPS, which is the most predictable outage cause available and is rarely alerted on.
Log retention itself, since a log rotation misconfiguration silently discards the evidence you would need to investigate anything, as the breach playbook explains.
Third-party dependencies. If your checkout depends on an external service, its outage is your outage regardless of your own health.
The common thread: each of these fails silently and is only discovered when you need the thing that stopped working. Monitoring exists precisely to convert silent failures into noisy ones.
A proportionate setup
What a small Indian business should actually implement, in order of value.
One external HTTP check with content matching, hitting a page that exercises PHP and the database, from an Indian location, every few minutes. Alerts to a phone. This is the baseline and takes ten minutes.
Certificate expiry monitoring, independent of your renewal automation.
Disk space alert at 80% if you are on a VPS.
Backup success monitoring. If your backup tool can email on failure, point it at an address someone reads. Better, use a heartbeat so the absence of a success signal alerts you.
Cron heartbeats for anything important, particularly backups.
Response time tracking, alerting on sustained degradation rather than single slow checks.
For a store, synthetic checkout monitoring. This costs more than a basic check and it watches the thing that generates revenue, which makes it the highest-value addition on this list.
A periodic email test, confirming send and authentication.
Domain expiry in your calendar, since it is not really monitoring but it belongs on the list.
A one-page runbook and a tested alert path.
What to skip: elaborate observability platforms for a five-page site, dashboards nobody looks at, and monitoring so noisy that alerts get muted. The goal is a small number of checks that reliably tell you when something a customer would notice has broken, reaching someone who can act.
FAQs
Is my host's status page enough to know if my site is down?
No. It reports incidents affecting the provider's infrastructure, not your individual site. The large majority of outages a small business experiences — plugin failures, expired certificates, resource throttling, database errors, account suspension — leave the status page green because they are yours rather than theirs.
Why does my uptime monitor say the site is up when it is broken?
Because a basic check confirms only that something responded. A cached homepage can be served while PHP is completely down, a database error page returns content, and a store can have a working homepage with a broken checkout. Check a page that exercises PHP and the database, and verify expected content is present.
What should I actually monitor on my website?
A dynamic page with content matching rather than a static asset, your critical user journey such as checkout, certificate expiry independently of renewal automation, response time degradation, disk space, backup success, and cron execution via heartbeats. Each of these catches a failure class that simple availability checks miss.
Can I run monitoring on my own server?
Only if it monitors something else. Monitoring hosted on the server it watches reports nothing when that server fails, which is a common and self-defeating setup. Use a hosted service, or self-host on a separate small instance at a different provider, and give that instance its own external check.
How do I monitor whether my backups are working?
Use a heartbeat: your backup job pings a monitoring endpoint on successful completion, and the absence of that ping raises an alert. Relying on the backup tool to email on failure is weaker, since a job that stops running entirely may never send anything. Silent backup failure over months is common.
What is a cron heartbeat?
A monitoring pattern where a scheduled task sends a signal to a monitoring service each time it completes successfully. The monitor alerts when the expected signal does not arrive within a defined window. It is the only reliable way to detect a scheduled job that has stopped running, since a stopped job produces no error anywhere.
Should I monitor checkout separately from my homepage?
For a store, yes, and it is the highest-value check available. Cart and checkout cannot be page-cached, so they fail independently of your homepage, and a store with a working homepage and a broken checkout has zero revenue and one hundred per cent measured uptime.
How often should my monitoring check my site?
Every one to five minutes is reasonable for the main availability check. More frequent adds little for a small business and increases the chance of transient false positives. What matters more than frequency is requiring confirmation before alerting, so a momentary network blip does not wake anyone.
How do I avoid alert fatigue?
Require a failure to persist across two checks or be confirmed from a second location before alerting. Route different severities to different channels, with only genuine outages reaching a phone. Review alert history monthly, since repeated alerts that get dismissed indicate either a real recurring problem or a badly tuned threshold.
Does monitoring need to check from India?
If your audience is Indian, at least one Indian check location is worth having, since a routing problem can make a site unreachable from one region while it works elsewhere. Checks from a single distant location can also produce false positives from network conditions unrelated to your site.
What should I do when an alert fires?
Follow a runbook written beforehand: what to check first, how to restart services, who to contact at the host, where backups are. The middle of an incident is a poor time to be deciding these things, and a one-page document turns a stressful hour into a sequence of steps someone else could follow.
How do I know my alerting actually works?
Trigger one deliberately and confirm it arrives, on the right channel, to the right person, within a reasonable time. Untested alerting is the same class of problem as untested backups: it appears to be working right up until the moment it needed to, and by then you have lost the thing it was protecting.
Conclusion
The gap that catches people is between "the server is running" and "the business is working." Almost all default monitoring measures the first and almost all real outages happen in the second.
Your host's status page is green during most of your downtime, because most of your downtime is yours. A homepage ping is satisfied by a cached page served while PHP is dead, by a database error page, and by a store whose checkout has been broken since Tuesday.
So build monitoring around function rather than availability. A page that exercises PHP and the database, with content matching so an error page does not count as success. For a store, a synthetic checkout run, which is the single most valuable check available because it watches the thing that makes money.
Then close the silent-failure gaps, which is where the real damage accumulates. Backup success, verified actively rather than assumed. Cron heartbeats, because a stopped scheduled task announces nothing. Certificate expiry, independently of the automation that normally handles it.
Put the monitoring somewhere other than the thing it monitors. This is obvious and it is a genuinely common mistake.
And test the alert path once, deliberately, while nothing is wrong. Untested alerting belongs in the same category as untested backups: it looks fine until the moment you needed it, and by then the thing it was protecting is already gone.
HostCloud runs Indian infrastructure with resource usage visible in the control panel, error log access and automated backups you can restore yourself — which covers the diagnosis side once your monitoring tells you something is wrong. Plans from ₹99 a month at https://www.hostcloud.in.