Does Access Monitor test my checkout logic?

No. It only measures technical load and availability (DNS/TLS/HTTP/redirects/challenges) from a real device — never business logic.

What counts as one check?

Each scheduled load of one target produces one MonitorRun with status, latency, a screenshot, and signed evidence — that is what plan limits count.

Web/Mobile Assurance

Access Monitor

Know the moment your critical page fails to load — from a real Android phone, not a bot.

url_load
app_launch

Available

$89.00/mo

2 monitored targets
6,000 checks / month
2 GB evidence storage
20,000 API requests / month
60-day retention

Start now

01 — The problem

The problem

Traditional synthetic monitors run in a datacenter: they miss user-agent/geolocation blocks and challenges (403/CAPTCHA) that only appear from a real mobile device.

Who it is for

Any company with a critical URL/app (checkout, login, landing) that needs to know if it loads correctly from a real Android device, not a bot or headless browser.

02 — What you send us

What you send us

Field	Format	Validation
target	http(s) URL (or Android package name for app_launch)	No literal IP, no control characters, SSRF denylist — rejected with 422 at check-creation time
check_type	url_load or app_launch	Enum, defaults to url_load
frequency_minutes	Integer, minutes	Floored by your plan’s included checks / included targets
timeout_seconds	Integer, 5-120	Defaults to 30
failure_threshold	Integer, 1-10	Consecutive failures before an incident opens
alert_email / alert_telegram_chat_id / results_webhook_url	Email / Telegram chat id / https:// URL	results_webhook_url must be https://; at least one alert channel recommended
country_code	2-letter code	Must be one of your plan’s included corridors

03 — What runs

What runs

The worker picks up due checks on real Android devices (never an emulator), up to your plan’s max_concurrency.
Each run loads the target and records status, latency_ms, a screenshot and signed evidence.
A run classified as a customer-side failure (your site down) still counts as a successful autonomous execution, evidenced accordingly.
An incident opens once failure_threshold consecutive failures are reached.

04 — What you get

What you get

json

{
  "status": "ok",
  "latency_ms": 842,
  "duration_ms": 1310,
  "screenshot_path": "evidence/2026-09-23/access-monitor/run_8f2a.png",
  "failure_class": null,
  "recovery_actions_json": null,
  "evidence_signature_json": {
    "signature": "3af1...c9",
    "algorithm": "Ed25519",
    "key_id": "witnio-run-ed25519-2026-09"
  },
  "ran_at": "2026-09-23T14:02:11Z"
}

One MonitorRun per check (status, latency_ms, screenshot, evidence)
Alerts
Dashboard
API/webhook per plan

05 — Limits & quotas

Limits & quotas

06 — Autonomy

Autonomy

Scheduled checks run unattended end to end — pickup, load, evidence, alert. Human escalation triggers only when failure_threshold is exceeded or the worker itself cannot reach a device (infrastructure failure class).

07 — Compliance

Compliance

Evidence

PILOT evidence: 1,503 qualified backtests measured on a real Android phone with a real SIM (99.9% autonomy measured across those runs); network path recorded per run (Wi-Fi today).

Verify evidence

08 — Known limitations

Known limitations

The screenshot doesn't replace functional business testing — only load is verified.
AI Visual Change Intelligence (part of Web Assurance) isn't validated yet — not a dependency of Access Monitor's core.
Runs from a real phone with a real SIM in the served corridor; today the browsing path is the phone's Wi-Fi (the site sees a local fixed-line ISP address, not a mobile-carrier address); the network path is recorded in every signed run.

09 — FAQ

FAQ

Questions about this service

Yes — Access Monitor is available today. Pick a plan on the pricing page to start.

Ready for Access Monitor?

Start now See pricing