Qué es realmente la monitorización web
En lo más simple, la monitorización web es un check externo: una petición enviada a tu sitio desde fuera de tus servidores, en un intervalo repetido, buscando una señal concreta, normalmente una respuesta 200 en tiempo razonable. Ese check ya detecta el fallo común de servidor inalcanzable, timeout o página de error.
La monitorización real va más allá del ping arriba/abajo. Revisa tiempo de respuesta, certificado TLS, DNS y cada vez más el contenido de la respuesta, porque un 200 con un error en el cuerpo sigue siendo una página rota.
El objetivo no son checks exóticos. Es comprobar desde fuera de tu infraestructura, con un horario suficientemente estrecho para detectar una caída en minutos y no por un ticket de soporte.
Qué monitorizar primero
Si empiezas de cero, monitoriza en este orden: la homepage y cualquier URL que un cliente visite directamente, caducidad TLS, caducidad del dominio, DNS y cualquier endpoint de API del que dependa otro servicio.
Un sitio con una URL principal, TLS y dominio cubre gran parte de lo que puede romperse en silencio. DNS, registros de autenticación de email e rutas API individuales se añaden cuando lo básico ya está cubierto.
La checklist de monitorización en producción
Usa esto como primera checklist de producción para un sitio pequeño o una app SaaS. No necesitas todos los monitores posibles el primer día; necesitas cubrir los fallos que harían que un cliente te escriba primero.
1. Alcance público: monitoriza la homepage o la URL principal de marketing desde fuera de tu infraestructura. Esto detecta fallos de DNS, caídas del servidor, deploys rotos y errores de routing que hacen desaparecer todo el sitio.
2. Ruta del cliente: monitoriza la URL que un usuario de pago necesita más — login, checkout, dashboard, flujo de reserva o endpoint de salud de API. La homepage puede estar verde mientras la ruta que genera ingresos está rota.
3. Señales de confianza: monitoriza vencimiento TLS, vencimiento del dominio, redirecciones y DNS. Son aburridas hasta el día en que fallan, y entonces navegadores, proveedores de email o clientes te bloquean antes de que tu código siquiera corra.
4. Trabajo interno silencioso: añade monitores heartbeat para crons, colas, importaciones programadas y backups. Los checks externos no pueden ver un worker de cola que murió el viernes o un backup que dejó de correr hace tres semanas.
5. Dueño de la alerta: envía alertas a una persona o canal que de verdad se mire, exige fallos consecutivos antes de avisar y deja escrito quién es dueño del monitor. Un monitor sin dueño es solo un registro.
6. Comunicación con clientes: si los clientes dependen del servicio, conecta los monitores a una status page. Cuando el sitio cae, una página de incidente clara ahorra soporte y muestra que alguien ya está trabajando en el problema.
Reglas de alerta que no gritan “lobo”
La forma más rápida de volver inútil la monitorización es alertar por el primer check fallido. Las redes tienen parpadeos transitorios que no significan que tu sitio esté caído; un fallo aislado desde una ubicación de sondeo es ruido normal, no un incidente.
Una regla práctica: exige dos o tres fallos consecutivos, idealmente desde más de una ubicación de sondeo, antes de alertar. Convierte “ruidoso e ignorado” en “raro y fiable”. Combínalo con un intervalo acorde a cuánto downtime puedes tolerar: cada 5 minutos para sitios de cara a clientes, cada 15 a 30 para herramientas internas.
Las alertas de tiempo de respuesta necesitan su propio umbral, separado del check arriba/abajo; un sitio “activo” que tarda 8 segundos en responder sigue siendo un problema real.
Errores que dejan pasar caídas
Monitorizar solo la homepage. Si checkout, login o tu API son rutas separadas, una caída limitada a una de ellas no aparece en un check de homepage.
Comprobar desde una sola ubicación. Un único punto no distingue “mi sitio está caído” de “esta ruta de red está caída”. Varias ubicaciones de sondeo lo descartan.
Nadie es dueño de las alertas. Un monitor que avisa a un Slack que nadie lee o a una bandeja filtrada no es monitorización; es un registro posterior. Las alertas necesitan destino y responsable reales.
Tomar “sin alerta” como “todo va bien”. Un monitor mal configurado, pausado o que no se ejecuta se parece a un sitio sano hasta que importa. Por eso los heartbeats importan junto a checks externos: confirman que lo que debe reportarse sigue reportándose.
Cómo lo hace Holter
Holter ejecuta checks externos de uptime, tiempo de respuesta, TLS, DNS y señales relacionadas desde varias ubicaciones de sondeo, y los combina con monitores heartbeat para lo que falla en silencio, como crons, colas y backups que dejan de correr.
El plan Free es realmente gratuito: 5 monitores, checks cada 5 minutos y sin tarjeta. Alcanza para cubrir hoy las URLs principales, TLS y dominio de un sitio real, y comprobar si las alertas encajan con cómo trabaja tu equipo antes de pagar.
Holter vigila esto por ti: monitores externos y heartbeats para fallos silenciosos. Plan gratis: 5 monitores, comprobaciones cada 5 minutos, sin tarjeta.
Crear mi primer monitor gratis