Website uptime monitoring is a simple idea: check the website from outside your own network on a fixed schedule and alert somebody when it stops behaving as expected.
The useful part is not the green percentage in a dashboard. It is finding out about a real outage before customers do — and knowing whether the failure is the server, DNS, SSL, CDN, page content or a business-critical journey such as checkout.
Good uptime monitoring asks more than “Did the server return 200?”
A useful setup checks from outside the site, confirms the expected response, avoids false alarms, watches response time and SSL, and has a clear escalation path when something genuinely fails.
What is website uptime monitoring?
An uptime monitor sends an automated request to a website or endpoint every minute, five minutes or another chosen interval.
Each check usually asks:
- Can the domain be resolved?
- Can a connection be opened?
- Does HTTPS/TLS complete correctly?
- What HTTP status code is returned?
- How long does the response take?
- Does the response contain the expected content?
If enough checks fail, the system creates an incident and sends an alert.
Why monitoring from outside your server matters
Internal server dashboards tell you what the infrastructure believes is happening.
External monitoring tells you what a customer can actually reach.
A server can report healthy CPU and memory while visitors cannot access the site because of:
- DNS failure;
- expired SSL;
- CDN problem;
- load-balancer fault;
- routing issue;
- firewall rule;
- hosting outage.
What does a basic HTTP uptime check prove?
It proves surprisingly little.
If the homepage returns HTTP 200, you know that request reached something that responded successfully.
You do not necessarily know that:
- the correct page loaded;
- the database is healthy;
- the contact form works;
- checkout works;
- customers can log in;
- the site is fast enough to use.
Why a 200 OK can still be a failure
Some sites return 200 for:
- maintenance pages;
- generic error templates;
- blank content;
- application-level errors;
- cached pages while the database is unavailable.
A content or keyword check can improve this by confirming that an expected phrase is actually present in the response.
What should a business monitor?
1. Homepage availability
This is the simplest public-health check.
2. A key service or landing page
If the homepage is heavily cached, also monitor a representative deeper page.
3. SSL certificate
Alert before the certificate expires rather than after browsers start warning customers.
If a live site already shows a security warning, the expired SSL troubleshooting guide deals with that repair separately.
4. Response time
Track degradation as well as total downtime.
A site taking 15 seconds to respond is technically up and commercially close to unusable.
5. DNS
DNS monitoring can catch changes or failures that ordinary server-health checks miss.
6. Critical API or endpoint
Where the business depends on an API, status endpoint or webhook receiver, monitor that directly.
7. Business transactions
High-value websites may justify synthetic checks that simulate:
- login;
- form submission;
- booking;
- checkout.
That is more complex than a basic ping but catches failures a green homepage monitor cannot see.
How often should an uptime monitor check?
Check interval controls how quickly you can detect an outage.
| Interval | Typical use | Trade-off |
|---|---|---|
| 30–60 seconds | High-value transactional systems | Fast detection, more checks/noise if poorly configured |
| 1–5 minutes | Most business websites | Good balance |
| 10–15 minutes | Low-risk informational sites | Longer outages can go unnoticed |
What does 99.9% uptime actually mean?
Percentages can sound reassuring without context.
Roughly:
- 99% uptime allows about 7 hours 18 minutes of downtime in a month.
- 99.9% allows about 43 minutes.
- 99.99% allows about 4 minutes.
The business question is whether those outages happen at 3am on Sunday or during the busiest sales hour.
Why one failed check should not always create an incident
External networks occasionally fail.
A good monitoring setup may:
- retry the check;
- confirm from another location;
- require two or more failures;
- use a short confirmation delay.
This reduces false alarms without delaying genuine incidents too much.
Why multi-region monitoring matters
A monitor running from one location can confuse a regional network problem with a global outage.
Checking from multiple regions provides stronger evidence that the site itself is unavailable.
What is alert fatigue?
If a monitor sends dozens of false or low-value alerts, people stop trusting it.
Then the real alert arrives and gets ignored.
Reduce alert fatigue by defining:
- what counts as an incident;
- how many failures trigger it;
- which endpoints matter;
- which alerts wake someone up;
- which can wait until business hours.
Who should receive uptime alerts?
An alert must reach somebody who can act.
Depending on the business, that may be:
- site owner;
- web agency;
- hosting team;
- developer;
- IT support;
- on-call engineer.
Sending alerts to an unattended admin inbox is not monitoring in any operational sense.
What should happen after an alert?
Use a simple sequence.
1. Confirm the outage
Check from another connection or monitoring location.
2. Determine the scope
Is it:
- whole site;
- one page;
- one region;
- checkout only;
- DNS;
- SSL;
- hosting;
- CDN?
3. Check external status pages
Hosting, CDN, DNS and payment providers may already be reporting an incident.
4. Review recent changes
Updates, deployments and DNS changes are useful clues.
5. Inspect logs
Server and WordPress logs can identify 500 errors, memory exhaustion or application failures.
6. Escalate to the owner of the failing layer
If the problem is at the host, escalating to a designer wastes time. If it is a WordPress plugin fault, restarting DNS will not help.
What does a 502 or 504 alert mean?
These errors often point to upstream server or application communication problems.
The 502/504 WordPress troubleshooting guide covers those faults in detail rather than duplicating the repair process here.
Uptime monitoring is not performance monitoring
They overlap, but the questions are different.
Uptime: can I reach the site?
Performance: how quickly does it respond and render?
A website can have excellent uptime and terrible user experience.
Uptime monitoring is not form monitoring
A homepage can return 200 while a contact form silently fails.
The preventative contact form testing guide explains how to follow a test lead all the way through the business process.
Uptime monitoring is not checkout monitoring
A WooCommerce store may stay online while its payment gateway fails.
For ecommerce, combine availability checks with order/payment monitoring and regular controlled test transactions.
What is synthetic transaction monitoring?
Synthetic monitoring imitates a user action automatically.
A script might:
- open a page;
- enter test data;
- submit a form;
- confirm an expected response.
For complex businesses this can provide much stronger operational assurance than a simple homepage ping.
Should you monitor a WordPress admin URL?
Usually the public customer-facing routes are the priority.
Monitoring admin login publicly can create unnecessary noise or security concerns. If editor/admin availability is critical, use appropriate authenticated or infrastructure monitoring instead.
Does uptime affect SEO?
Short outages happen and search engines expect them.
Repeated or prolonged server errors can reduce crawl access and damage user experience. The operational goal should therefore be reliable service, not chasing a percentage purely because it sounds like a ranking factor.
How should planned maintenance be handled?
If a live site needs to be temporarily unavailable, use the correct response where possible.
For short maintenance, HTTP 503 signals temporary unavailability more appropriately than returning a permanent-looking error.
Should downtime alerts be paused during maintenance?
Yes, where the monitoring tool supports planned maintenance windows.
Otherwise everybody receives expected alerts and starts ignoring them.
What should an uptime report contain?
A useful report can show:
- availability percentage;
- incident count;
- incident duration;
- mean response time;
- slowest periods;
- root causes;
- time to acknowledge;
- time to restore.
What does an SLA percentage actually include?
Hosting providers may exclude:
- planned maintenance;
- customer configuration errors;
- third-party outages;
- DDoS;
- force-majeure events.
Read how the SLA is measured rather than treating the headline number as universal availability.
How much downtime costs a small business
The direct cost varies.
For ecommerce, it may be lost sales per minute.
For a local service business, the cost may be missed enquiries.
For a B2B site, one missed high-value lead can exceed months of monitoring cost.
That is how to decide how aggressive monitoring needs to be.
What should a small-business monitoring stack include?
Availability: homepage + one important endpoint.
SSL: certificate expiry.
Performance: response-time trend and periodic real-page tests.
Forms: controlled lead-path testing.
Ecommerce: checkout/payment signals and test orders.
Alerts: clear owner and escalation route.
Free monitoring vs paid monitoring
Free monitoring can be perfectly adequate for a straightforward website.
Paid services become more useful when you need:
- shorter intervals;
- multiple regions;
- SMS/phone alerts;
- transaction monitoring;
- status pages;
- team escalation;
- long retention;
- SLA reporting.
How Core Web UK uses monitoring
Our website maintenance and support service combines monitoring with the ability to investigate the alert rather than treating notification as the finished job.
If a site is already down, the emergency website fixes service is designed for active incidents.
Frequently asked questions
How often should a business website be checked?
One- to five-minute intervals are common. Higher-value transactional services may justify shorter intervals.
Can uptime monitoring detect a broken contact form?
Not with a simple HTTP check. Forms need functional or synthetic testing.
Does uptime monitoring slow a website down?
Normal lightweight HTTP monitoring has negligible impact when configured sensibly.
Should I monitor only the homepage?
The homepage is a useful baseline, but important deeper endpoints or customer journeys may need separate checks.
What uptime percentage is good?
99.9% is a common benchmark, but business impact, incident timing and recovery speed matter more than the percentage alone.
Can a site be “up” but unusable?
Yes. It may return 200 while checkout, forms, database functions or critical scripts are broken.
A green homepage check is a start. A trusted monitoring system tells you what failed, avoids false alarms and gets the alert to somebody who can restore the business service.
What does 99.9% uptime actually allow?
Uptime percentages sound more reassuring than they are until you turn them into minutes.
| Monthly uptime | Approximate downtime allowed in a 30-day month |
|---|---|
| 99% | About 7 hours 12 minutes |
| 99.9% | About 43 minutes |
| 99.99% | About 4 minutes |
This is why the right target depends on the business. A brochure site and a high-volume ecommerce store do not have the same tolerance for downtime.
How do you avoid alert fatigue?
One failed check should not always wake somebody up. Useful monitoring normally confirms the fault with another check or another region before escalating.
Set different alert rules for different failures. A complete outage may need an immediate call. A gradual response-time increase may belong in a warning queue. SSL expiry should be alerted days or weeks before it becomes an incident.
Monitor the business transaction, not only the homepage
For revenue-critical sites, consider synthetic checks that verify a login, basket, checkout step or key API response. A green homepage monitor cannot prove the part of the site that makes money is healthy.
