A client once showed me their monitoring dashboard with evident pride. Everything green. No alerts in weeks. They wanted to know why their checkout conversion rate had been quietly declining for the same period.
We looked at the logs. Their payment gateway was responding — technically. But response times had crept up from 400 milliseconds to over three seconds on mobile connections. The uptime check showed it as "up" because it was returning a 200 response. Nobody had defined "slow" as a failure condition. Nobody was watching for it.
This is the monitoring gap I see most often in small and medium businesses: they have a system that tells them whether their server is breathing, and nothing that tells them whether their users are actually able to do what they came to do.
What Does Uptime Monitoring Actually Measure?
Uptime monitoring, in its basic form, checks whether a URL returns a successful response — typically a 200 HTTP status code — at regular intervals. If it does, the check passes. If it doesn't, an alert fires.
That is genuinely useful. But it covers only one failure mode: the server being completely unreachable. It does not catch any of the following:
- The server responds, but slowly enough to cause users to abandon
- The page loads, but a critical third-party script — a payment form, a booking widget, an authentication service — is failing
- An SSL certificate has expired (browsers show a security warning; your uptime checker ignores it)
- An API your software depends on is returning incorrect data rather than an error code
- A specific user journey — login, checkout, form submission — is broken even though the homepage loads fine
A business can have 100% uptime and simultaneously be losing customers, revenue, and trust, because the thing users actually need to do is failing in ways the uptime check cannot see.
Response Time Is a Reliability Signal
Slow is a kind of broken. Users abandon slow pages. Conversions drop. And unlike a hard outage, slow performance often goes undetected for weeks because no alert fires.
Most web performance research puts the threshold for user abandonment somewhere between two and three seconds for mobile users. If your checkout page is loading in 2.8 seconds on a good day and 4.5 seconds on a busy day, that is a reliability problem — even if it never triggers an uptime alert.
What to track:
- Response time, not just up/down status
- Response time trends over time, not just spot checks
- Performance from multiple geographic locations, not just from a single monitoring server
Response time thresholds differ by page type. A marketing homepage can tolerate slightly more latency than a checkout form. Define your own thresholds — and alert when you breach them consistently, not just once.
Third-Party Dependencies Are Your Problem Too
Your system is not just your servers. Every external service your product touches — payment processors, email delivery platforms, mapping APIs, authentication providers, CDN networks — is a potential point of failure you do not control.
When a third-party service goes down or degrades, your users experience that as your product failing.
This matters for monitoring because most businesses only watch their own infrastructure. A payment gateway taking eight seconds to respond reads as your checkout being slow. A CDN misconfiguration causing images to fail shows up as your product looking broken. Your uptime check won't catch any of it, because your server is responding fine.
The practical fix: identify your critical third-party dependencies — the ones that, if they fail, prevent users from completing a core action — and monitor them explicitly. Many monitoring tools let you check external endpoints alongside your own. If your payment provider has a status page, subscribe to it. That is not the same as automated monitoring, but it is better than finding out from a customer complaint.
What About SSL Certificates?
An expired SSL certificate is one of the most preventable causes of a site going down, and one of the most common. When a certificate expires, browsers show a security warning instead of your site. Users see a red lock and a scary message. Most leave immediately. Depending on your setup, some users may not even be able to reach your site at all.
Certificates expire on a fixed schedule — typically one to two years for manually managed certificates, or 90 days for Let's Encrypt certificates. Renewal can be automated, but automation fails. A server rebuild, a misconfiguration, a DNS change — any of these can interrupt renewal without anyone noticing until the certificate actually expires.
Monitoring certificate expiry is simple: check the certificate's expiry date and alert when it falls below a threshold — 30 days is a reasonable minimum, 60 days gives you more time to investigate if the renewal is not working automatically. This is a one-time setup that prevents an entirely avoidable outage.
End-to-End Journey Testing
The most valuable — and least commonly implemented — form of monitoring is checking whether a critical user journey completes successfully, not just whether individual pages load.
End-to-end monitoring simulates a real user action and verifies the entire flow works as expected. This might mean scripting a synthetic login flow, a test purchase, or a form submission, and running it every few minutes against your production environment.
This catches failures that page-level checks completely miss: a login button that no longer submits, a checkout flow that errors on the payment step, a form that appears to submit but silently fails in the backend. These are the failures that hurt most because they directly block the actions users came to take — and they can persist for hours before anyone notices.
Synthetic monitoring tools have made this more accessible in recent years. The setup is more involved than a simple URL check, but for a business that depends on a web application to generate revenue, it is worth it. Start with your one or two most critical flows — the paths that, if broken, immediately cost you money — and work outward from there.
The Problem With Alert Fatigue
A monitoring setup that alerts on everything is not better than one that alerts on nothing. Alert fatigue is real: when alerts fire constantly for low-priority events, the people responsible for responding start to ignore them, and the alert that genuinely matters gets missed.
Good monitoring sends fewer, higher-quality alerts — ones that require action and tell you what that action should be.
A few principles:
- Alert on conditions that require a human response, not on every anomaly
- Give alerts context: what failed, how long it has been failing, what the likely impact is
- Route different alert types to different channels — a certificate expiring in 30 days is a task, not an emergency; a checkout page returning errors is an emergency
- Review your alert thresholds regularly; the right threshold for a new system is not the same as the right threshold for a mature one
What a Basic Monitoring Stack Looks Like
If you are starting from scratch or reviewing what you have, here is a reasonable baseline for most small and medium businesses:
- Uptime and response time checks on all customer-facing pages and key API endpoints, from multiple locations
- SSL certificate expiry monitoring with alerts at 60 and 30 days before expiry
- Third-party dependency checks on the external services your core flows depend on
- Synthetic transaction monitoring on your one or two most critical user journeys
- Alert routing with clear escalation paths and severity levels
You do not need enterprise-grade tooling to cover all of this. The important thing is actually covering it, rather than treating a basic uptime check as a complete monitoring solution.
This is part of the problem that PingPatrol was built to address — giving businesses clear visibility into whether their systems are actually working, not just whether they're technically online.
If you are reviewing your monitoring setup and not sure where the gaps are, or you need help designing a reliability strategy for a specific application, get in touch. It is usually a short conversation to identify what you are missing and what to prioritise first.