Your page.Put to the test.
Add a page you depend on. KeyPages opens it in a real browser and runs synthetic checks on its content, links, and key controls.
Checks repeat automatically. When something breaks, you get an alert explaining what failed—with evidence to help you investigate.
No installation. No test scripts to maintain.
1 Add your page
2 We run synthetic checks
Page loads
Content renders
Buttons usable
Links resolve
3 You get a clear alert
example.com/pricing
Illustrative example · Checks repeat on schedule
A path is enough to know what the page owes its visitors.
The URL is not just an address to ping. It tells KeyPages what kind of page this is, and therefore the one job it has to keep doing. That job is always something we can verify from the outside.
/products/travel-jacketProduct pageAdd-to-cart present and usable/checkoutCheckout entryReachable, not redirected away/bookBooking pageBooking form present and usable/contactLead formEnquiry form present and usable/pricingPricing pagePrices and primary CTA present/searchSearch pageSearch control present and usable
Nothing to install on the site, and no test scripts to keep in step with every change.
Five moves, then it starts over.
This is not a one-time audit. It is a loop that runs against the live site for as long as the page is protected.
- 01
Open the live page
In a real browser, against production, not a preview build.
- 02
Run what applies
Only the protections that make sense for this kind of page.
- 03
Capture evidence
Screenshot, rendered HTML, and browser context.
- 04
Compare to healthy
Against the last verified good version of this page.
- 05
Update the status
A confirmed failure becomes an issue you can read.
Every check that can run is listed in the check catalog, grouped into the five protection areas. A check that does not apply to a page is never counted as passed.
An alert that explains itself.
Most monitoring hands you a status code and leaves the diagnosis to you. An issue in KeyPages is written so that the failure, the impact, and the next move are all in one place.
Everything on the right came out of a single automated check. Nobody wrote it by hand.
- Page
- northstar-supply.com/products/travel-jacket
- Expected
- Add-to-cart control present and enabled.
- Observed
- Add-to-cart is rendered but disabled. Page returned HTTP 200.
- Why it matters
- A customer arriving on this page cannot start a purchase. Uptime still reads green.
- Next step
- Check the theme update that went live at 09:14.
Controlled fixture from the KeyPages test lab, reproduced on every run. Not a customer outage.
Four honest states. No false alarms dressed up as outages.
A page is only ever in one of these states, and each one is earned by evidence from a real-browser check. When a check cannot get a trustworthy answer, the last trustworthy result stays visible instead of flipping the page red.
- Protected
The latest qualifying check passed.
The page loaded in a real browser, the key action was present and usable, and nothing drifted from the healthy baseline.
- Warning
Something degraded, not yet a confirmed failure.
Slower than baseline, a certificate nearing expiry, a dependency that changed. Worth a look, never treated as an outage.
- Needs attention
A confirmed, evidence-backed failure.
The key action failed or the page is materially broken. You get the finding, the screenshot, and the next move.
- Could not verify
The check was inconclusive.
A timeout, a block, or a scanner restriction meant we could not get a trustworthy answer. This is never reported as an outage.
Lifecycle of an issue: a confirmed finding opens with saved evidence. You fix it, the next check runs, and a later qualifying check verifies the recovery. The issue closes but stays in history, so it shows up in the next report. See the status FAQ for the short version.
Could not verify is not a customer outage.
Some sites push back on automated browsers, and some runs simply do not capture enough to judge. KeyPages is built to say we do not know rather than guess.
The site blocks automated browsers
A bot challenge, a WAF rule, or a geo restriction stops the check before the page renders. We record what we saw and mark the check Could not verify.
The capture is thin or incomplete
The page answered but too little rendered to judge it fairly. Rather than guess, we treat the run as inconclusive.
We retry before we conclude
An inconclusive run is retried on the next cycle. A page is never flipped red on a single unclear result.
The last trustworthy state stays visible
While a page is Could not verify, its last confirmed status remains on the dashboard so nobody mistakes a gap for an outage.
Inconclusive checks are usually a scanner or firewall restriction on the site. The security page lists what to allow so the check can get through.
A failure is confirmed before it is called one.
Not every check carries the same weight. The clear ones surface at once. The ones that can flicker for reasons outside your control have to repeat before they are shown as anything more than a Warning.
Decisive checks surface immediately
The page did not load, the key action is missing or disabled, a redirect sends visitors away. One clear real-browser result is enough.
Noisy checks need confirmation
Response time, a third-party script that sometimes lags, a small content shift. These have to repeat across checks before they are shown as anything more than a Warning.
Recovery is verified, not assumed
A finding closes only when a later real-browser check passes. Your fix going live is not the end; the next passing check is.
Broken at 09:14. Verified fixed by 10:07.
- 09:14
A theme update went live
It disabled the add-to-cart button on a product page. Every uptime signal stayed green.
- 09:41
KeyPages caught it
The key action failed in a real browser. Finding and screenshot saved, alert sent.
- 10:02
The fix went live
One theme setting restored. Nothing to update on the KeyPages side.
- 10:07
Recovery verified
A later real-browser check confirmed add-to-cart is usable again. The issue closed and stayed in history.
Finding, saved evidence, your fix, a later real-browser check, verified recovery. The issue stays in history after it closes, so the next report shows what was protected, what broke, and what recovered.
The limits, stated plainly.
Knowing exactly where a check stops is what makes its result trustworthy. These are the lines KeyPages does not cross, on any plan.
Public pages only
KeyPages checks what an anonymous visitor can reach. It never signs in and never goes behind a login.
Nothing is submitted
No forms are filled, no accounts created, no orders placed, no payments attempted. Ever.
Presence and usability
For a form or button, we confirm it is present, enabled, and reachable. We do not press it.
Every 15 minutes
Each protected page is opened in a real browser on that cycle, with evidence kept for every run.
Full detail, including the IP ranges and user agent to allow, is on the security page.
The raw evidence is kept for every check.
What a customer could actually see.
The page after JavaScript has run.
Console and runtime detail, when that is the answer.
The healthy version each check compares against.
One URL. Then let it run.
Start with the page a client would call you about.
7-day trial, 5 pages, no card. Public pages only; nothing is submitted.