Access Monitor
Sappia nel momento esatto in cui la sua pagina critica smette di caricarsi — da un vero telefono Android, non da un bot.
- 2 target monitorati
- 6.000 checks / mese
- 2 GB di storage delle prove
- 20.000 richieste API / mese
- conservazione di 60 giorni
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.
Cosa ci invii
| Campo | Formato | Convalida |
|---|---|---|
| target | URL 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_type | url_load o app_launch | Enum, predefinito url_load |
| frequency_minutes | Intero, minuti | Limitato dai check inclusi / target inclusi del suo piano |
| timeout_seconds | Intero, 5-120 | Predefinito 30 |
| failure_threshold | Intero, 1-10 | Errori consecutivi prima che si apra un incidente |
| alert_email / alert_telegram_chat_id / results_webhook_url | Email / chat id di Telegram / URL https:// | results_webhook_url deve essere https://; si consiglia almeno un canale di avviso |
| country_code | Codice di 2 lettere | Deve essere uno dei corridoi inclusi nel suo piano |
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.
Cosa ottieni
- Un MonitorRun per check (status, latency_ms, screenshot, evidence)
- Avvisi
- Dashboard
- API/webhook in base al piano
Limiti e quote
Loading...
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).
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.)
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.)
Domande su questo servizio
Guide correlate
- Qual è la differenza tra il monitoraggio sintetico e il monitoraggio su dispositivo reale?
- Quali prove richiede un audit del consenso ai cookie?
- Cos'è la verifica geografica basata su SIM, e in cosa differisce dai controlli via IP o GPS?
- Cosa copre la verifica web su dispositivo reale, e quando serve?
- Come si verifica se un'app o un sito web funziona su telefoni Android di fascia bassa?