Uptime monitoring that watches the wrong thing

Picture a store with an uptime monitor that has reported 100% availability for six months. The owner gets an alert only when the monitor sees the site go down. One afternoon, three customers email to say they cannot log in. The owner tries to log in and gets a database connection error. The site has been unreachable to anyone trying to use an account for at least an hour. The monitor never sent an alert. The monitor was pointed at the homepage, which is static and does not touch the database. The homepage loaded fine. The monitor reported green.

That is the most common version of this problem. The second most common version is a monitor pointed at an IP address instead of a hostname. The IP responds, the monitor reports up, but DNS is broken and the domain does not resolve. Customers see an error. The monitor sees success.

The purpose of uptime monitoring is to alert you when customers cannot use your site. A check that does not exercise the same systems customers use will report success while customers see failure. If your site requires a database to log in, to check out, or to display product details, your monitor needs to touch the database. If your site is reached by a hostname, your monitor needs to resolve that hostname. A check that skips either of those steps is checking something other than what customers experience.

What a check should exercise

A useful uptime check does at least three things. It resolves the hostname through DNS, the same way a browser does. It requests a page over HTTPS, so it confirms the certificate is valid and the web server is responding. And it looks for a specific piece of content on the page that proves the application layer is working.

For a static site, that last part can be simple. Check that the page contains a known string of text. For a site with a database, the check should request a page that queries the database. That might be a product page, a login page, or a custom status endpoint that runs a trivial query and returns a result. The point is not to test the entire application. The point is to confirm that the database is reachable and responding, because if it is not, large parts of the site will fail even if the web server is up.

The other thing a check should do is follow the same path customers follow. If your customers reach the site at www.example.com, point the monitor at www.example.com, not at example.com, not at the server IP, not at a subdomain you use for testing. If the site redirects HTTP to HTTPS, make sure the check is testing HTTPS. If the site sits behind a CDN or a firewall, make sure the check is coming from outside that layer, not from inside your network where everything looks up even when external access is broken.

Monitoring an ecommerce site

For a store, the minimum useful check is one that loads a product page and confirms the page contains the price and the add-to-cart button. That proves DNS is working, the web server is responding, the database is reachable, and the application is rendering product data. It does not test the payment gateway, and it does not test checkout, but it catches the majority of outages that affect customers.

Some monitoring tools let you set up a transaction check, which is a sequence of requests that simulates adding an item to the cart and proceeding partway through checkout. That is better, because it exercises more of the stack, but it is also more complicated to set up and more likely to break when the site changes. A product page check is a reasonable middle ground. It is simple enough to stay stable and detailed enough to catch database failures, which are the most common cause of partial outages.

The other thing to monitor on a store is certificate expiry. Most uptime monitors will alert you if the certificate is expired, but the better ones will warn you when the certificate is approaching expiry, which gives you time to renew it before customers see an error. Certificates expire on Sundays, as I have written about before, or at least it feels that way. Monitoring the expiry date separately from the uptime check means you get advance notice instead of an outage alert.

Where this sits

Uptime monitoring is included in RedCyfer hosting and in the Care retainer. The checks are pointed at a page that touches the database, and they resolve the hostname the same way customers do. I also set up separate checks for certificate expiry, for DNS resolution, and for mail server response. The goal is that if a customer sees a failure, the monitor saw it first and sent an alert before the customer had time to email. That does not always happen, but it happens more often when the check is pointed at the right thing.