The category
Landing page monitoring
Landing page monitoring is the continuous checking of the page a paid click actually lands on, to verify that it can still convert. Not that a server answered — that the offer is still there, on the device the visitor is holding.
It is a different question from the one uptime monitoring asks, and the gap between the two questions is where the expensive failures live. All of them return 200 OK.
What landing page monitoring catches
Six failure modes. For each: how it happens, what an uptime monitor reports while it is happening, and what to actually do about it. Five of the six answer 200 OK.
The page says it is gone
Sev-1A CMS catch-all, a route with no match, a deleted product page. The visitor reads “page not found”; the server says 200 OK.
- How it happens
- A migration drops a path prefix from the route table. /lp/spring-offer no longer matches anything, the router’s catch-all renders “this page could not be found”, and the framework never sets a status to go with it.
- Your uptime monitor says
- 200 OK. Healthy.
- What to do
- Restore the route, or repoint the campaign at the path that now exists. Then make the catch-all answer 404, so the next one is loud instead of silent.
The click lands somewhere else
Sev-1A retired campaign URL that now bounces to a sign-in wall or the homepage. The visitor never sees the offer they clicked.
- How it happens
- A campaign URL for a retired promotion is 301’d to /login or to the homepage so it “still works”. Every paid click lands on a sign-in wall having never seen the offer it was sold.
- Your uptime monitor says
- 200 OK, for wherever it ended up.
- What to do
- Point the ad at a live URL. A retired offer should answer 410 Gone rather than redirect to something that looks alive — a redirect hides the failure from you and not from the visitor.
The page renders broken
Sev-1The page comes back a fraction of its usual size: a template that lost its body, a build that shipped an empty shell, a CDN that dropped the assets. It looks wrong to a human and fine to a machine.
- How it happens
- A deploy ships without its CSS bundle, or a CMS query times out and the template renders its shell. Fourteen kilobytes come back where a hundred and eighty normally do, and the page is a column of unstyled text.
- Your uptime monitor says
- 200 OK, and the right number of bytes to not care.
- What to do
- Roll back. Compare each page against its own median over the previous week rather than a fixed byte threshold — “normal” is different for every destination and a global number will either miss this or cry wolf daily.
Conversions stopped while spend carried on
Sev-1The page is up, the page is whole, and nobody is converting. The funnel broke somewhere the page cannot show you.
- How it happens
- The form’s endpoint starts returning 500, or a tag container is published with the conversion tag switched off. The page loads perfectly, reads perfectly, and records nothing.
- Your uptime monitor says
- 200 OK. Nothing about the page is wrong, and it is not.
- What to do
- Check the endpoint and the tag before you touch the page. This one is almost never a page problem, which is why a page check will never find it and why sending somebody to inspect the HTML wastes the hour that matters.
Fine on your laptop, broken for the click
Sev-2A consent wall, an app-install interstitial or a geo-redirect that only fires for a phone — which is where most paid clicks come from.
- How it happens
- A consent banner whose accept button does not render below 400px, or an app-install interstitial that only fires for a mobile user agent. On a laptop the page is flawless — and most paid clicks are not on a laptop.
- Your uptime monitor says
- 200 OK — it asked as a desktop browser and got the good page.
- What to do
- Fetch as a phone, which is the only way to see it at all. Then fix the breakpoint or exempt paid traffic from the interstitial; this is the one class where the desktop check is structurally blind rather than unlucky.
The page is refusing visitors
Sev-2A 401, 403, 429 or 503 — a login wall left on by accident, a rate limiter, a WAF rule that started matching your own traffic.
- How it happens
- A WAF rule tightened overnight starts challenging datacentre addresses, or a rate limiter begins counting the ad platform’s own crawler as abuse.
- Your uptime monitor says
- DOWN. This is the one it sees — and it names the wrong problem.
- What to do
- Allow-list the checker and the platform crawlers. This is a rule change, not a rollback — and that distinction is the whole value of catching it here, because an uptime monitor files it as downtime and sends somebody to revert a deploy that was never the cause.
One of these we cannot see, and it belongs here rather than in a footnote: a single-page app whose router paints “not found” in the browser sends perfectly good HTML down the wire, and the probe reads the response rather than running your JavaScript. Conversions stopping still catches it, slower. A real browser would fix it properly and we have not built one — the rest of what is missing is on how the check works.
Take this taxonomy as JSON ↓All six, plus the four checks that run on numbers and the four things we do not detect, with severity and status codes. CC BY 4.0 — quote it, with attribution.
How often to monitor a landing page
Match the interval to the spend rate, not to how often the page changes. The question is how much money passes through the page between two checks.
The last row is what actually happened over 213 minutes, and it is the only figure here that is not arithmetic.
Does it need access to your ad accounts?
No. Checking a destination needs the URL and nothing else — no OAuth, no account access, no review process, about sixty seconds. The spend figure is optional and does exactly one thing: it turns “this page is broken” into “this page is broken and it is costing $58.59 a minute”, which is the sentence that gets somebody out of bed.
Today that figure arrives one way: you send it. Pull-based connectors to the ad platforms are not built yet, and a page that implied otherwise would be the first false sentence on this site.
Why monitoring is not the hard part
Of the 213 minutes INC-2291 ran, 6 were detection and 207 were a person asleep. A monitor that finds the problem in six minutes and then waits three hours for somebody to look at a dashboard has saved nothing. So the alert carries a link and a prepared, reversible action, and it goes to whoever is awake rather than to whoever owns the account.
Each of those decisions has a reason and the reasons are written down: the six checks, and why each one exists. The six are one half of PPC monitoring; the other half runs on the numbers rather than on a URL. The most expensive of them is the soft 404 — the failure that answers 200 OK — and what it costs while it stands is arithmetic, not an estimate.
See it monitoring something
The demo is a working copy of the product with a soft-404'd destination already in it — the check that caught it, the incident it opened, and the decision that stopped the spend.
Landing page monitoring, answered plainly
What is landing page monitoring?
Landing page monitoring is the continuous checking of the page a paid click actually lands on, to verify that it can still convert. It differs from uptime monitoring in three specific ways: it follows redirects and compares the final path to the one you registered, it reads the page body for not-found language behind an HTTP 200 status, and it fetches with a mobile user agent because most ad clicks are mobile.
How often should you monitor a landing page?
Match the interval to the spend rate. At $58.59 a minute — one real advertiser’s rate across 3 campaigns — a five-minute check caps the exposure of any single failure at $293, while an hourly check caps it at $3,515. The right question is not how often the page changes but how much money passes through it between checks.
Does landing page monitoring need access to my ad accounts?
No. Checking the destination needs only the URL — no OAuth and no account access. The spend figure is optional and only adds context to an alert, which turns "this page is broken" into "this page is broken and it is costing $58.59 a minute". Today that figure is sent to us over an ingest endpoint rather than pulled from an ad account, because pull-based platform connectors are not built yet.