Una guía práctica para monitorear un sitio web con AWS Lambda, CloudWatch, alarmas y dashboards, incluyendo qué hacer cuando no existe un endpoint de salud formal.
Muchas veces el monitoreo de un sitio web se imagina como algo pesado: agentes instalados, servidores dedicados, herramientas caras o stacks demasiado grandes para un problema que, en esencia, consiste en responder una pregunta bastante concreta: ¿el sitio está sano o no?
En AWS, una forma especialmente limpia de resolver esto es usando AWS Lambda junto con CloudWatch. La lógica es simple: una función se ejecuta cada cierto tiempo, consulta el sitio o una API de salud, interpreta el resultado y publica métricas. Luego CloudWatch transforma esas métricas en alarmas, histórico y dashboards.
Este enfoque tiene varias ventajas prácticas. Es serverless, opera sobre componentes muy estables, escala sin esfuerzo y no obliga a mantener una máquina prendida solo para hacer chequeos repetitivos. Para monitoreo liviano o intermedio, suele ser una solución muy sana.
Dicho de otra forma: Lambda no solo sirve para saber si una URL responde, sino también para verificar si responde como debería. Y esa diferencia importa mucho. Un sitio puede devolver código 200 y aun así estar roto desde el punto de vista del negocio.
Si el sitio o aplicación tiene un endpoint como /health, /status o similar, el trabajo se vuelve mucho más limpio. Esa ruta puede responder información útil sobre el estado del sistema: conectividad a base de datos, acceso a dependencias externas, cola de mensajes, latencia o versión desplegada.
En ese caso, la Lambda puede ejecutarse una vez por minuto —o con la frecuencia que tenga sentido—, consultar ese endpoint, leer su respuesta JSON y transformar esos datos en métricas concretas dentro de CloudWatch.
Una regla programada ejecuta la función cada minuto, cada cinco minutos o según la sensibilidad operacional que necesites.
La función hace una llamada HTTP, mide tiempo de respuesta y valida que el contenido recibido tenga la forma esperada.
Por ejemplo: disponibilidad, tiempo de respuesta, salud de base de datos o estado de un componente específico.
Sobre esas métricas se construyen alarmas, tableros, notificaciones y series históricas para detectar degradación antes de que el problema explote.
No todos los sitios tienen una API de salud formal. Y en muchos proyectos heredados, pedirla no siempre es inmediato. En esos casos, una alternativa muy útil es monitorear una página que sea representativa del funcionamiento real del sistema.
La recomendación de VRWEB es elegir una página que dependa de las piezas importantes del sitio. Idealmente, una vista que no solo responda desde el servidor web, sino que también requiera acceso a base de datos u otra dependencia central. Luego la Lambda lee el HTML o la respuesta y busca un string conocido que solo aparece cuando todo está operando correctamente.
Esto parece simple, pero tiene mucho valor operativo. Permite detectar un caso frecuente: el servidor web sigue arriba, pero el motor de base de datos cayó, se degradó o devolvió un error silencioso. Desde fuera, el sitio “abre”; desde el negocio, está roto.
La clave es entender que el monitoreo debe parecerse a una prueba mínima de usuario real. No solo verificar que “algo” contestó, sino que la respuesta tenga sentido desde el punto de vista funcional.
Una vez que la Lambda publica indicadores en CloudWatch, aparece la segunda mitad del sistema: convertir observación en reacción. Ahí entran las alarmas. Puedes levantar alertas cuando la disponibilidad cae a cero, cuando el tiempo de respuesta supera un umbral, o cuando el string esperado deja de aparecer durante varios chequeos seguidos.
Esas alarmas pueden gatillar distintas acciones: correos, SMS, webhooks, eventos internos o integraciones con plataformas de incidentes. Lo importante no es solo avisar, sino avisar con criterio. Una alarma demasiado sensible genera ruido. Una demasiado laxa llega tarde.
Otro valor importante de CloudWatch es que no se queda solo en la alarma puntual. También permite construir dashboards para observar comportamiento a lo largo del tiempo. Eso ayuda a ver degradaciones lentas: un sitio que no cayó, pero que empezó a responder más lento; una página que intermitentemente falla; una dependencia que se vuelve inestable ciertas horas del día.
En operación real, esa mirada histórica es muy valiosa. Muchas veces el problema no se presenta como caída total, sino como deterioro gradual. Y esos patrones son precisamente los que un buen dashboard deja ver con claridad.
La portada puede estar cacheada o responder bien aunque partes críticas del sistema estén caídas. Elige una vista que realmente pruebe algo importante.
Usar ventanas de evaluación con dos o tres fallos consecutivos suele reducir mucho los falsos positivos.
Una cosa es que la URL responda; otra es que responda con contenido correcto. Ambas dimensiones deberían medirse por separado.
La notificación debería decir qué URL falló, qué validación se incumplió y desde cuándo, para que la respuesta del equipo sea más rápida.
Este enfoque es excelente para monitoreo externo y funcional, pero conviene combinarlo con logs, métricas de infraestructura y monitoreo de aplicación cuando la criticidad del sistema lo amerita.
Monitorear un sitio web con AWS Lambda y CloudWatch es una solución elegante, serverless y muy práctica. Permite ejecutar chequeos frecuentes, validar endpoints o páginas reales, guardar indicadores, construir alarmas útiles y observar tendencia en dashboards.
Y quizás lo más importante: ayuda a monitorear el sitio como lo vive el negocio, no solo como lo ve el servidor. Esa diferencia es la que convierte un chequeo técnico en monitoreo realmente útil.
En VRWEB podemos ayudarte a diseñar monitoreo práctico, alarmas útiles y tableros que realmente sirvan para operar mejor, sin complejidad innecesaria.