Un sitio puede responder HTTP 200 mientras el formulario de contacto está roto, el certificado está a punto de vencer o un despliegue entrega una pantalla vacía en cierta región. La monitorización sintética ayuda a detectar esos casos repitiendo desde fuera de la aplicación un recorrido pequeño y seguro, y registrando lo que vería una persona visitante.
Empieza por la página pública y el recorrido de mayor valor: el contacto del portfolio, la pantalla de acceso de un cliente o una lectura de API sin efectos secundarios. Comprueba estado, contenido esperado, destino de redirección, validez TLS y un límite de respuesta. Las pruebas con navegador también detectan errores de JavaScript y recursos ausentes, pero cuestan más y requieren selectores resistentes. Un enfoque por capas combina HTTP frecuente con un recorrido de navegador más ocasional.
| Señal | Qué indica | Conclusión errónea habitual |
|---|---|---|
| DNS y TLS | Resolución y certificado vistos desde esa región | “Todo el sitio cayó” tras un problema aislado de resolución |
| Estado y contenido HTTP | Alcance y respuesta básica esperada | “Funciona” porque respondió un 200 genérico |
| Recorrido en navegador | Renderizado e interacción críticos | “El backend está sano” porque la interfaz cargó |
| Coincidencia regional | Si el síntoma se repite en puntos independientes | “No hay incidente” porque pasó la región más cercana |
Muestra juntos el último éxito, el último fallo, la región, la versión de la prueba y la revisión desplegada. Separa las distribuciones de latencia de la disponibilidad y representa los datos ausentes de forma distinta a los saludables. Un gráfico vacío no es un gráfico verde.
Para un portfolio con poco tráfico, una comprobación cada cinco minutos puede bastar; el intervalo depende del tiempo de detección deseado y del coste. Un fallo aislado puede generar un evento de diagnóstico, pero normalmente una alerta urgente debería exigir repetición o coincidencia entre regiones independientes. Avisa también de la recuperación y agrupa duplicados durante el incidente. No alertes por cada muestra lenta si no existe impacto relevante.
Usa cuentas sintéticas, permisos mínimos y acciones de solo lectura. No envíes formularios reales de contacto repetidamente; dirige los envíos de prueba a un destino aislado o utiliza un endpoint de salud dedicado. No incluyas credenciales ni datos personales en URLs, capturas o registros. Las grabaciones del navegador pueden contener cookies y contenido privado.
Si el monitor se ejecuta solo en la misma cuenta de alojamiento que el sitio, una caída del proveedor puede silenciar ambos. Guarda los resultados fuera o usa ejecución independiente. Configura timeouts, reintentos y límites para que una página bloqueada no consuma un worker indefinidamente. Vigila la frescura del monitor: una sonda retrasada o ausente indica degradación de la monitorización, no disponibilidad supuesta.
Empieza con un verificador HTTP, un recorrido de navegador para una ruta crítica, almacenamiento sencillo de series temporales y alertas enlazadas a evidencia diagnóstica. Registra estado, duración, región, aserción y revisión desplegada. Usa la sonda para abrir un incidente, no para reiniciar o cambiar producción automáticamente antes de entender los falsos positivos. La monitorización sintética responde “¿funciona este recorrido desde aquí y ahora?”; la telemetría interna ayuda a explicar por qué.
Para ampliar el diseño de alertas, consulta observabilidad con presupuesto limitado y postmortems para desarrolladores en solitario.
Una monitorización sintética útil comprueba un resultado que importa al cliente, se ejecuta desde un punto independiente y presenta evidencia con contexto de frescura y despliegue. Mantén las sondas seguras, distingue el ruido puntual del impacto sostenido y muestra la ausencia del monitor de forma distinta al éxito.