Most businesses that buy monitoring start by monitoring the wrong thing. They set up a ping check on the company website, watch it stay green for a year, and conclude that monitoring is a solved problem. Then the payment gateway integration silently fails on a Thursday and nobody notices until the weekly reconciliation.
The gap is between “the server is responding” and “the business is working”. Here is a practical list of what belongs in the second category.
Start from revenue, not infrastructure
The useful question is not “what do we run?” but “what has to be working for us to take money and serve customers?” Trace that path end to end and monitor every step of it.
For a typical small business that path includes: the website loads, the enquiry or booking form actually submits and the submission arrives somewhere a human sees, payments process, order confirmations send, and staff can access the systems they need to fulfil the order. Any one of those failing stops the business, and only the first is covered by a basic uptime check.
Uptime checks: necessary but shallow
A standard HTTP check tells you the server returned a response. It does not tell you the response was correct. A site can return a perfectly healthy 200 status while displaying a database error, an empty product catalogue, or a checkout page with a broken payment button.
Content checks fix this cheaply. Instead of just confirming the page loads, confirm a specific string appears on it — the price, the “Add to cart” text, a footer element that only renders when the database is reachable. If that string disappears, something has broken that a status code would not have caught.
Transaction monitoring: the one most people skip
The highest-value check you can run is a synthetic transaction — an automated script that periodically walks through your critical flow the way a customer would. Load the page, fill the form, submit, confirm the success message.
This is the only check that catches the failure mode that costs the most: everything looks fine, and enquiries have quietly stopped arriving. Businesses discover this after two weeks of unusually quiet phones. A synthetic transaction catches it in fifteen minutes.
Certificates, domains and the slow-moving failures
Some outages are entirely predictable and still happen constantly. An expired TLS certificate produces a full-page browser warning that stops essentially all traffic. An expired domain takes everything down. Both have known dates.
Monitor certificate expiry with at least thirty days’ notice, domain expiry with sixty, and set the alerts to reach more than one person. These are the cheapest outages to prevent and among the most embarrassing to suffer.
Backups: monitor the restore, not the job
A backup job that reports success is not evidence of a recoverable backup. Monitor that backups are completing, that the file sizes are consistent with expectation — a backup that suddenly shrinks by 90 per cent is a failed backup reporting success — and that someone actually performs a test restore periodically.
Email deliverability, which almost nobody watches
Order confirmations, password resets and enquiry notifications are business-critical messages that fail silently. Nothing errors. The mail is simply accepted and then filtered, or rejected by a receiving server, and the only symptom is customers saying they never got anything.
This deserves its own attention because the causes sit outside your infrastructure — authentication records, sender reputation, a provider’s policy change. Businesses that depend on transactional mail benefit from treating email deliverability as a monitored service rather than assuming that sending equals arriving.
Getting the alerting right
Two failure modes to avoid. Alerting nobody in particular, where notifications go to a shared inbox and are everyone’s problem and therefore no one’s. And alerting too much, where the team learns to ignore the channel because it produces noise.
Route critical alerts to a named person with a defined backup, require confirmation from two checks before paging, and review the alert log monthly to remove anything that has never once been actionable.
Start with the revenue path. Add the predictable expiries. Then extend outward as you learn where your actual failures come from.