Uptime Monitoring: Know Before Your Customers Do
By CodexierPublished 7 min read
A website that is down at nine on a Monday morning loses the enquiries of the day, and a checkout that silently fails loses orders without anyone noticing until the numbers look wrong. Uptime monitoring is the cheapest insurance in web operations, and most small companies either do not have it or have it pointed at the wrong thing. This guide covers what to monitor, which tools to use, how to route alerts so they get acted on, and what to do after each incident.
What to monitor, not just the homepage
The homepage is the page least likely to break and the one every free monitor checks by default. The pages that matter are further in. A contact form depends on a mail service; a booking widget depends on a third-party script; a checkout depends on a payment provider, a shipping API and a database. Each of those can fail while the homepage smiles. So list the flows that produce revenue or enquiries and monitor the last step of each: the form's thank-you page, the booking confirmation, the checkout's payment step. Where a flow needs input, use a transaction check that submits a test form or adds a test product, and mark the test data so it does not pollute your orders.
| Check | What it catches | Interval |
|---|---|---|
| Homepage returns expected text | Server down, DNS broken, wrong site deployed | Every minute |
| Contact form submits and the thank-you page loads | Broken form plugin, mail service failure, spam filter blocking | Every 15 minutes |
| Checkout reaches the payment step with a test product | Payment provider outage, shipping API failure, broken theme update | Every 5 to 15 minutes |
| Login page accepts a test account | Auth provider outage, expired certificate, session store down | Every 5 minutes |
| SSL certificate validity | Expiry in the next 14 days | Daily |
| Domain expiry and DNS records | Renewal missed, records changed | Daily |
Test accounts and test products should be real records flagged as tests, so the check exercises the same code your customers use.
Free and paid monitoring tools
Free tiers from established monitoring services are enough for a simple site: a handful of checks, a few-minute interval, email and app alerts. Paid tiers add shorter intervals, transaction checks that click through a flow, more locations, SMS and phone alerts, and status pages. The features that justify paying are the transaction checks and the alert routing; the number of monitors rarely matters for a small business. What you should not do is rely on your hosting provider's own dashboard as the only monitor, because when the host has a problem, its dashboard often has the same problem. Use a service that runs from outside your host, in more than one location, so that one region's network issue does not wake you for nothing.
- Check from at least two locations and alert only when both fail, to avoid false alarms.
- Look for keyword or content matching, not only status codes.
- Prefer a tool with an incident timeline you can export; you will need it for the review.
- If you run a maintenance plan with an agency, ask what they monitor and how you get alerted too.
Alert routing and escalation
An alert that lands in a shared inbox is not an alert; it is a log entry. Decide who is on point for the site, how they are reached, and what happens if they do not respond. For most small companies that is one person by push notification and SMS during the day, with the agency or the host's support as the second step. Set an acknowledgement window of a few minutes; if nobody acknowledges, the alert goes to the next person. Silence alerts that are not actionable, such as a slow response that resolved itself, so the ones that arrive are always worth reading. Test the chain once a quarter by triggering a fake outage on a staging page.
Level 1: the site owner
Push and SMS, day and evening. Can check whether it is a host outage or a broken deployment, and can roll back a plugin update.
Level 2: the agency or developer
Reached automatically if level 1 does not acknowledge, or manually for anything that needs code. Response time set in the maintenance agreement.
Level 3: the host or provider
Support ticket with the monitor's evidence attached. Most outages at this level are already known; the ticket gets you the timeline.
Status pages
A status page is a separate page, hosted somewhere other than your site, that shows whether your services are up and lets customers subscribe to updates. For a B2B SaaS product or a webshop with a support team it saves hours of "is it just me?" emails during an incident, and it signals that someone is paying attention. For a local service business with a contact form it is usually unnecessary. If you set one up, keep it honest: components that reflect the real checks, incidents posted when they happen and updated when they resolve, and no green ticks on things nobody monitors.
Reviewing incidents
Every incident, including a five-minute blip, gets a short note: when it started, when it was detected, when it was resolved, what caused it and what would have prevented it. The gap between start and detection is your monitoring's quality; the gap between detection and resolution is your response chain's quality. After a few months the notes show the pattern: a plugin that breaks on every update, a host that drops out on Sunday nights, a form service that rate-limits you at month end. Each pattern is a fix that removes a category of incident, which is far cheaper than responding to it forever.
When you do not need any of this: a brochure site with no forms, where a day of downtime costs you a phone call you would have received anyway, can live with a free homepage check and an email alert. Where monitoring earns its cost is on any site that takes enquiries, bookings or payments, and that is what is built into our monthly maintenance package together with updates, backups and a response time. Pair it with the quarterly website health check you can run yourself. What your site needs is a 15-minute conversation.
- Monthly maintenance packageMonitoring of the flows that matter, alerting to us and to you, updates, backups and a response time.
- Website health check you can run yourselfThe quarterly checks that catch what a monitor does not.
- Book a free 15-minute callTell us which pages make you money; we tell you what to monitor and who should be alerted.
Frequently asked questions
How often should uptime checks run?
Every minute for the homepage and every five to fifteen minutes for transaction checks such as forms and checkout. Shorter intervals find problems faster but cost more and create more noise; what matters is that the important flows are checked at all.
Will monitoring slow down my website?
No. A check is one request every minute or so, which is nothing compared with a single visitor's page load. Transaction checks that submit forms should use flagged test data so they do not create real enquiries or orders.
What is a good uptime target for a small business site?
Any target is meaningless without monitoring to measure it. In practice, a well-hosted site with a maintenance routine sees a few short incidents a year, mostly from plugin updates or host maintenance. The useful measure is time to detect and time to resolve, which monitoring and a response chain directly improve.
Our agency says they monitor the site. Is that enough?
Ask what they monitor, from where, and who gets alerted at what time of day. If the answer is the homepage during office hours, add your own checks on the forms and checkout and route the alerts to yourself as well. Two monitors are cheap; one blind spot is not.
Not sure whether anyone would notice if your checkout broke tonight?
Fifteen minutes with an engineer: we map the flows that bring you enquiries and orders, and tell you what to monitor, at what interval and who should be woken up.
Book a free 15-minute call