Monitoreo sintético de transacciones
La monitorización de transacciones web de HostTracker repite un flujo de usuario real - iniciar sesión, buscar, añadir al carrito, pagar - en un navegador real desde 300+ ubicaciones, y te alerta en cuanto un paso falla.
Cómo se ejecuta una comprobación de transacción, del primer paso a la alerta
Cada ejecución, desde la primera navegación hasta el veredicto.
Nada de grabadoras de macros que se vuelven obsoletas. Ponga nombre a los pasos - el nombre es lo que dice la alerta.
checkout · 5 pasos · 3.6 s
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
navigate, click, type, select, checkContent, hover, waitForNavigation, sleep, screenshot y back - cada una con su propio tiempo de espera y nombre.
Cualquier error en la consola del navegador hace fallar la comprobación, con una lista de subcadenas permitidas de hasta diez para un script ruidoso de terceros.
Cree y edite monitores de transacciones mediante REST, los SDKs, Terraform o MCP - con el conjunto completo de acciones incluido.
Más informaciónEmpieza por el único recorrido cuyo fallo te cuesta dinero, ponlo en verde, y solo entonces añade el resto. Un flujo monitoreado en el que confías vale más que cinco a medio configurar.
Abre una página de producto, haz clic en añadir al carrito, verifica que el indicador del carrito muestre un artículo, abre el checkout, verifica que el total y el formulario de pago se hayan renderizado. Detente un paso antes de que se realice el pedido y obtienes cobertura completa sin pedidos de prueba en tu base de datos.
Escribe las credenciales de una cuenta de prueba dedicada, envía, espera la navegación y luego verifica un texto que solo existe una vez que la sesión es real. Este es el escenario de mayor valor para la mayoría de las aplicaciones: un login roto es una caída total que devuelve 200 en cada página.
Completa los campos, envía, verifica el texto de agradecimiento. La rotura silenciosa de formularios es la clásica caída invisible: nada da error, nada alerta, y las consultas simplemente dejan de llegar hasta que alguien lo nota semanas después.
Escribe una consulta que siempre debe coincidir con algo, envía, y luego verifica tanto que un resultado conocido esté presente como que el texto de "sin resultados" esté ausente. Esa segunda aserción es la que detecta un índice de búsqueda que silenciosamente dejó de reconstruirse.
Recorre el formulario de registro hasta la pantalla de confirmación final y verifícala, apuntando el formulario a un destino de prueba para que el monitoreo nunca cree cuentas reales. El registro se rompe de forma silenciosa y costosa: nadie se queja de un registro que no pudo completar.
Solicita un restablecimiento y verifica que aparezca la pantalla de confirmación. Depende de tu canal de correo, de tu cola y de tu servicio de tokens, así que es un canario inusualmente bueno para problemas de backend que la página principal nunca muestra.
El servicio de verificación de transacciones de HostTracker garantiza que todas las etapas de un proceso de transacción online funcionen correctamente. Prueba cada paso del proceso, desde añadir artículos al carrito hasta completar una compra. Esto ayuda a encontrar y corregir problemas que podrían impedir que los clientes compren, lo que mejora la experiencia del cliente y reduce las ventas perdidas.
La función de verificación de transacciones de HostTracker es integral y cubre varios aspectos de una transacción de comercio electrónico. Incluye elementos como el envío de formularios, los clics en botones y las redirecciones entre páginas, para reproducir el comportamiento de los usuarios reales. Esto prueba todo el proceso de compra para asegurarse de que funcione bien. Además, ofrece registros y reportes detallados que ayudan a los administradores a encontrar y corregir rápidamente cualquier problema, sin afectar el recorrido de compra del usuario.
Las verificaciones de transacciones hacen que los sitios de comercio electrónico sean más fiables y eficientes. Ayudan a mantener las transacciones funcionando sin problemas al corregir los fallos antes de que ocurran. Esto significa clientes más satisfechos y una mayor confianza en el sitio. También ayuda a mantener a los clientes contentos al evitar ventas perdidas, lo que la convierte en una herramienta útil para las tiendas online.
El paso por su nombre, su captura de pantalla y el tiempo de cada paso anterior.
El resultado y la alerta llevan el nombre del paso, de modo que "caído" se convierte en "3 - el envío de inicio de sesión dejó de redirigir".
Capturada cuando un paso falla, junto a la del paso posterior al último - cómo se veía la página en el camino.
Sitios web, servidores, APIs, certificados. Un tipo de comprobación por página, con las mismas ubicaciones, alertas e informes detrás.
"Llevo mucho tiempo trabajando con este servicio de monitorización, y mi rutina diaria ya no es un problema. Vigila silenciosamente todos mis sitios y me permite reaccionar en cuanto algo falla."
Con la confianza de equipos en
Cada capítulo se abre en su lugar, para que la página siga siendo breve.
El monitoreo sintético significa que el tráfico se genera a propósito: en lugar de esperar a que un visitante se tope con un problema y confiar en que te avise, un servicio de monitoreo recorre tu sitio por sí mismo, según un horario, desde fuera de tu red. El monitoreo de transacciones es su forma de varios pasos. Una verificación sintética simple solicita una URL y observa la respuesta. Una verificación de transacción abre un navegador real, recorre un escenario ordenado - abrir la página, iniciar sesión, buscar, añadir al carrito, finalizar la compra - y comprueba lo que encuentra en cada parada.
La diferencia importa porque la mayor parte de lo que los clientes realmente hacen en un sitio web es una secuencia, no la vista de una sola página. Cada página individual de un checkout puede devolver HTTP 200 mientras el checkout en sí está roto: un botón eliminado por una implementación, un formulario que envía a un endpoint que ahora devuelve 404, un error de JavaScript que detiene el asistente en el paso tres. Nada de esos fallos aparece en un código de estado, así que nada de eso aparece en el monitoreo de disponibilidad convencional.
No es lo mismo que el monitoreo de transacciones financieras. En banca y cumplimiento normativo, "monitoreo de transacciones" significa examinar pagos en busca de fraude y lavado de dinero. Esta página trata sobre el significado en operaciones web: reproducir automáticamente un recorrido de usuario en tu propio sitio para comprobar que sigue funcionando. HostTracker es un servicio de monitoreo de sitios web: vigila tu flujo de checkout, no tu libro de pagos.
Una verificación HTTP rápida es la herramienta adecuada para "¿el sitio está activo?". Es una sola solicitud, así que su veredicto es una sola respuesta: el código de estado, el tiempo de respuesta y la palabra clave o regla de aserción que hayas configurado sobre el cuerpo recibido. Eso es mucha cobertura por muy poco costo - y se detiene precisamente donde termina la primera respuesta. Todo lo que está por debajo de la línea en esta tabla ocurre después de ese punto.
| Qué se rompió realmente | Verificación HTTP rápida | Verificación de transacción |
|---|---|---|
| Servidor inaccesible, fallo de DNS, handshake TLS rechazado | Detectado | Detectado |
| La página de inicio devuelve 500 tras una implementación | Detectado | Detectado |
| La página carga, pero el botón "Añadir al carrito" fue eliminado en una versión | No detectado - el HTML sigue devolviendo 200 | Detectado - el paso de clic no puede resolver su selector |
| El formulario de login envía a un endpoint que ahora devuelve 404 | No detectado - la propia página del formulario está bien | Detectado - el paso posterior al envío nunca llega a la página de la cuenta |
| Una excepción de JavaScript detiene el asistente de checkout en el paso dos | No detectado - JavaScript nunca se ejecuta | Detectado - el navegador ejecuta el script, y la verificación puede fallar por errores de consola |
| La página de pago muestra un aviso de error en vez de la confirmación | No detectado - un error renderizado sigue siendo un 200 | Detectado - falla una aserción de contenido sobre el texto de confirmación |
| La cookie de sesión deja de establecerse, así que el paso tres rebota a la página de login | No detectado - no hay sesión que perder | Detectado - una sola sesión de navegador ejecuta todo el escenario |
| Un script de terceros - chat, gestor de etiquetas, SDK de pagos - bloquea el renderizado | No detectado - los recursos de terceros nunca se solicitan | Detectado - el navegador los solicita igual que un visitante |
| El flujo funciona pero cada paso ahora tarda ocho segundos | Parcialmente - solo se cronometra la primera respuesta | Detectado - cada paso se cronometra, y un paso puede agotar su tiempo |
Ninguna verificación reemplaza a la otra. Lo recomendable es ejecutar ambas: una verificación HTTP cada minuto en el mismo sitio para detectar caídas rápido, y una verificación de transacción en uno o dos recorridos que realmente generan ingresos. Si quieres empezar por la mitad de disponibilidad, comienza con el monitoreo de disponibilidad distribuido desde más de 300 puntos de verificación y añade el flujo encima.
Cada ejecución abre un navegador Chromium real, sin interfaz gráfica, en uno de los puntos de verificación de HostTracker, y le da una sola sesión de navegador para todo el escenario. Ese detalle es lo que hace que la verificación tenga sentido: las cookies, tokens y el estado de sesión establecidos en el paso dos siguen ahí en el paso cinco, exactamente como estarían para una persona navegando por tu sitio. El JavaScript se ejecuta, se siguen las redirecciones - incluidas las que disparan tus propios scripts - y los recursos de terceros cargan igual que en el navegador de un visitante.
El escenario es secuencial y falla rápido. Los pasos se ejecutan en el orden en que los escribiste, y el primer paso que falla termina la ejecución y se convierte en la causa reportada. Nunca obtienes una avalancha de errores en cascada causados por un solo botón roto: obtienes el botón roto.
Dos interruptores opcionales cambian cuán estricta es una ejecución. Fallar ante un error de consola convierte cualquier error de consola del navegador en una verificación fallida - potente en una aplicación bien comportada, y combinado con una lista de hasta diez subcadenas permitidas para que un script de terceros conocido por su ruido no dé falsas alarmas. Omitir la carga de archivos multimedia está activado por defecto; desactívalo cuando lo que estás probando es precisamente el contenido multimedia.
Una transacción es una lista de pasos, y cada paso es una acción sobre la página. No hay un grabador de macros que se desactualice: construyes el escenario explícitamente, que es también por qué sigue funcionando cuando tu equipo de marketing cambia el texto de un botón.
| Acción | Qué hace el paso |
|---|---|
| navigate | Abre una URL. La primera navegación - a la dirección propia del monitor - se añade por ti como paso cero. |
| click | Hace clic en un elemento resuelto por selector CSS, o en una coordenada del viewport. Botón izquierdo, derecho o central, con un retardo de mantener pulsado opcional. |
| type | Escribe texto en un campo, opcionalmente con un retardo entre pulsaciones para que los propios manejadores de entrada de la página puedan seguir el ritmo. |
| select | Verifica la cardinalidad de un selector: debe no coincidir con nada, coincidir con exactamente un elemento, con al menos uno, o con cualquier cantidad. Actúa sobre todas las coincidencias, la primera, o una aleatoria. |
| checkContent | Verifica el texto renderizado. Hasta diez palabras clave, cualquiera o todas ellas, sensibles o no a mayúsculas, presentes o deliberadamente ausentes, y opcionalmente solo en el texto visible. |
| hover | Pasa el cursor sobre un elemento - la forma de llegar a un menú o tooltip que solo existe al pasar el mouse por encima. |
| waitForNavigation | Espera a que la página navegue, y opcionalmente falla el paso si no ocurre ninguna navegación a tiempo. |
| sleep | Pausa, de 1 milisegundo hasta 10 segundos, con variación aleatoria opcional para que un escenario no golpee el mismo instante exacto en cada ejecución. |
| screenshot | Captura la página a mitad del flujo, para que un fallo dos pasos después siga mostrándote cómo se veía la página en el camino. |
| back | Retrocede una entrada en el historial del navegador. |
Cualquier paso puede llevar una captura de pantalla y una espera de navegación después de él, su propio límite de tiempo personalizado, y un nombre corto de hasta 19 caracteres. Ponles nombre a tus pasos: el nombre es lo que aparece en el resultado y en la alerta, y "3 - enviar login" es la diferencia entre una página que está "caída" y una página cuyo POST de login dejó de redirigir. En el editor web, las capturas de pantalla y las esperas de navegación se ofrecen como comportamientos posteriores al paso; el conjunto completo de acciones, incluido hover, está disponible a través de la API.
id o un atributo data- que controles tú, no un nombre
de clase generado que cambia con la siguiente compilación.checkContent después de cada transición significativa
es lo que convierte una secuencia de clics en una prueba real: después del login, verifica el texto de
la página de la cuenta; después del checkout, verifica el texto de confirmación.Si quieres verificar rápidamente la URL de partida antes de construir el escenario, ejecuta una verificación HTTP instantánea gratuita sobre ella - sin necesidad de iniciar sesión - o mide cómo carga la página en un navegador real con la prueba de velocidad de página gratuita.
La ejecución se detiene en el paso que falló y registra lo que vio. El resultado nombra el paso, clasifica el fallo - un tiempo de espera agotado, un elemento que el selector no pudo resolver, una aserción de contenido que no coincidió, un error HTTP, un error de conexión, un error de consola del navegador, o un paso mal configurado - y conserva las duraciones por paso, la URL, la IP y el estado HTTP en el que aterrizó cada navegación, los mensajes de consola del navegador, y una captura de pantalla de la página en el momento en que se rompió.
Luego se verifica dos veces antes de despertar a nadie. Una sola observación fallida no se trata como una caída: la verificación se repite en puntos de verificación independientes adicionales y el cambio de estado solo se confirma cuando el quórum está de acuerdo. Por defecto es un veredicto por mayoría entre hasta siete agentes, con un mínimo de tres, de modo que un punto de verificación inestable, o un problema de red pasajero entre un centro de datos y tu host, no puede fabricar una alerta por sí solo.
Una vez confirmada la transición, la alerta sigue el retraso que cada contacto eligió: inmediatamente, o solo después de 3, 5, 15, 30 o 60 minutos, o de 3, 6, 12 o 24 horas de fallo continuo. Las alertas salen por los nueve canales de notificación que soporta HostTracker - correo electrónico, SMS, llamada de voz, webhook, Slack, notificaciones push y las apps de mensajería Telegram, Discord y Viber - y llega un aviso de recuperación cuando el flujo vuelve a completarse.
Una verificación de transacción es el monitor más potente que ofrece HostTracker y el que tiene más restricciones del mundo real. Conocerlas de antemano te ahorra una tarde.
Los dos enfoques responden preguntas distintas, y un equipo que entiende la diferencia deja de esperar que uno haga el trabajo del otro. HostTracker es un servicio de monitoreo sintético de sitios web: genera el tráfico él mismo, desde sus propios puntos de verificación, según el horario que tú controlas.
| Monitoreo sintético de transacciones | Monitoreo de usuario real | |
|---|---|---|
| Quién genera el tráfico | El servicio de monitoreo, en un horario fijo | Tus visitantes reales, siempre que lleguen |
| Funciona antes de tener tráfico | Sí - un sitio de staging sin usuarios igual se verifica | No - sin visitantes, sin datos |
| Nota una rotura a las 3 de la madrugada | Sí - el horario no duerme | No, hasta que alguien aparezca |
| Nombra el paso exacto que falló | Sí - el escenario es determinista | Rara vez - ves el síntoma, no la secuencia |
| Refleja lo que experimentaron los clientes reales | No - es una muestra controlada | Sí - ese es todo el sentido |
| Requiere código en tu sitio | No - se ejecuta enteramente desde fuera | Un script o SDK en cada página |
| Cubre un flujo que los clientes rara vez completan | Sí - tú eliges qué se ejercita | No - los caminos poco frecuentes quedan sin medir |
Si lo que buscas a continuación es la mitad de tiempos en lugar de la mitad de flujo, HostTracker también mide cargas de página en un navegador real - mira el monitoreo de tiempos de carga en navegador - y para el equivalente máquina a máquina de una transacción, una verificación de monitoreo de API valida el contrato de la respuesta en lugar de la página renderizada. Del lado del servidor, un monitor de consultas de base de datos a menudo explica por qué un flujo se volvió lento en primer lugar.
El monitoreo de transacciones de un sitio web es una verificación que automatiza un flujo de usuario real de varios pasos - como completar un formulario, iniciar sesión, añadir un artículo al carrito o finalizar una compra - y comprueba que cada paso se ejecute correctamente y que toda la secuencia produzca el resultado esperado. A diferencia de una verificación simple que solo confirma que una página carga, el monitoreo de transacciones sigue el mismo camino que recorrería un visitante real, enviando datos y navegando por las páginas en orden, y luego valida el resultado según las reglas que definas. Esto importa porque un sitio web puede parecer perfectamente saludable según todas las métricas simples de disponibilidad - la página de inicio carga, las páginas individuales devuelven código 200 - mientras un proceso crítico de varios pasos, como el checkout, está roto silenciosamente a mitad de camino. El monitoreo de transacciones de HostTracker está diseñado específicamente para detectar ese tipo de fallo.
El monitoreo de transacciones de HostTracker puede automatizar y validar una amplia gama de interacciones del sitio web, incluyendo el envío de formularios, clics en botones y redirecciones entre páginas, que en conjunto reproducen cómo un usuario real se mueve por tu sitio. Esto cubre escenarios habituales como completar un registro o un inicio de sesión, enviar un formulario de contacto o de captación de leads, y procesos de compra de varios pasos, como añadir artículos al carrito y avanzar por el checkout. Como la verificación simula el comportamiento real del usuario paso a paso en lugar de simplemente cargar una página, puede validar que cada etapa del proceso funcione realmente y produzca el resultado esperado, no solo que las páginas involucradas carguen. Esto lo hace útil para cualquier sitio web donde un flujo interactivo roto - no solo una página rota - te cueste leads, registros o ventas.
El monitoreo básico de disponibilidad (uptime) comprueba si una sola página o endpoint responde y devuelve un código de estado normal, lo cual indica que el servidor es accesible, pero no dice nada sobre si un proceso de varios pasos construido sobre él realmente funciona. El monitoreo de transacciones va más allá: automatiza toda una secuencia de pasos - enviar un formulario, navegar por varias páginas, completar un flujo de compra - y valida que cada paso se complete con éxito y que el proceso de principio a fin produzca el resultado correcto. Un sitio web puede pasar todas las verificaciones de disponibilidad mientras su proceso de checkout está completamente roto en el paso de pago, porque cada página individual sigue cargando bien de forma aislada; solo una verificación que realmente recorra la transacción detectaría eso. Para cualquier sitio donde las conversiones dependan de un flujo de varios pasos, el monitoreo de transacciones cubre una categoría de fallos que el monitoreo básico de disponibilidad simplemente no puede ver.
Sí, este es uno de los casos de uso principales del monitoreo de transacciones. Las verificaciones de transacciones de HostTracker recorren una secuencia definida de pasos - como añadir un artículo al carrito, avanzar al checkout, completar los campos obligatorios y llegar a una página de confirmación - y validan que cada paso se complete según lo esperado en el camino. Esto significa que cualquier fallo introducido en el flujo, ya sea un botón de "añadir al carrito" roto, un error de validación en un formulario o una página de checkout que no carga tras una implementación reciente, se detecta y se reporta con registros detallados que señalan el paso específico que falló. Detectar este tipo de problema rápidamente es importante porque un paso de checkout roto cuesta ventas directamente, y puede pasar inadvertido durante mucho tiempo para las verificaciones simples de disponibilidad, ya que las páginas individuales involucradas pueden seguir devolviendo códigos de estado normales.
Cuando un paso de una verificación de transacción falla - un formulario no se envía, una página esperada no carga o no se cumple una regla de validación - HostTracker registra el punto exacto del fallo y envía una alerta a través de tus canales de notificación configurados, de modo que sepas no solo que algo se rompió, sino en qué punto del flujo ocurrió. La alerta va acompañada de registros y reportes detallados, que le dan a los administradores el paso específico y el resultado necesarios para investigar rápidamente, en lugar de tener que recorrer manualmente todo el flujo. Este nivel de detalle por paso es lo que hace que el monitoreo de transacciones sea realmente útil para resolver problemas con rapidez: saber que "el checkout está roto" es mucho menos accionable que saber que el fallo ocurre específicamente en el paso de confirmación de pago tras un cambio reciente en particular, lo cual acota considerablemente la causa probable.
No. Aunque los flujos de compra de varios pasos son un ejemplo habitual, el monitoreo de transacciones es útil para cualquier sitio web donde una secuencia de acciones del usuario - y no solo la carga de una página - necesite funcionar correctamente. Esto incluye flujos de registro e inicio de sesión de aplicaciones SaaS, formularios de contacto o de captación de leads para negocios de servicios, procesos de solicitud de varias páginas, y cualquier recorrido del sitio donde un enlace roto o un envío de formulario fallido a mitad de camino impida que un visitante complete lo que vino a hacer. Cualquier proceso interactivo donde perder a un usuario a mitad de camino tenga un costo real - un registro perdido, un formulario de leads abandonado, una solicitud incompleta - se beneficia de tener ese flujo específico automatizado y verificado regularmente, en lugar de asumir que sigue funcionando solo porque las páginas individuales cargan sin errores.
Una verificación de transacción se ejecuta en un intervalo que eliges entre 10 minutos y 24 horas - 10, 15, 30 y 45 minutos, luego 1, 2, 4, 6, 12 y 24 horas. El mínimo es más alto que el de un minuto que ofrece HostTracker para las verificaciones HTTP simples, y es así de forma deliberada: una verificación de transacción abre un navegador real, carga la página con su JavaScript y recorre tu escenario paso a paso, lo cual toma segundos de trabajo real en lugar de una sola solicitud. El patrón habitual es combinar ambas: una verificación HTTP o de ping cada minuto responde "¿el sitio es accesible ahora mismo?", y una verificación de transacción cada 10 o 15 minutos responde la pregunta más difícil de si el checkout, el login o el flujo de registro detrás de él siguen completándose. Esa combinación detecta una caída total en un minuto y un flujo roto dentro de un ciclo de verificación, sin ejecutar una sesión de navegador contra tu aplicación cada sesenta segundos.
No, y no deberías hacerlo. Una verificación de transacción envía formularios reales contra tu sitio real, así que la configuración correcta es una cuenta de prueba dedicada, un producto o SKU de prueba y, si el flujo llega al pago, el modo sandbox o de tarjetas de prueba de tu proveedor de pagos, exactamente como lo harías para cualquier prueba automatizada de extremo a extremo. Muchos equipos detienen el escenario monitoreado un paso antes de la acción irreversible: llegan a la página de pago, verifican que se haya renderizado con el total correcto y terminan ahí. Eso sigue demostrando que cada paso hasta el punto de venta funciona, sin crear un pedido cada diez minutos. La misma regla se aplica a los flujos de registro y captación de leads: apunta el escenario a un formulario de prueba, o filtra los envíos del monitor de tu lado, para que el tráfico de monitoreo nunca contamine tus datos reales.
Inicia una prueba gratuita y monitorea tus flujos de usuario críticos - login, búsqueda, checkout - las 24 horas del día.
Forma parte del software de monitorización web de HostTracker.