Access Monitor
Saiba no momento em que sua página crítica deixa de carregar — a partir de um telefone Android real, não um bot.
- 2 alvos monitorados
- 6.000 checks / mês
- 2 GB de armazenamento de evidências
- 20.000 requisições de API / mês
- retenção de 60 dias
O problema
Os monitores sintéticos tradicionais rodam em um datacenter: eles não detectam bloqueios por user-agent/geolocalização nem challenges (403/CAPTCHA) que só aparecem a partir de um dispositivo móvel real.
Para quem e
Qualquer empresa com uma URL/app crítica (checkout, login, landing) precisa saber se ela carrega corretamente a partir de um dispositivo Android real, não um bot ou navegador headless.
O que voce nos envia
| Campo | Formato | Validação |
|---|---|---|
| target | URL http(s) (ou nome do pacote Android para app_launch) | Sem IP literal, sem caracteres de controle, denylist de SSRF — rejeitado com 422 na criação do check |
| check_type | url_load ou app_launch | Enum, padrão url_load |
| frequency_minutes | Inteiro, minutos | Limitado pelos checks incluídos / alvos incluídos do seu plano |
| timeout_seconds | Inteiro, 5-120 | Padrão 30 |
| failure_threshold | Inteiro, 1-10 | Falhas consecutivas antes de abrir um incidente |
| alert_email / alert_telegram_chat_id / results_webhook_url | E-mail / chat id do Telegram / URL https:// | results_webhook_url deve ser https://; recomenda-se pelo menos um canal de alerta |
| country_code | Código de 2 letras | Deve ser um dos corredores incluídos no seu plano |
O que roda
- O worker retoma os checks vencidos em dispositivos Android reais (nunca um emulador), até o max_concurrency do seu plano.
- Cada execução carrega o alvo e registra status, latency_ms, uma captura de tela e evidência assinada.
- Uma execução classificada como falha do lado do cliente (seu site fora do ar) ainda conta como execução autônoma bem-sucedida, evidenciada de acordo.
- Um incidente é aberto quando failure_threshold falhas consecutivas são atingidas.
O que voce recebe
- Um MonitorRun por check (status, latency_ms, screenshot, evidence)
- Alertas
- Dashboard
- API/webhook conforme o plano
Limites e cotas
Loading...
Autonomia
Os checks agendados rodam sem supervisão do início ao fim — retomada, carregamento, evidência, alerta. A escalada humana só é acionada quando failure_threshold é excedido ou quando o próprio worker não consegue alcançar um dispositivo (classe de falha de infraestrutura).
Conformidade
Evidência
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: as declarações de evidência são publicadas em inglês para manter a redação exata.)
Limitações conhecidas
- 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: as declarações de evidência são publicadas em inglês para manter a redação exata.)
Perguntas sobre este serviço
Guias relacionados
- Qual é a diferença entre monitoramento sintético e monitoramento em dispositivo real?
- Que evidências uma auditoria de consentimento de cookies precisa?
- O que é a verificação geográfica baseada em SIM, e qual a diferença em relação às verificações por IP ou GPS?
- O que a verificação web em dispositivo real cobre, e quando ela é necessária?
- Como testar se um aplicativo ou site funciona em celulares Android de entrada?