Your uptime monitor should log in, not just ping

The claim

A monitor that fetches your homepage and checks for a 200 status confirms the least useful thing about your business: that a web server is running. The failures that cost you money live one or two layers deeper — a login that silently rejects everyone, a checkout that 500s only when the payment provider is slow, a search that returns nothing. A monitor worth paying for performs the transaction a customer performs, and asserts on the result.

The gap between "up" and "working"

Consider what a homepage ping cannot see. Your session store fills its disk, so every login fails while the homepage — which needs no session — serves perfectly. A deploy ships a broken database credential to the checkout service only; the marketing pages are static and fine. A third-party address-validation API times out, and your registration form hangs on the final step. In all three the homepage returns 200, the uptime dashboard is green, and revenue is zero.

We have watched a business lose a full day of signups because a form's submit button pointed at a renamed endpoint. Every synthetic check they had was passing, because none of them clicked the button.

Three tiers of check, in order of value

1. Content assertion. One step up from a status check and worth doing everywhere: fetch a page and confirm expected text is present. This catches the empty-catalogue and blank-page failures that a status code cannot.

   curl -fsS https://example.ca/products | grep -q 'Add to cart' || alert

2. Authenticated fetch. Log in as a dedicated monitoring account and load a page that only works when the session store, the database, and the auth path are all healthy. This is the check that catches the full-disk-session failure while the front page looks fine.
3. Full transaction. Drive a real browser through the critical path — search, add to cart, reach the payment step — against a test account, stopping just short of a real charge. This is the only check that verifies the thing you actually sell.

Building the transaction check

A headless browser script run on a schedule covers most businesses without a monitoring vendor's synthetic product:

// Playwright, run every 5 minutes from a host outside your network
await page.goto('https://example.ca');
await page.fill('#search', 'chair');
await page.click('#search-submit');
await page.waitForSelector('.product-card');       // search works
await page.click('.product-card:first-child .add'); // cart works
await page.goto('https://example.ca/checkout');
await page.waitForSelector('#payment-form');        // checkout renders
// assert, emit a metric, do NOT submit payment

Run it from somewhere that is not your own infrastructure — a monitor hosted on the same network it watches goes down with it, and reports nothing at the exact moment you need it most.

The three things a real transaction check needs

A dedicated test account, flagged as such. Its orders must not enter fulfilment, count in revenue reports, or trigger customer emails. Tag it in the database and exclude it everywhere the tag appears, or you will ship a chair to your monitoring robot every five minutes.

A hard timeout per step. The check exists to measure slowness, so a step that hangs must fail the check, not hang the check. Ten seconds per step is generous.

Alerting that distinguishes slow from broken. A step that usually takes 400ms and now takes 4s is a warning; a step that errors or times out is a page. Feeding both into the same threshold wastes the signal.

What it costs, and what it saves

A content assertion is free — it is one line in whatever monitor you already run. An authenticated check is an afternoon. A full transaction check is a day to build and a small ongoing cost to run, whether through a vendor's synthetic-monitoring tier or a scheduled script on a cheap external host. Against that, weigh the failure it is designed to catch: a checkout that is broken for everyone, invisibly, while every conventional signal says the site is healthy. That outage ends when a customer emails to complain, which means its duration is set by how long customers wait before giving up rather than emailing — and most simply leave.

Where to start

Add the content assertion to your five most important pages this afternoon; it is nearly free and catches more than its simplicity suggests. Build one authenticated check for your login this week. Build the full transaction check for your single most important flow — the one that, if broken for an hour, would ruin the day — this month. You do not need to synthetically monitor everything. You need to monitor the one path whose silent failure you cannot afford, in a way that actually exercises it.