Monitoreo de SSL, cron y uptime: qué alertar y por qué

Muchas caídas no empiezan con un servidor apagado. Empiezan con un certificado que no se renovó, una copia de seguridad que dejó de ejecutarse hace tres semanas o un dominio que venció sin que nadie viera el aviso. Son fallos silenciosos: no hacen ruido hasta que ya afectan a los usuarios.

Un buen monitoreo no consiste en medir todo, sino en enterarse a tiempo de lo que importa y no despertar a nadie por lo que no importa.

Uptime: comprobar lo que ve el usuario

Que el servidor responda a un ping no significa que el sitio funcione. Una comprobación de disponibilidad útil se parece a lo que hace un visitante:

• Pide la URL real por HTTPS y verifica el código de estado esperado.
• Comprueba que la respuesta contiene un texto clave de la página. Un 200 con una página de error del framework o con un aviso de «cuenta suspendida» también es una caída.
• Mide el tiempo de respuesta y alerta cuando se degrada de forma sostenida, no por un pico aislado.
• Se ejecuta desde varias ubicaciones y confirma el fallo antes de avisar. Así se evitan falsas alarmas por un problema de red puntual.

Además de la portada, conviene vigilar los recorridos críticos: inicio de sesión, el endpoint de salud de la API o la página de pago, según el producto.

Certificados SSL/TLS: menos tiempo para reaccionar

Dos cambios recientes hacen que el monitoreo de certificados deje de ser opcional:

1. Let's Encrypt dejó de enviar correos de aviso de vencimiento el 4 de junio de 2025. Quien dependía de esos correos para enterarse de una renovación fallida ya no los recibe.
2. La duración máxima de los certificados públicos se está reduciendo. La votación SC-081 del CA/Browser Forum establece un calendario para bajar la validez máxima de 398 a 47 días, con reducciones escalonadas entre marzo de 2026 y marzo de 2029.

Con certificados más cortos, la renovación manual deja de ser viable: hay que automatizarla, normalmente con un cliente del protocolo ACME. Pero que la renovación esté automatizada no garantiza que funcione. Puede fallar la validación DNS, cambiar una regla del firewall o renovarse el certificado sin que el servidor web lo recargue.

Por eso hay que vigilar el certificado que realmente sirve cada dominio, conectándose a él como lo haría un navegador, y no solo el resultado de la tarea de renovación. Lo que conviene comprobar:

• Días restantes hasta el vencimiento.
• Que el certificado cubre el nombre del dominio, incluido www si se usa.
• Que la cadena de confianza está completa.

Con validez corta, los umbrales fijos como «avisar a 30 días» pierden sentido. Es más práctico alertar cuando queda menos de un tercio de la vida del certificado: ya debería haberse renovado y todavía hay margen para actuar.

Tareas programadas: vigilar la ausencia

Un cron que falla no avisa: simplemente no ocurre nada. Las copias de seguridad, la facturación nocturna o la sincronización con otro sistema pueden pasar días sin ejecutarse antes de que alguien lo note.

El patrón más fiable es el heartbeat (también llamado dead man's switch):

1. Cada tarea, al terminar con éxito, hace una petición a una URL de monitoreo.
2. El monitor sabe con qué frecuencia debería llegar esa señal y con qué margen.
3. Si la señal no llega a tiempo, alerta.

Así se detecta tanto la tarea que falla como la que ni siquiera se ejecutó porque el servidor se reinició o alguien borró la entrada del crontab. Si la tarea envía también una señal al empezar, puedes detectar ejecuciones que se quedan colgadas o que tardan mucho más de lo normal.

Para las copias de seguridad, la señal de éxito debería llegar después de verificar algo concreto, como el tamaño del archivo o una restauración de prueba, y no solo después de lanzar el comando.

Dominios: el vencimiento que nadie mira

El registro de un dominio vence, normalmente una vez al año. Si la tarjeta asociada caducó o los avisos llegan a un correo que ya nadie revisa, el sitio, el correo y todo lo que dependa de ese dominio dejan de funcionar a la vez.

Conviene vigilar:

• La fecha de vencimiento del registro, con avisos con semanas de antelación.
• Los cambios en los registros DNS importantes (A, CNAME, MX), que pueden indicar un error de configuración o un acceso no autorizado.
• Los servidores de nombres del dominio, para detectar cambios inesperados.

Qué alertar y qué no

El capítulo sobre monitoreo del libro de SRE de Google propone una idea útil: una alerta que interrumpe a una persona debe ser urgente y accionable. Si al recibirla no hay nada que hacer, o puede esperar a mañana, no debería ser una alerta de ese tipo.

En la práctica:

• Alerta inmediata: el sitio no responde desde varias ubicaciones, un certificado vence en pocos días, una copia de seguridad crítica no se ejecutó.
• Aviso diario o semanal: degradación de tiempos de respuesta, dominios que vencen en más de un mes, tareas no críticas con fallos aislados.
• Solo panel: métricas de tendencia que sirven para investigar, pero no requieren acción.

También es útil distinguir síntomas de causas. «Los usuarios no pueden iniciar sesión» es un síntoma y merece una alerta. «La CPU está al 85 %» es una posible causa: sirve para diagnosticar, pero alertar por ella suele generar ruido.

Cada alerta debería decir qué falló, desde cuándo y por dónde empezar a mirar. Una alerta que obliga a investigar desde cero cuesta minutos que no sobran.

Checklist

• Comprobaciones HTTP de las URLs críticas, con código de estado y texto esperado, desde varias ubicaciones.
• Monitoreo del certificado servido por cada dominio, no solo de la tarea de renovación.
• Renovación automática de certificados con un cliente ACME.
• Heartbeat para cada tarea programada importante, incluidas las copias de seguridad.
• Avisos de vencimiento de dominios y vigilancia de cambios DNS.
• Alertas urgentes solo para situaciones accionables; el resto, en resúmenes o paneles.
• Cada alerta llega a un canal que alguien revisa y dice por dónde empezar.