How it works
How landing page monitoring works
Every one of these exists because a version without it shipped and got something wrong. The reasoning is more useful than the feature list, so it is what is written down.
Fetch the page a customer would land on
A GET from a mobile user agent, every five minutes, to the exact URL your ads point at. Mobile because most paid clicks are, and a consent wall or geo-redirect that only fires for a phone is invisible to a desktop check.
Report where the visitor actually ended up
Following redirects is correct; reporting the status of wherever you landed is not. A retired URL that now bounces to /signin answers 200, and that 200 belongs to the sign-in page. We record the destination path and call it redirected, not ok — unless the redirect keeps the same path, which is just http→https or a trailing slash and wakes nobody.
Read the body, because 200 is not an answer
A soft 404 is a page that returns 200 and says "page not found". We match a short list of gravestone phrases and record which one matched, so the claim is checkable rather than asserted. Precision beats recall here: a false Sev-1 at 3am costs more trust than a missed soft 404 costs money.
Compare the page against its own past
A page that comes back a fraction of its usual size is broken even though it answers 200: a template that lost its body, a build that shipped an empty shell, a CDN that dropped the assets. Each destination is measured against its own median over the past week rather than an absolute threshold, because "too small" only means anything relative to what that page normally is.
Require two strikes before waking anyone
One failed check is a blip — a timeout, a deploy, a CDN hiccup. Two consecutive failures is an outage. The difference is whether people act on your alerts or filter them.
Group symptoms into one incident
A dead landing page shows up four ways at once: the probe fails, conversions go to zero, the CPA guardrail breaches, the goal falls behind. Those are one event. Four alerts about one event is how a channel gets muted — and a condition that keeps returning stays one incident with a count on it, not a new alert every cycle.
Page whoever is awake, with the decision already written
Detection was 6 minutes of INC-2291. The other 207 were a person asleep. The alert carries a link and a prepared, reversible action — pause these three campaigns — and it goes to the rota, not to the account owner. If nobody answers and the action can be undone, it happens anyway and everyone is told what was done.
Where the cost-per-minute number comes from
Spend that went to a page which could not convert is arithmetic: minutes broken × spend rate. No counterfactual, no model, no assumption about what would have happened.
Lost revenue is a different kind of number and we do not print it. Where a figure needs a guess, the interface says unknown and explains why. A number a customer cannot check is a number that destroys trust the first time they try.
The long version of that sum is on what a dead landing page costs. For the failure it usually starts with, see what a soft 404 is, and for why an uptime monitor never reports it, uptime monitoring vs landing page monitoring.
Questions about the check
How often does VampireAI check a landing page?
Every five minutes by default, from a mobile user agent. The interval should match your spend rate rather than how often the page changes: the question is how much money passes through the page between two checks.
Does the check need anything installed on my site?
No. There is no script, no tag and no snippet to add. The check runs from outside, fetching the page exactly as a visitor would, and that is the point rather than a convenience: a tag that ships with your site goes down with your site, and a page that failed to render may never run it at all. Nothing has to be deployed for monitoring to start, or to keep working on the day the deploy is the problem.
How does it avoid false alarms?
Two strikes. One failed check is a blip and is never paged; a second consecutive failure is an outage. Symptoms that begin within thirty minutes of each other in one part of the business are grouped into a single incident rather than paged separately.
Can it tell when a page is rendering broken?
Yes, by size. A page that comes back a fraction of the bytes it normally returns is usually rendering without its template, its content or its assets, and it still answers 200. Each destination is compared against its own median over the past week rather than a fixed threshold.
Does it check the page on mobile?
Yes — every fetch uses a mobile user agent, because most paid clicks are mobile and a consent wall, app-install interstitial or geo-redirect that only fires for a phone is invisible to a desktop check.