Sev-1
The page says it is gone
The status code is fine, so status-code monitoring reports it healthy.
Landing page and PPC monitoring · the destination your ads pay for
Your CAC didn’t rise.
Something broke and kept billing.
Acquisition cost is a fraction, and the cheapest way to wreck it is to keep paying the numerator while the denominator goes to zero. VampireAI checks the page every one of your ads points at, every five minutes, as a phone — and wakes a human the minute it starts costing money without returning any.
Most of it never shows up as an outage. The example below answered 200 OK for 3 hours and 33 minutes while every uptime monitor pointed at it reported healthy.
On this page red means something is wrong, amber means something is drifting, green means it is working. Nothing is coloured for decoration — not even the buttons. The AI in the wordmark is the single exception.
GET /lp/screening-trial■ Soft 40400:06 America/Denver
→ fetching as a phone
→ 200 OK · 14,208 bytes
→ body matched “page could not be found”
→ conversions 0 · spend continuing
Status returned
200 OK
Body matched
page could not be found
Unfixed for
213 min
Spent into it
$12,480
In one sentence
What VampireAI does
It fetches the page every one of your ads points at, every five minutes, as a phone — and pages a human the moment that page stops being worth spending on.
That is landing page monitoring, and it is the sharpest version of the job because a dead destination bills at full rate and returns exactly nothing. Checking one needs its address and nothing else: no ad-account access, no OAuth screen, no procurement.
Reporting tools tell you what last month did. This is the other job: noticing, now, while the money is still going out. Any number you can send us gets watched the same way — spend, conversions, revenue — so the alert can say what the break is costing and not merely that it happened.
What it watches
Every URL you pay to send traffic to, plus any number you send us
Destinations need no permissions at all: you paste the address and we fetch it the way your customer would, on a phone, following whatever it does next. Numbers arrive the other way round — anything that can make an HTTP request POSTs them to us, from a cron job, a warehouse query or twelve lines of Python. We do not pull from your ad accounts; that connector is not built.
What it catches
Anything that looks wrong, not just anything that is down
A feed that goes quiet. A cost per acquisition through its guardrail. A goal falling off pace. Two sources disagreeing about the same number. A destination that says it could not be found, renders broken, or walls off phones. Almost none of it is an outage, and all of it costs money.
What it does about it
Wakes whoever is awake, with the fix attached
After two failed checks in a row it raises an incident and pages the person actually on shift — with the action already written, priced and reversible. Approve or reject from your phone.
One place
What else can it watch besides the page?
Any number you send it. The direction matters and most tools are coy about it, so plainly: destinations we fetch ourselves — you give us a URL and nothing else — and every other number you push to us, one POST at a time. There are no pull-based platform connectors. That is a real limitation and it buys you a real thing: nothing here waits on an OAuth review.
Paid media
The destination every ad points at, fetched as a phone every five minutes — that half needs only the URL. Spend rate, conversions and cost per acquisition against a guardrail are numbers you send us, and they are what let the alert price the break.
we fetch the destination · you send the spend
Organic search
Clicks and impressions per page, and the pages that stop reporting them — a template change that de-indexes a directory looks like nothing until the quarter closes.
you send it from Search Console or your analytics
Social and content
Publishing cadence and the traffic it returns, so a channel that quietly stopped posting or stopped landing is a signal rather than a discovery.
you send it from your analytics
Email and lifecycle
Sends, opens, clicks and the conversions behind them. A broken send or a deliverability cliff shows up as a feed that went quiet, not as an outage anyone gets paged for.
you send it from your ESP or CRM
Revenue and product
Signups, trials, orders and the money. This is the denominator: without it, every cost number on the page is half a fraction.
you send it from Stripe, your warehouse or your database
Anything else you have
The checks are not channel-specific. A feed going silent, a threshold breached, a goal off pace, two sources disagreeing — those work on any number you can send us, from any system that can report one — one POST and a token, no OAuth screen and no waiting on us to build a connector.
Metabase, BigQuery, Snowflake, a cron job, a webhook
Nothing here is sampled, modelled or estimated. Every number is one your own systems reported, with the source and the timestamp next to it, because a figure you cannot trace is a figure you will not act on at three in the morning.
What the click actually got
Why a dead landing page still answers 200 OK
Paid click
$58.59 / min
sent to
/lp/screening-trial
the URL you registered
until 00:00 this served the offer page
AFTER DEPLOY 8f2c1 · NO ROUTE MATCHES ↓
The router's catch-all
“this page could not be found”
which answers ↓
200 OK
an uptime monitor stops here — it reads the status code and nothing else
VampireAI instead reads ↓
the words on the page · the path it landed on · fetched as a phone
→ and the conversions that stopped while spend did not
What a dead landing page costs per minute
$0.00
That is what has left the account since you opened this page, at INC-2291’s real rate: 0:00 here, at $58.59 a minute. That page went 213 minutes before anyone acted, which came to $12,480. Arithmetic, not an estimate.
What it costs to stop it, by how long that takes
The same arithmetic, on your numbers
What does a break cost you before anyone notices?
Minutes broken × your spend rate × how often it happens. No counterfactual in it and no model behind it — move the sliders and the page does the multiplication in front of you. The only figure we supply is our own: two checks five minutes apart, so ten minutes to a page and five more to act on it.
A year of breaks, noticed in 4h
$8,333
6 × 240 min × $5.79
The same year, caught here
$521
6 × 15 min × $5.79
Stays in the account
$7,813
94% of it
At $250,000 a month, 100% of the account bills at $5.79 a minute while it is broken. Two of the assumptions in that pull against each other and we would rather name both than call the answer conservative: dividing a month evenly by its minutes understates it, because almost nobody spends evenly at four in the morning and the daytime rate is the one billing while a page is down; assuming a break takes out every campaign you run overstates it — INC-2291 was 3 campaigns, not an account. Move that last slider until it matches what one break actually reaches; the sum is only worth as much as that number is. Nothing here estimates revenue you would have earned: every dollar in it bought nothing by definition, because a destination that cannot convert converts nobody, which is why it lands on acquisition cost as pure numerator.
The same sum has its own page if you need to send it to somebody who controls the budget: the downtime cost calculator. If the number you are defending is cost per customer instead, the CAC calculator takes the spend that reached a dead page out of the numerator and shows what it did to the figure.
Six ways a landing page breaks that your uptime monitor will not tell you about
Five of them answer 200 OK, so nothing that reads status codes ever sees them. The sixth your uptime monitor does see — and reports as down, which sends the wrong person to fix the wrong thing.
Sev-1
The click lands somewhere else
The 200 belongs to wherever it ended up, not to your landing page.
Sev-1
The page renders broken
Every check that stops at the status code sees a healthy page.
Sev-1
Conversions stopped while spend carried on
Nothing about the page is wrong, so no page check will ever fire.
Sev-2
Fine on your laptop, broken for the click
A desktop check never sees it, because it never asks as a phone.
Sev-2
The page is refusing visitors
This is the one an uptime monitor does see — and files as down. The fix is a rule, not a rollback.
Not built yet, and we would rather say so
- Response time
- The probe cannot honestly time itself yet — it fires through a queue that batches its writes, so there is no per-request latency to report. It needs a prober that clocks its own fetch.
- Broken links on the page
- Needs a crawl of every link on the destination, not just a fetch of the destination itself.
- Layout and visual regression
- Needs the page rendered in a real browser and compared against a reference. The current probe reads the response, not the picture.
- Client-rendered not-found pages
- The probe fetches the response and never runs your JavaScript, so a single-page app whose router paints "not found" in the browser looks healthy to it — the HTML off the wire really was fine. Conversions stopping still catches it, slower. A real browser fixes it properly.
All six run against any URL you paste, free and without an account, in the landing page checker — one fetch, as a phone, with the evidence printed beside each verdict. It is one of six free tools, and what none of them can tell you is whether the page is still fine at two in the morning, which is the whole difference between checking once and watching.
The part nobody builds
Why the alert has to arrive with the decision already made
Detection took 6 minutes. The other 207 were a person asleep.
Deploy 8f2c1 shipped at Denver midnight, and the only person who could roll it back was asleep. A faster dashboard saves none of that. So the alert arrives with the decision already written, reversible, and goes to whoever is actually awake.
00:06
Detected
Feed watch: conversions stopped while spend continued, confirmed on a second check. One failure is a blip; two in a row is an outage.
00:06
Paged — primary on call, UTC−3
No answer. The rota moves on rather than waiting for the account owner.
00:19
Acknowledged — next shift, UTC+5:30
Taken. The first contact stops being paged.
00:21
Applied — 3 campaigns paused
Spend stopped. The 207-minute wait becomes 15.
00:06 is INC-2291's. The rota, and everything after it, is what this alert produces instead of a 3h27m wait.
What lands on the phone at 00:06
What a landing page monitoring alert looks like
Most alerting says a number crossed a line. This says what it costs, what it proposes, and lets you say no — the only version a person answers at 3am.
- ·It names the evidence — which check, how many times, what it found.
- ·It prices the delay, so the decision has a cost attached to waiting.
- ·Reject is a first-class answer, and it is recorded like any other.
Try it — the card records what you chose, the way the real one does.
VAMPIREAIAwaiting decision00:06
Pause the three campaigns spending into the dead page
Conversions from these three campaigns stopped while spend continued, and the destination probe confirms the page body says it could not be found while the server answers 200. These campaigns are spending $58.59 a minute into it and have converted nobody since it started.
Confirmed on
2 checks
Approving stops
$58.59/min
Either way it is recorded, with who and when.
What it costs you to try
What you need to start monitoring a landing page
A URL. Not an OAuth review.
Checking a destination needs the address of the page and nothing else. No account access, no permissions screen, no procurement.
Connecting an ad account is optional, and it buys you one thing: the alert stops saying this page is broken and starts saying this page is broken and it is costing $58.59 a minute — the version that gets somebody out of bed.
To start watching one page
| Paste the URL | ~20 sec |
| Pick a check interval | ~10 sec |
| Say where it should land | ~30 sec |
| Connect an ad account | optional |
| Enter a card | none exists yet |
There is no price on this site because the self-serve connect flow is not built. Charging before it exists would be charging for a promise.
Before you spend a minute on this
Who landing page monitoring is not for
If you spend a few thousand a month, this is not worth your money yet.
A dead landing page for an afternoon costs a small account less than a subscription would. Run this page’s own arithmetic backwards and it gives the line exactly: watching starts paying for itself around $32k a month of spend, and the tier with the guardrails and the rota around $160k — sooner across a book of client accounts, where a dead page is a weekly event rather than a yearly one. Below those figures the free checker is the honest answer, and we would rather say so here than take the money. The pricing page shows the working.
Common questions
Landing page monitoring, answered plainly
What does VampireAI do?
VampireAI is landing page monitoring for paid traffic. It fetches the page every one of your ads points at, every five minutes, from a mobile user agent, and checks that the page still works: the click arrives where you sent it, the offer is still on it, it rendered whole, and people are still converting. When two checks in a row fail it raises an incident and pages whoever is on shift, with a priced, reversible action already written.
What can VampireAI watch besides the landing page?
Any number you send it. Destinations are the one thing it fetches for itself, from a URL and nothing else; everything else — spend, conversions, sessions, sends, revenue — you POST to an ingest endpoint, and the same checks apply to it: a feed going silent, a threshold breached, a goal off pace, two sources disagreeing. There are no pull-based connectors to ad platforms or analytics, which is why nothing here waits on an OAuth review.
How does monitoring lower customer acquisition cost?
Acquisition cost is spend divided by the customers it brought. Spend that reaches a broken destination buys nobody, so it lands on that fraction as pure numerator and moves CAC the whole way. Cutting the time a break stands from hours to minutes removes that spend from the numerator. The saving is arithmetic — minutes broken times your spend rate — with no counterfactual revenue in it.
What is landing page monitoring?
Landing page monitoring is the continuous checking of the page a paid click actually lands on, to confirm it still works. It checks where the visitor ended up, what the page says, whether it rendered whole, and what a phone sees — not just whether a server answered.
How is landing page monitoring different from uptime monitoring?
Uptime monitoring asks whether the server answered. Landing page monitoring asks whether the page can still sell. A dead landing page usually returns 200 OK, so an uptime monitor reports it healthy while the ads keep running.
What does VampireAI check on a landing page?
Six things, every five minutes, as a phone: that the click still arrives at the URL you registered, that the page does not say it is gone, that it comes back whole rather than as a stripped or empty render, that a phone is not shown a wall a laptop never sees, that the page is not refusing visitors, and that conversions have not stopped while spend continues. Five of the six still return 200 OK, which is why a status-code check never reports them.
What is a soft 404?
A soft 404 is a page that says it does not exist while the server answers 200 OK. A CMS catch-all, a route with no match, or a deleted product page all produce one. Because the status code looks fine, most monitoring never sees it.
How often should you check 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 while it is broken. At $58.59 a minute, five-minute checks and the two-strike rule put detection about six minutes in — roughly $352. INC-2291 was unfixed for 213 minutes, which came to $12,480.
Does VampireAI need access to my ad accounts?
No. Checking a destination needs the address of the page and nothing else — no OAuth, no account access, no review process. The spend rate is optional and only adds context to the alert; today it is sent to us over an ingest endpoint rather than pulled from an ad account, because pull-based platform connectors are not built yet.
Open the demo, with the incident already in it.
A working copy of the product loaded with INC-2291 — the check that caught it, the war room the next shift read, and the decision that would have stopped the spend at 00:21. No account, no connection, no card.
We store what you type here and nothing else of ours. Visits are counted with Vercel and Google Analytics, which sets a cookie; we switch off ad personalization and never run ads. A browser Do Not Track or Global Privacy Control signal stops Google loading. One person reads this. Unsubscribe by replying.