Two ways a page fails. Most tools only watch one.
Uptime monitoring catches the obvious failure: the page is down. Liveness monitoring catches the invisible one: the page is fine, returns 200, looks perfect, and the structured data you are paying for stopped appearing on it three weeks ago. MetaPilot watches both.
14:02 up HTTP 200 · 141 ms 14:07 failing HTTP 502 · streak 1/3 · no alert 14:12 failing HTTP 502 · streak 2/3 · no alert 14:17 down incident opened · 1 email sent 14:33 up resolved after 16m · 1 email sent ───────────────────────────────────────────── liveness missing Article schema gone since Jul 19 last seen live 21 days ago · page returns 200
The problem
Schema breaks silently. A cache purge, a CDN change, a theme update, a route someone disabled, a URL that moved, and your JSON-LD is simply gone.
Nothing errors. Nothing 500s. Your monitoring is green, your rich results quietly stop, and you find out when someone asks why traffic dropped. There is no error page for “the thing you paid for is not on the page anymore”, which is exactly why nobody catches it.
How it works
-
Nothing to set up
There is no watchlist to build and nothing to switch on. We check your homepage from the moment we have your sitemap, on every plan including Free. Structured-data liveness follows your auto-pilot flag the same way: switch auto-pilot on for a page and the Monitoring badge on its row lights up.
-
MetaPilotBot polls them on your plan’s cadence
Availability is checked as often as every 5 minutes on paid plans. Liveness runs coarser, hourly at the top end, because markup disappears far less often than a server does.
-
You get one alert per event
Not one per failing check. One when it breaks, one when it recovers, addressed to whichever members opted in. Everything in between updates the open incident silently.
What you get
Uptime monitoring: did the page answer?
MetaPilotBot fetches your homepage and records the status code and response time. Anything outside a timely 2xx or 3xx counts as a failing sample. We append a named cache-busting parameter (?metapilot-uptime=) so the request goes through to your origin wherever your cache honours it, which is how we notice a broken origin before the cache expires and your visitors do.
Every page on auto-pilot is watched, on every plan
Liveness monitoring is not an allowance you spend. There is no cap on how many pages it covers and nothing to arm: auto-pilot is the switch. A page you told us to keep fresh is a page we keep confirming is actually serving what we generated, whether you are on Free or on Business.
Liveness monitoring: did it answer with your metadata on it?
The second failure has no error page. The URL returns 200, the design looks perfect, and the JSON-LD you are paying for stopped appearing three weeks ago. We re-fetch the page and confirm our markup is genuinely in it. Not that we generated it, that it is there.
We know what should be on the page
Because we put it there. A generic monitor can only tell you the page loaded; structured-data monitoring needs to know which types were supposed to be present, which is the one thing an external checker cannot know.
Alerts that do not cry wolf
A single blip never pages anyone. A page has to fail 3 consecutive uptime checks before an incident opens, and 2 consecutive liveness checks before we call the markup gone.
Alerts that do not double up
If a page is unreachable you get the uptime alert, not a second email telling you the schema on the unreachable page is missing. The liveness incident is still recorded; the redundant email is simply not sent.
A real uptime percentage, not a green dot
Every sample is kept for your plan’s retention window, so your dashboard says “homepage up 99.98% over 30 days” rather than showing you a light that is on. Days we did not look read as gaps, never as zeroes, because those are opposite claims.
A deleted page is named as one
A managed page that starts returning 404 reads as Page gone (404) on its own row, not as a generic failure. That is the difference between “the site had a bad minute” and “this URL is gone and your sitemap still lists it”.
It does not cry wolf on a new page either
A page whose markup has never been confirmed live is treated as still propagating rather than broken. Only a page that was live and stopped opens an incident, which is the difference between “not wired up yet” and “regression”.
Everything we inject is covered
Not just schema. Your FAQ and How-To sections and your Ask AI widget are checked the same way, with no separate opt-in and no separate cap. Publishing them is the opt-in.
Plan availability
Uptime: your homepage, on every plan including Free, with no watchlist to fill and nothing to arm. What your plan buys is how often we look: Free every 30 minutes, Starter every 5 minutes, Growth every 5 minutes, Business every 5 minutes. Samples are kept for 7 days on Free up to 365 on Business, which is the window your uptime percentage is measured over.
Structured-data liveness: unlimited pages on every plan, including Free. There is no watchlist to fill and no page cap: every page you put on auto-pilot is watched. What your plan buys is how often we look: Free daily, Starter every 6 hours, Growth every 3 hours, Business hourly.
Liveness of the FAQ, How-To and Ask AI blocks you publish works the same way: publishing already spent a plan slot, and a check you have to remember to arm is a gap.
Frequently asked
Uptime asks “did the page answer?” Liveness asks “did the page answer with our metadata on it?” A page can pass the first and fail the second for weeks, and only the second one explains why your rich results quietly stopped.
Because that is the question uptime uniquely answers: is the site up at all. If it is not, nothing else we could tell you about it matters. Every other page you care about is covered a different way. Put it on auto-pilot and liveness monitoring checks it on your plan cadence, reporting a page that has started 404ing right on its row. That covers more pages than a watchlist ever did, and you do not have to choose which.
No, not for either kind. Uptime is your homepage automatically; liveness follows whichever pages you have on auto-pilot, with no limit on how many. Keeping your important pages fresh already puts every one of them under watch.
No. It takes 3 consecutive failing checks to open an uptime incident, so a deploy blip or a single 502 never fires an alert. Below the threshold the page still reads healthy.
Members of your organization who have opted in, per alert type, on their profile page. They are on by default, because arming the monitor is the opt-in, so a teammate who never opened their settings still hears about an outage. Invite your team and alerts fan out rather than landing in one shared inbox.
Then checks fail for the wrong reason. MetaPilotBot identifies itself honestly and publishes what it is and where it comes from on the bot page, so you can allowlist it in a minute.
There isn’t one, on purpose. Turn auto-pilot on for a page and liveness monitoring comes with it: the Monitoring badge on that row goes from grey to watching, then green once we have confirmed the markup live. A second switch would only ever be the one somebody forgot to flip.
No. Both checks are outside-in fetches of your URL, so they work on whichever channel is publishing your metadata, whether that is the edge Worker or a platform app. What liveness needs is for the metadata to be live somewhere it can read it. Uptime monitoring needs nothing installed at all.
Know before your customers do
There is nothing to arm. Connect your sitemap, turn auto-pilot on where it matters, and hear about it the first time either kind of failure happens.
Ask an AI which pages you should be monitoring