Witnio.
Web/Mobile Assurance

Access Monitor

Sabe el instante en que tu página crítica deja de cargar — desde un teléfono Android real, no un bot.

  • url_load
  • app_launch
Disponible
USD 89,00/mes
  • 2 targets monitoreados
  • 6.000 checks / mes
  • 2 GB de storage de evidencia
  • 20.000 requests API / mes
  • retencion de 60 dias
Empezar ahora
01 — El problema

El problema

Los monitores sinteticos tradicionales corren en datacenter: no detectan bloqueos por user-agent/geolocalizacion ni challenges (403/CAPTCHA) que solo aparecen desde un dispositivo movil real.

Para quien es

Cualquier empresa con una URL/app critica (checkout, login, landing) que necesita saber si carga correctamente desde un dispositivo Android real, no un bot/headless.

02 — Lo que nos envias

Lo que nos envias

CampoFormatoValidacion
targetURL http(s) (o package Android para app_launch)Sin IP literal, sin caracteres de control, denylist SSRF — rechazado con 422 al crear el chequeo
check_typeurl_load o app_launchEnum, por defecto url_load
frequency_minutesEntero, minutosCon piso segun los checks incluidos / targets incluidos de tu plan
timeout_secondsEntero, 5-120Por defecto 30
failure_thresholdEntero, 1-10Fallas consecutivas antes de abrir un incidente
alert_email / alert_telegram_chat_id / results_webhook_urlCorreo / chat id de Telegram / URL https://results_webhook_url debe ser https://; se recomienda al menos un canal de alerta
country_codeCodigo de 2 letrasDebe estar entre los corredores incluidos de tu plan
03 — Que corre

Que corre

  • El worker toma los chequeos vencidos en dispositivos Android reales (nunca un emulador), hasta el max_concurrency de tu plan.
  • Cada corrida carga el target y registra status, latency_ms, un screenshot y evidencia firmada.
  • Una corrida clasificada como falla del lado del cliente (tu sitio caido) igual cuenta como ejecucion autonoma exitosa, evidenciada como tal.
  • Se abre un incidente al superar failure_threshold fallas consecutivas.
04 — Lo que obtienes

Lo que obtienes

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 por chequeo (status, latency_ms, screenshot, evidencia)
  • Alertas
  • Dashboard
  • API/webhook segun plan
05 — Limites y cuotas

Limites y cuotas

Cargando...

06 — Autonomia

Autonomia

Los chequeos programados corren desatendidos de punta a punta — toma, carga, evidencia, alerta. La escalacion humana solo se activa al superar failure_threshold o si el worker mismo no puede alcanzar un dispositivo (clase de falla de infraestructura).

07 — Cumplimiento

Cumplimiento

Evidencia

Evidencia PILOT: 1.503 backtests calificados medidos en un teléfono Android real con una SIM real (99,9% de autonomía medida en esas corridas); ruta de red registrada por corrida (Wi-Fi hoy).

Verificar evidencia

08 — Limitaciones conocidas

Limitaciones conocidas

  • El screenshot no reemplaza pruebas funcionales de negocio — solo se verifica la carga.
  • AI Visual Change Intelligence (parte de Web Assurance) no esta validada aun — no es dependencia del core de Access Monitor.
  • Corre desde un teléfono real con una SIM real en el corredor servido; hoy la ruta de navegación es el Wi-Fi del teléfono (el sitio ve una dirección de un ISP fijo local, no una dirección de operador móvil); la ruta de red queda registrada en cada corrida firmada.
09 — FAQ
FAQ

Preguntas sobre este servicio

Si — Access Monitor esta disponible hoy. Elegi un plan en la pagina de precios para empezar.

Guías relacionadas

Listo para Access Monitor?

Empezar ahoraVer precios