Un monitor de ruta crítica vigila la única secuencia de rutas que más importa para tus ingresos —tu registro o tu pago— y te avisa cuando esa ruta y las conversiones reales se rompen al mismo tiempo.
Qué es (y qué no es) un monitor de ruta crítica
Un monitor de ruta crítica es una barrera de protección del negocio, no una garantía de disponibilidad ni una certificación de fiabilidad.
Repite la accesibilidad de las rutas HTTP: envía solicitudes GET a las rutas de tu camino y registra si cada una responde. No:
- Ejecuta un navegador headless
- Ejecuta flujos de JavaScript del lado del cliente
- Envía formularios ni hace
POSTa tus endpoints de registro/pago - Garantiza que el flujo funcione de extremo a extremo
Considéralo una señal de aviso temprano que combina la accesibilidad sintética con tus datos de conversión reales, no una prueba de que tu embudo convierta.
Requisito de plan: los monitores de ruta crítica están disponibles en los planes Pro, Scale y Enterprise.
Cómo se encuentra la ruta crítica
Zenovay analiza tus sesiones reales exitosas más recientes —sesiones en las que un visitante realmente completó un registro o un pago— y determina la secuencia de rutas más común que siguieron esos visitantes:
- Observa las sesiones recientes que terminaron con un registro o pago exitoso.
- Extrae la secuencia ordenada de rutas que cada convertidor visitó camino a ese éxito.
- Encuentra la secuencia más común y calcula una puntuación de confianza: cuán dominante es esa única secuencia entre todos los que convirtieron.
- Muestra la ruta sugerida, la puntuación de confianza y el tipo de conversión (registro o pago) en la pestaña Golden Path.
Si no hay suficientes sesiones exitosas para deducir una secuencia dominante, Zenovay lo dice con claridad: no sugerirá una ruta de baja confianza. En su lugar verás un estado de «aún no hay suficientes sesiones exitosas». Sigue rastreando y la sugerencia aparece en cuanto los convertidores reales le dan un patrón estable.
Ejecutar la deducción ahora: La pestaña Configuración tiene un botón «Buscar una ruta crítica ahora» que dispara la deducción de inmediato (con límite de velocidad) en lugar de esperar al programa diario. Igualmente solo propone un candidato; tú lo confirmas antes de que comience la monitorización.
Configuración
La pestaña Golden Path está en el grupo COMPORTAMIENTO del panel de tu dominio.
- Abre la pestaña Golden Path → Configuración. Zenovay muestra la secuencia de rutas sugerida y su puntuación de confianza.
- Elige registro o pago. Si ambos se califican con confianza suficiente, elige cuál monitorizar. La V1 monitoriza una ruta por proyecto: registro o pago, no ambas. Elige la que más importe para tu negocio.
- Confirma la ruta. Revisa los pasos y confirma. A partir de ese punto Zenovay programa las reejecuciones sintéticas.
Confirmas la ruta deducida; no escribes las rutas a mano en la V1. Si la ruta deducida parece incorrecta, normalmente significa que tus convertidores reales están tomando un camino que no esperabas, lo cual ya es en sí un hallazgo útil.
Con qué frecuencia se vuelve a ejecutar
El intervalo de reejecución es configurable por el usuario para cada monitor mediante el control «Comprobar cada X minutos» en la pestaña Configuración de un monitor activo.
| Plan | Intervalos disponibles |
|---|---|
| Free | No disponible |
| Pro | 60 minutos (fijo) |
| Scale | 5 / 10 / 15 / 30 / 60 minutos |
| Enterprise | 5 / 10 / 15 / 30 / 60 minutos |
El intervalo mínimo es de 5 minutos — esa es la frecuencia con la que el programador realiza las consultas. El valor predeterminado al confirmar un monitor es 60 minutos. Elegir un intervalo más corto te da una señal más rápida cuando algo falla; los planes Scale y Enterprise pueden elegir cualquiera de las cinco opciones por monitor. Un intervalo menor significa más comprobaciones al día, pero no cambia cómo se calcula la sensibilidad a la desviación.
Cada ejecución envía solicitudes GET a las rutas en orden y registra, para cada paso: el estado (¿la ruta era accesible?), el tiempo y el primer paso que falló (si lo hubo).
Leer la pestaña Health
La pestaña Health se abre con cuatro tarjetas de resumen:
- Tasa de éxito: proporción de las reejecuciones programadas recientes en las que cada paso fue accesible.
- Última ejecución: cuándo se volvió a ejecutar la ruta por última vez.
- Duración media: duración media de reproducción de las ejecuciones recientes.
- Desviación: si un fallo sintético y una caída de conversión real están ocurriendo ahora juntos (mostrado como "calmado" o "degradado").
Bajo las tarjetas, la lista de reejecuciones recientes muestra cada ejecución individualmente. Expande una ejecución para ver el estado por paso, la duración y el primer paso que falló (donde esa ejecución se rompió, si lo hizo).
Gráfico de tiempos de respuesta
La vista Health incluye un gráfico de tiempos de respuesta que muestra la duración de reproducción por ejecución. Las ejecuciones están codificadas por colores: verde = normal, ámbar = lenta o degradada (completada pero más lenta que la línea de base), rojo = fallo. Bajo el gráfico encontrarás una lista de ejecuciones recientes (hasta las últimas 50) con el estado y el tiempo por paso.
Selector de intervalo de fechas
Un selector de intervalo de fechas en la parte superior de la vista Health filtra todos los datos mostrados. Los intervalos disponibles dependen de la ventana de retención de datos de tu plan:
| Intervalo | Planes |
|---|---|
| Últimas 24 horas | Todos los planes de pago |
| Últimos 7 días | Todos los planes de pago |
| Últimos 30 días | Pro, Scale, Enterprise |
| Últimos 90 días | Scale, Enterprise |
| Últimos 180 días | Enterprise |
Los intervalos que superan la ventana de retención de tu plan aparecen bloqueados. El selector aplica a toda la vista Health: tasa de éxito, gráfico, duración media y lista de ejecuciones se actualizan juntos.
La tasa de éxito y los tiempos describen únicamente la accesibilidad de las rutas. Una tasa de éxito del 100 % significa que cada ruta respondió a un GET; no significa que un usuario real pueda completar el registro o el pago. El JavaScript del lado del cliente, la validación de formularios, el procesamiento de pagos y el estado de autenticación quedan todos fuera de lo que una comprobación de accesibilidad puede ver.
Alertas de desviación e incidentes
La desviación es la señal que convierte esto en una barrera de protección del negocio en lugar de una página de estado.
La desviación solo se activa cuando ambas condiciones son ciertas en la misma ventana:
- Las comprobaciones sintéticas programadas fallan, y
- las conversiones reales de esa ruta han caído.
Cuando se activa la desviación, Zenovay genera un incidente y la pestaña Health te dirige directamente a él en la pestaña Incidents.
Cada ejecución que falla está también etiquetada con una de tres clases de fallo (mostrada como una insignia cuando expandes la ejecución en la pestaña Health). La clase te indica dónde se encuentra la rotura:
| Clase de fallo | Qué significa |
|---|---|
| infra | Una ruta agotó el tiempo, retornó un 5xx o era inaccesible — probablemente un problema de hosting o red, no tu embudo. |
| flow_drift | Un paso intermedio ahora devuelve 404, 410 o bucle de redirección mientras la ruta de entrada está bien — una URL en la ruta probablemente se movió (por ejemplo, una ruta /signup renombrada). |
| business_flow | Cada ruta respondió, pero la señal de éxito real (un registro o pago completado) no fue corroborada en la misma ventana — la rotura está detrás de las rutas (un paso roto del lado del cliente, un fallo de pago, un error de validación) que una comprobación de accesibilidad no puede ver directamente. |
La clase business_flow es exactamente por lo que importa la puerta de doble señal: la accesibilidad por sí sola habría informado «todo en verde» mientras tus ingresos caían. Combinarla con datos de conversión reales atrapa el fallo que un monitor sintético puro pasaría por alto. También mantiene las alertas en silencio: un fallo sintético por sí solo nunca alerta, porque las rutas pueden dar 404 a un rastreador y aun así funcionar para los usuarios.
Qué no hace la V1
Para mantener las expectativas honestas, la V1 no:
- Ejecuta un navegador headless ni ejecuta flujos de JavaScript del lado del cliente
- Envía formularios ni hace
POSTa los endpoints de registro/pago - Garantiza que el flujo funcione de extremo a extremo, ni certifica disponibilidad, fiabilidad o cumplimiento
- Monitoriza más de una ruta por proyecto, ni registro y pago a la vez
- Alerta ante un fallo sintético por sí solo (por diseño: sería ruidoso)
Esto es una barrera de protección que te dice cuándo la ruta que te genera dinero está en problemas. No es un sustituto de las pruebas funcionales de extremo a extremo de tu registro o tu pago.