Monitorización web: enterarse antes que sus clientes
La monitorización de disponibilidad responde a una pregunta: ¿responde la portada? Casi todos los fallos reales son más silenciosos que eso. El sitio está en pie y el formulario de contacto lleva tres semanas fallando, o la caja funciona para todos menos para quienes usan un método de pago.
Esta guía cubre qué monitorizar, cómo fijar umbrales que signifiquen algo y cómo mantener las alertas creíbles.
Más allá de «¿está en pie?»#
Los fallos que cuestan dinero suelen ser parciales. Monitorice los resultados que le importan, no solo que el servidor responda.
| Monitor | Detecta | Frecuencia |
|---|---|---|
| Disponibilidad HTTP | Servidor caído, fallo de DNS | Cada 1–5 minutos |
| Comprobación de transacción | Formulario roto, caja rota | Cada 15–60 minutos |
| Tasa de error | Excepciones subiendo tras un despliegue | Continua |
| Caducidad del certificado | La clásica caída del domingo por la mañana | Diaria, alerta 30 días antes |
| Caducidad del dominio | La peor caída posible | Diaria, alerta 60 días antes |
| Core Web Vitals | Degradación lenta que nadie nota | Semanal |
| Cobertura de Search Console | Páginas cayéndose del índice | Semanal |
| Tamaño de disco y base de datos | Crecimiento silencioso hacia un límite duro | Diaria |
| Éxito de las copias | Copias que dejaron de ejecutarse hace meses | Diaria |
Una transacción sintética que envía un formulario real a una dirección de prueba es el monitor de mayor valor para casi cualquier sitio de empresa. Los formularios rotos son invisibles y caros.
Fijar umbrales que signifiquen algo#
Un monitor que alerta ante cualquier hipo enseña a la gente a ignorarlo, y entonces no funciona cuando importa. Los umbrales deberían reflejar lo que de verdad le haría actuar.
- Exija dos o tres fallos consecutivos antes de alertar, desde más de una ubicación.
- Alerte sobre la tasa de error en vez de sobre errores individuales: un solo 500 es ruido, un cambio de tasa es señal.
- Fije alertas de rendimiento sobre una tendencia de días, no sobre una medición lenta.
- Separe gravedades: sitio caído va a un teléfono; una página lenta va a un resumen semanal.
- Dirija las alertas a una persona, no a un buzón compartido que nadie asume.
- Revise cada alerta que se disparó: si no requirió acción, cambie el umbral o borre el monitor.
Qué hacer cuando salta una alerta#
Tener un orden de operaciones escrito convierte un incidente de improvisación en procedimiento, lo que importa sobre todo cuando quien está de guardia no es quien construyó el sitio.
- Confirme que es real: cargue el sitio usted desde otra red.
- Compruebe primero lo obvio: ¿se desplegó algo, caducó un certificado, informa el proveedor de un incidente?
- Publique una actualización de estado si hay clientes afectados. El silencio es peor que una mala noticia.
- Restaure el servicio antes de diagnosticar. Revierta el despliegue y luego investigue con calma.
- Escriba qué pasó, por qué y qué lo habría detectado antes.
- Añada el monitor que lo habría detectado. Así es como crece bien la lista anterior.
El resultado más útil de un incidente es un monitor nuevo y una forma menos de que vuelva a pasar en silencio.
Valores por defecto sensatos para un sitio pequeño#
No necesita una plataforma de observabilidad. Para casi cualquier sitio de empresa este conjunto basta y se configura en una tarde.
- Comprobación de disponibilidad en la portada y en una página profunda, cada cinco minutos, desde dos ubicaciones.
- Un envío sintético de formulario a diario, a una dirección que lea una persona.
- Alertas de caducidad de certificado y de dominio, con mucha antelación.
- Alertas de errores de servidor desde la aplicación, con un umbral de tasa.
- Un correo semanal con Core Web Vitals y cobertura de Search Console.
- Una confirmación diaria de que la copia se ejecutó y su tamaño parece normal.
Preguntas frecuentes
¿Cada cuánto debo comprobar la disponibilidad?
Cada uno a cinco minutos es lo habitual, desde al menos dos ubicaciones geográficas para que un problema de red en un nodo de monitorización no le despierte a las 3 de la madrugada. Comprobaciones más frecuentes rara vez cambian el desenlace, porque el tiempo hasta notarlo es pequeño comparado con el tiempo hasta arreglarlo.
¿Qué disponibilidad debo esperar?
Un alojamiento compartido decente da alrededor del 99,9 %, que son unas nueve horas de caída al año. Las plataformas gestionadas y las buenas configuraciones en la nube llegan al 99,95 % o mejor. Importa más que la cifra si la caída son minutos dispersos o una única caída larga en horario comercial.
¿Bastan las herramientas de monitorización gratuitas?
Para la disponibilidad de un sitio pequeño, en general sí: los planes gratuitos cubren un puñado de comprobaciones cada cinco minutos. Lo que suele faltar en los planes gratuitos son las transacciones sintéticas y las comprobaciones de varios pasos, que es justo donde está la monitorización valiosa. Reserve un pequeño presupuesto específicamente para eso.
¿Cómo evito la fatiga de alertas?
Borre los monitores que nunca han requerido acción, exija varios fallos consecutivos antes de alertar y separe el enrutamiento urgente del informativo. Después revise mensualmente las alertas disparadas. Un canal de alertas que la gente silencia es peor que no tener alertas, porque crea la creencia de que alguien está vigilando.
monitorización webmonitorización de disponibilidadmonitorización sintéticaseguimiento de erroresrespuesta a incidentesalertas web
