Assurance Web/Mobile

Access Monitor

Sappia nel momento esatto in cui la sua pagina critica smette di caricarsi — da un vero telefono Android, non da un bot.

  • url_load
  • app_launch
In arrivo
89,00 USD/mese
  • 2 target monitorati
  • 6.000 checks / mese
  • 2 GB di storage delle prove
  • 20.000 richieste API / mese
  • conservazione di 60 giorni
Avvisami
01 — Il problema

Il problema

I monitor sintetici tradizionali girano in un datacenter: non rilevano i blocchi per user-agent/geolocalizzazione né i challenge (403/CAPTCHA) che compaiono solo da un vero dispositivo mobile.

A chi e rivolto

Qualsiasi azienda con una URL/app critica (checkout, login, landing) ha bisogno di sapere se si carica correttamente da un dispositivo Android reale, non da un bot o un browser headless.

02 — Cosa ci invii

Cosa ci invii

CampoFormatoConvalida
targetURL http(s) (o nome del package Android per app_launch)Nessun IP letterale, nessun carattere di controllo, denylist SSRF — rifiutato con 422 alla creazione del check
check_typeurl_load o app_launchEnum, predefinito url_load
frequency_minutesIntero, minutiLimitato dai check inclusi / target inclusi del suo piano
timeout_secondsIntero, 5-120Predefinito 30
failure_thresholdIntero, 1-10Errori consecutivi prima che si apra un incidente
alert_email / alert_telegram_chat_id / results_webhook_urlEmail / chat id di Telegram / URL https://results_webhook_url deve essere https://; si consiglia almeno un canale di avviso
country_codeCodice di 2 lettereDeve essere uno dei corridoi inclusi nel suo piano
03 — Cosa viene eseguito

Cosa viene eseguito

  • Il worker preleva i check in scadenza su dispositivi Android reali (mai un emulatore), fino alla max_concurrency del suo piano.
  • Ogni esecuzione carica il target e registra status, latency_ms, uno screenshot e prova firmata.
  • Un'esecuzione classificata come guasto lato cliente (il suo sito è offline) conta comunque come esecuzione autonoma riuscita, documentata di conseguenza.
  • Si apre un incidente al raggiungimento di failure_threshold errori consecutivi.
04 — Cosa ottieni

Cosa ottieni

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"
}
  • Un MonitorRun per check (status, latency_ms, screenshot, evidence)
  • Avvisi
  • Dashboard
  • API/webhook in base al piano
05 — Limiti e quote

Limiti e quote

Loading...

06 — Autonomia

Autonomia

I check pianificati vengono eseguiti senza supervisione dall'inizio alla fine — prelievo, caricamento, prova, avviso. L'escalation umana si attiva solo quando failure_threshold viene superato o quando il worker stesso non riesce a raggiungere un dispositivo (classe di errore infrastrutturale).

07 — Conformità

Conformità

Prova

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). (Nota: le dichiarazioni relative alle prove sono pubblicate in inglese per mantenerne l'esattezza.)

Verifica la prova

08 — Limiti noti

Limiti noti

  • 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.
  • (Nota: le dichiarazioni relative alle prove sono pubblicate in inglese per mantenerne l'esattezza.)
09 — FAQ
FAQ

Domande su questo servizio

Sì — Access Monitor è disponibile oggi. Scegliete un piano nella pagina dei prezzi per iniziare.

Pronto per Access Monitor?