Monitoring only your homepage proves that your homepage works. Checkout can be returning errors, login can be rejecting every attempt, and search can be timing out, all while the homepage renders perfectly and your dashboard shows a month of unbroken green. These pages fail independently because they depend on different systems, and the ones most likely to break are almost always the ones that make money.
This article shows how to decide which pages deserve their own check, explains the content assertion technique that makes page-level monitoring worth doing at all, covers the pages that need careful handling because checking them has side effects, and finishes on how to keep the whole thing from becoming unmanageable.
Why pages fail independently
A homepage is usually the simplest page on a site. It is heavily cached, often static or near-static, and it typically touches nothing more complicated than a content store. Checkout is the opposite: it talks to a payment gateway, a tax service, an inventory system, a shipping rate API, and a session store, and any one of those failing takes it down while leaving the homepage untouched.
The same asymmetry applies across the site. Login depends on an identity provider and a session backend. Search depends on a search index that can fall out of sync or run out of memory independently of everything else. Product pages depend on a catalogue database. A pricing page might depend on nothing at all. When a third party script fails, it takes down the pages that embed it and no others. Monitoring the simplest page on the site and inferring the health of the most complex ones is a category error, and it is the most common gap in otherwise reasonable monitoring setups.
Mapping the pages worth checking
The useful exercise is to trace the path money takes through the site and monitor each step of it. For a store that means the homepage, a category page, a product page, the cart, and the checkout, with checkout being the one that matters most and the one most likely to break. For a SaaS product it means the marketing site, the signup page, the login page, and the main authenticated dashboard, which needs the approach in our guide to monitoring behind a login.
Beyond the revenue path, three categories deserve their own checks. Any page carrying a third party script that can fail independently, because those failures are invisible to server-side monitoring. Any page that is expensive to generate, since it is the first to suffer under load. And any page that generates leads: a contact form, a demo request, a pricing page. A broken contact form is a silent outage that costs real money for weeks, because nobody ever complains about a form that appears to submit successfully and sends nothing.
For most sites this produces five to ten checks rather than one, which is a small enough number to reason about and large enough to catch what a single homepage check misses. This is the practical end of what synthetic monitoring is for.
The assertion is the point
Adding more URLs to a status-code check multiplies a weak signal. The technique that makes page-level monitoring genuinely valuable is asserting on the content of the response, because the most expensive failures return a perfectly healthy 200.
A checkout page that loads its template but fails to reach the payment gateway often renders with an error message inside a 200 response. A product page whose database query failed can render with an empty price. A search page can return a successful page containing zero results because the index is down. A page rendered by a frontend framework will return 200 for the shell even when the API behind it is returning nothing at all. In every one of these, the status code says healthy and the page is useless.
The fix is to give each check a string that only appears when the page is genuinely working. For checkout, the payment provider's frame identifier or the label on the pay button. For a product page, the price format or the add-to-cart text. For search, a result container that only renders when results exist. Choose something stable enough to survive a copy change and specific enough to disappear when the page breaks, and revisit it when the page is redesigned, because a stale assertion becomes a false alarm.
Checking pages with side effects
Some of the most important pages cannot simply be requested repeatedly. Checkout is the obvious one: a monitor that starts a transaction every minute generates abandoned carts, distorts conversion analytics, and in the worst configurations creates real orders. Anything that sends email, writes a record, or consumes an API quota has the same problem.
Three approaches solve this. Monitor the page as far as the point of action without crossing it, which for checkout usually means loading the page and asserting that the payment form initialised rather than submitting anything. Build a health endpoint that exercises the same dependencies without the side effect, so a route that pings the payment gateway's status, checks the inventory service, and returns a small response tells you what a real checkout would tell you without creating an order. Or use a dedicated test account and a test mode, which most payment providers offer, and accept that this proves rather more but requires ongoing maintenance.
Whichever you choose, exclude the monitoring traffic from analytics. A check running every minute against a checkout page adds forty three thousand pageviews a month to a funnel that somebody is trying to optimise, and the resulting conversion rate is fiction.
Common mistakes in page-level monitoring
Monitoring the homepage and inferring the rest. The homepage is usually the simplest and best-cached page on the site. Its health says almost nothing about the pages that depend on payment, identity, or search.
Checking status codes without content assertions. Broken checkouts, empty product pages, and dead search indexes routinely return 200. Without an assertion on expected content the check cannot see any of them.
Letting a monitor transact. A check that submits a checkout or a form creates orders, emails, and junk records continuously. Stop at the last read-only step, or build a health endpoint that exercises the same systems.
Choosing a fragile assertion string. Matching on a marketing headline that changes with every campaign produces false alarms. Match on something structural that only exists when the page works.
Forgetting to exclude monitoring from analytics. Minute-by-minute checks against a funnel page distort every conversion metric derived from it, and nobody notices until the numbers are being used for a decision.
FAQ
How many pages should I monitor?
Usually five to ten for a typical site: the homepage, each step of the revenue path, login, and any page carrying a critical third party dependency. Enough to cover the paths that generate money, few enough to reason about.
Why does my checkout break while the homepage stays up?
Because they depend on different systems. A homepage is typically cached and simple, while checkout depends on payment, tax, inventory, shipping, and session services, any one of which can fail alone.
What should I assert on for a checkout page?
Something that only renders when the payment path initialised correctly, such as the payment provider's frame identifier or the text on the pay button. Avoid marketing copy that changes with campaigns.
Will monitoring my checkout page create test orders?
Only if the check submits the form. A check that loads the page and asserts the payment form initialised creates nothing. Where you need deeper coverage, a health endpoint that exercises the same dependencies is safer.
Closing thought
The pages most worth monitoring are the ones that are hardest to monitor, which is exactly why so many teams end up watching the easy one and hoping. Map the path a customer takes to give you money, put a check on each step, and give every check something to assert on beyond the status code. That is the whole method, and it takes an afternoon.
The payoff is finding out that checkout broke from a dashboard rather than from a drop in orders three days later. Odown checks any URL you point it at from seventeen global locations, with keyword assertions on the response body so a page that returns 200 with an error inside it is treated as the outage it is. If your monitoring currently proves your homepage is fine, website monitoring starts at twelve dollars a month with a fourteen day trial and no card required. Monitoring only your homepage proves that your homepage works. Checkout can be returning errors, login can be rejecting every attempt, and search can be timing out, all while the homepage renders perfectly and your dashboard shows a month of unbroken green. These pages fail independently because they depend on different systems, and the ones most likely to break are almost always the ones that make money.
This article shows how to decide which pages deserve their own check, explains the content assertion technique that makes page-level monitoring worth doing at all, covers the pages that need careful handling because checking them has side effects, and finishes on how to keep the whole thing from becoming unmanageable.
Why pages fail independently
A homepage is usually the simplest page on a site. It is heavily cached, often static or near-static, and it typically touches nothing more complicated than a content store. Checkout is the opposite: it talks to a payment gateway, a tax service, an inventory system, a shipping rate API, and a session store, and any one of those failing takes it down while leaving the homepage untouched.
The same asymmetry applies across the site. Login depends on an identity provider and a session backend. Search depends on a search index that can fall out of sync or run out of memory independently of everything else. Product pages depend on a catalogue database. A pricing page might depend on nothing at all. When a third party script fails, it takes down the pages that embed it and no others. Monitoring the simplest page on the site and inferring the health of the most complex ones is a category error, and it is the most common gap in otherwise reasonable monitoring setups.
Mapping the pages worth checking
The useful exercise is to trace the path money takes through the site and monitor each step of it. For a store that means the homepage, a category page, a product page, the cart, and the checkout, with checkout being the one that matters most and the one most likely to break. For a SaaS product it means the marketing site, the signup page, the login page, and the main authenticated dashboard, which needs the approach in our guide to monitoring behind a login.
Beyond the revenue path, three categories deserve their own checks. Any page carrying a third party script that can fail independently, because those failures are invisible to server-side monitoring. Any page that is expensive to generate, since it is the first to suffer under load. And any page that generates leads: a contact form, a demo request, a pricing page. A broken contact form is a silent outage that costs real money for weeks, because nobody ever complains about a form that appears to submit successfully and sends nothing.
For most sites this produces five to ten checks rather than one, which is a small enough number to reason about and large enough to catch what a single homepage check misses. This is the practical end of what synthetic monitoring is for.
The assertion is the point
Adding more URLs to a status-code check multiplies a weak signal. The technique that makes page-level monitoring genuinely valuable is asserting on the content of the response, because the most expensive failures return a perfectly healthy 200.
A checkout page that loads its template but fails to reach the payment gateway often renders with an error message inside a 200 response. A product page whose database query failed can render with an empty price. A search page can return a successful page containing zero results because the index is down. A page rendered by a frontend framework will return 200 for the shell even when the API behind it is returning nothing at all. In every one of these, the status code says healthy and the page is useless.
The fix is to give each check a string that only appears when the page is genuinely working. For checkout, the payment provider's frame identifier or the label on the pay button. For a product page, the price format or the add-to-cart text. For search, a result container that only renders when results exist. Choose something stable enough to survive a copy change and specific enough to disappear when the page breaks, and revisit it when the page is redesigned, because a stale assertion becomes a false alarm.
Checking pages with side effects
Some of the most important pages cannot simply be requested repeatedly. Checkout is the obvious one: a monitor that starts a transaction every minute generates abandoned carts, distorts conversion analytics, and in the worst configurations creates real orders. Anything that sends email, writes a record, or consumes an API quota has the same problem.
Three approaches solve this. Monitor the page as far as the point of action without crossing it, which for checkout usually means loading the page and asserting that the payment form initialised rather than submitting anything. Build a health endpoint that exercises the same dependencies without the side effect, so a route that pings the payment gateway's status, checks the inventory service, and returns a small response tells you what a real checkout would tell you without creating an order. Or use a dedicated test account and a test mode, which most payment providers offer, and accept that this proves rather more but requires ongoing maintenance.
Whichever you choose, exclude the monitoring traffic from analytics. A check running every minute against a checkout page adds forty three thousand pageviews a month to a funnel that somebody is trying to optimise, and the resulting conversion rate is fiction.
Common mistakes in page-level monitoring
Monitoring the homepage and inferring the rest. The homepage is usually the simplest and best-cached page on the site. Its health says almost nothing about the pages that depend on payment, identity, or search.
Checking status codes without content assertions. Broken checkouts, empty product pages, and dead search indexes routinely return 200. Without an assertion on expected content the check cannot see any of them.
Letting a monitor transact. A check that submits a checkout or a form creates orders, emails, and junk records continuously. Stop at the last read-only step, or build a health endpoint that exercises the same systems.
Choosing a fragile assertion string. Matching on a marketing headline that changes with every campaign produces false alarms. Match on something structural that only exists when the page works.
Forgetting to exclude monitoring from analytics. Minute-by-minute checks against a funnel page distort every conversion metric derived from it, and nobody notices until the numbers are being used for a decision.
FAQ
How many pages should I monitor?
Usually five to ten for a typical site: the homepage, each step of the revenue path, login, and any page carrying a critical third party dependency. Enough to cover the paths that generate money, few enough to reason about.
Why does my checkout break while the homepage stays up?
Because they depend on different systems. A homepage is typically cached and simple, while checkout depends on payment, tax, inventory, shipping, and session services, any one of which can fail alone.
What should I assert on for a checkout page?
Something that only renders when the payment path initialised correctly, such as the payment provider's frame identifier or the text on the pay button. Avoid marketing copy that changes with campaigns.
Will monitoring my checkout page create test orders?
Only if the check submits the form. A check that loads the page and asserts the payment form initialised creates nothing. Where you need deeper coverage, a health endpoint that exercises the same dependencies is safer.
Closing thought
The pages most worth monitoring are the ones that are hardest to monitor, which is exactly why so many teams end up watching the easy one and hoping. Map the path a customer takes to give you money, put a check on each step, and give every check something to assert on beyond the status code. That is the whole method, and it takes an afternoon.
The payoff is finding out that checkout broke from a dashboard rather than from a drop in orders three days later. Odown checks any URL you point it at from seventeen global locations, with keyword assertions on the response body so a page that returns 200 with an error inside it is treated as the outage it is. If your monitoring currently proves your homepage is fine, website monitoring starts at twelve dollars a month with a fourteen day trial and no card required.
