La semana pasada una empresa del Fortune 500 perdió alrededor de 14 millones de dólares en unas seis horas porque un único certificado SSL caducó en silencio y nadie se dio cuenta hasta que los clientes empezaron a quejarse en Twitter. El email de renovación se había enviado. Llegó a una bandeja compartida que antes gestionaba el responsable de DevOps anterior. Se marchó en marzo. El certificado caducó un sábado a las 02:14 UTC. El ingeniero de guardia del equipo de plataforma no recibió ningún aviso porque, técnicamente, nada estaba "caído" — el sitio servía tráfico, solo que con un enorme aviso rojo en el navegador que ahuyentaba a cualquier cliente de pago.

No es una historia inusual. Es la caída evitable más común que vemos, y no tiene nada que ver con la arquitectura cloud ni la orquestación de contenedores. Ocurre porque la mayoría de equipos tratan la monitorización de dominios, la monitorización SSL y la monitorización de uptime como tres problemas separados resueltos por tres herramientas separadas — o, más a menudo, por nadie. Esta guía recorre el stack completo de 3 capas, qué monitorizar en cada una y cómo cablearlo todo para que no te vuelvan a pillar por sorpresa.

El stack de monitorización de 3 capas#

Cualquier propiedad web pública tiene tres modos de fallo independientes que provocan los síntomas de "el sitio está caído", pero cada uno requiere una solución completamente distinta:

Caducidad del dominio — el registro caduca, el registrador recupera el dominio y tu DNS deja de resolver. Tiempo de recuperación: horas o días. Coste: catastrófico.
Caducidad del certificado SSL — el DNS sigue resolviendo, el servidor sigue arriba, pero el certificado ha pasado su fecha notAfter. Los navegadores bloquean la conexión. Tiempo de recuperación: minutos si está automatizado, horas si es manual.
Uptime / fallo HTTP — el DNS resuelve, el cert es válido, pero el servidor devuelve un 5xx, da timeout o ha sido redirigido a una página de aparcamiento por tu hosting. Tiempo de recuperación: depende de la causa raíz.

Las tres capas son necesarias porque cada una detecta un fallo que las otras se pierden. La monitorización de uptime te dirá que el sitio está roto — pero solo después de que el cert SSL ya haya caducado y los clientes ya se hayan ido. La monitorización de dominios detecta el fallo en el registro semanas antes de que el dominio se libere. La monitorización SSL detecta el problema del cert 30 días antes de que aparezca el aviso del navegador. Apila las tres y tienes defensa por capas; sáltate una y tienes un agujero por el que cabe un camión.

Capa 1: monitorización de caducidad de dominios#

La caducidad de dominios es la caída más evitable de internet, y también la más vergonzosa. Microsoft lo ha hecho. Google lo ha hecho (dos veces). Foursquare lo hizo. Sorenson Media lo hizo. Cada una de estas fue una caída de varias horas causada por una tarjeta de crédito caducada o un email de renovación enviado a la bandeja equivocada.

Por qué los emails del registrador no son suficientes#

Los registradores envían recordatorios de renovación. Llegan al email que figuraba cuando se registró el dominio por primera vez, que suele ser el Gmail personal de un contratista que se marchó hace tres años. Incluso cuando la dirección es correcta, los emails del registrador acaban en spam con frecuencia, y aunque no acaben ahí, son idénticos a los emails de phishing que se hacen pasar por avisos de renovación, así que la gente los borra.

La auto-renovación se supone que arregla esto, pero falla en silencio de tres formas habituales:

La tarjeta de crédito guardada caduca.
La tarjeta es rechazada por fraude (las renovaciones anuales le parecen raras al banco emisor).
El interruptor de auto-renovación del registrador se desactiva durante una migración de cuenta o un rediseño del panel de control.

La monitorización externa es la única red de seguridad fiable.

Cómo monitorizar la caducidad de dominios#

El protocolo es RDAP (el reemplazo moderno de WHOIS) con un fallback a WHOIS para los TLDs que aún no soportan RDAP. Una comprobación diaria es suficiente — las fechas de caducidad no cambian minuto a minuto, y los registradores aplican sus propios periodos de gracia encima de lo que publiques.

# Comprobación manual rápida desde la línea de comandos
curl -s "https://rdap.org/domain/example.com" | jq '.events[] | select(.eventAction=="expiration")'

Mete eso en un cron y tienes un monitor básico. Pero también necesitas umbrales de alerta, lógica de reintento para fallos transitorios de WHOIS y una forma de detectar la diferencia entre "caducado" y "renovado pero la fecha aún no se ha propagado". Por eso, normalmente, una herramienta hospedada es más rápida que construirla.

La cadencia de alertas 30/14/7/2 días#

Envía alertas en cuatro puntos: a 30 días (planificación), a 14 días (acción), a 7 días (escalado) y a 2 días (pánico). Más frecuente genera fatiga. Menos frecuente no deja margen si la primera alerta se pierde.

Qué significa "caducado" en realidad#

Los dominios no se liberan en el segundo en que caducan. La mayoría de TLDs tienen una cronología en varias fases:

Día 0–30 tras la caducidad: periodo de gracia. El dominio está suspendido (sin DNS) pero el titular puede renovarlo al precio normal.
Día 30–60: periodo de redención. La renovación sigue siendo posible pero con una tasa de redención de 80–200 $.
Día 60–90: pendiente de borrado. El dominio está bloqueado y no se puede renovar.
Día 90+: liberado. Cualquiera puede registrarlo.

Si un dominio tuyo entra en redención, probablemente vas a pagar pero aún puedes recuperarlo. Una vez está pendiente de borrado, estás compitiendo contra drop-catchers profesionales. No dejes que llegue ahí.

Nova Uptime tiene un comprobador gratuito de caducidad de dominio para consultas puntuales, y el dashboard ejecuta RDAP a diario sobre cada dominio monitorizado con la cadencia 30/14/7/2 días incorporada.

Capa 2: monitorización de certificados SSL#

La caducidad de certificados SSL es, con diferencia, la causa más común de caídas tipo "el sitio está caído". Microsoft Teams se cayó en febrero de 2020 por un certificado de auth caducado. Microsoft Azure tuvo una caída de varias horas en 2021 por la misma causa. Spotify lo ha hecho. LinkedIn lo ha hecho. Google Voice lo ha hecho. El hilo común: la rotación cada 90 días de Let's Encrypt ha entrenado a toda la industria a esperar automatización, y cuando la automatización se rompe, lo hace en silencio.

Qué monitorizar realmente en un certificado#

Un certificado tiene más modos de fallo que solo notAfter. Un monitor completo comprueba:

notBefore y notAfter — la ventana de validez. Alerta a 30, 14, 7 y 2 días antes de notAfter.
Cadena del emisor completa — tu servidor debe servir la cadena intermedia completa. Un bug de despliegue habitual es enviar solo el certificado leaf; funciona en Chrome (que cachea intermedios) pero falla en Firefox, navegadores móviles y la mayoría de clientes de API.
Coincidencia de Subject y SAN — los Subject Alternative Names del certificado deben incluir el hostname solicitado. Los certs wildcard están bien pero asegúrate de que el wildcard cubre realmente el subdominio que estás golpeando.
Cipher suite y versión TLS — TLS 1.0 y 1.1 están deprecados. TLS 1.2 es el suelo; TLS 1.3 es lo preferido. Los ciphers débiles (RC4, 3DES) deberían hacer que tu check falle.
Presencia de OCSP staple — si has configurado OCSP stapling y deja de funcionar, verás avisos del navegador incluso con un cert válido.

Modos de fallo SSL habituales#

En orden aproximado de frecuencia, los fallos que vemos en producción:

Certificado caducado. El hook de auto-renovación no se disparó. Murió el cron. La renovación tuvo éxito pero el nuevo cert no fue recargado por el servidor web.
Certificado intermedio ausente o incorrecto. Certbot genera la cadena pero un script de despliegue la sobrescribe, o un proxy inverso está configurado con ssl_certificate en vez de ssl_certificate fullchain.pem.
Hostname mismatch. El cert se emitió para example.com pero el usuario está accediendo a www.example.com y el SAN no incluye www.
Cert incorrecto servido (bug de SNI). El servidor aloja varios sitios y se sirve el cert por defecto del vhost en lugar del cert por sitio.
Deriva del reloj. El reloj del servidor lleva más de unos minutos de retraso, haciendo que certs válidos parezcan caducados o aún no válidos.

Frecuencia de comprobación recomendada#

Diaria es el mínimo. Para endpoints críticos para ingresos — APIs de pago, flujos de login, widgets embebidos — cada hora es razonable. La comprobación es barata (un único handshake TLS por endpoint) así que la frecuencia rara vez es el cuello de botella.

Desastres SSL del mundo real#

El patrón se repite cada año:

Microsoft Teams, feb 2020 — un certificado interno caducado tumbó Teams durante horas en plena jornada laboral.
Microsoft Azure, marzo 2021 — la caducidad de un cert TLS provocó una caída de 14 horas que afectó a la autenticación en varias propiedades de Microsoft.
Spotify, varios años — los certificados caducados han causado al menos tres caídas públicas.
Página de status de GitHub — en algún momento la propia página de status sirvió un cert caducado, lo cual es la clase de ironía que hace reír nerviosamente a los ingenieros.

A ninguna de estas empresas le faltaba talento de ingeniería para evitar la caducidad. Les faltaba la monitorización por capas que la habría detectado. El comprobador gratuito de caducidad SSL de Nova Uptime hace una comprobación puntual; el dashboard ejecuta el mismo check programado y alerta a 30/14/7/2 días.

Capa 3: monitorización de uptime / HTTP#

La monitorización de uptime es la capa que captura todo lo que las dos primeras no pueden anticipar: caídas del servidor, despliegues mal hechos, fugas de memoria, agotamiento del pool de conexiones de base de datos, DDoS, problemas del hosting, mala configuración DNS, envenenamiento de caché del CDN y los otros cincuenta modos de fallo que no aparecen en un cert ni en el registro del registrador.

Qué comprobar#

Un monitor HTTP útil comprueba más que solo "¿la petición devolvió 200?". En concreto:

Código de estado — cualquier 2xx es saludable, 3xx puede ser una redirección a una página de aparcamiento (sospechoso), 4xx y 5xx son fallos.
Tiempo de respuesta — la latencia p95 subiendo es el indicador adelantado de un problema de base de datos o CPU.
Contenido del cuerpo de respuesta — idealmente, comprueba una cadena conocida-buena (un endpoint de heartbeat que devuelve {"status":"ok"}) para que captures el caso en que el servidor devuelve 200 pero la aplicación está caída y sirve una página de error.
Éxito del handshake TLS — pliega parte de la capa 2 dentro del mismo check.
Tiempo de resolución DNS — una resolución DNS lenta suele ser el primer indicio de un problema de CDN o de upstream.

Por qué importa multi-región#

Un monitor de una sola región es una máquina de falsa confianza. Tu monitor vive en us-east-1. Tu aplicación también. AWS tiene un problema regional. Ambos caen. Tu monitor reporta "sitio arriba" porque el monitor está muerto. La monitorización multi-región (o, como mínimo, monitorización cross-región — monitoriza en us-west si tu app está en us-east) elimina esta clase de falso negativo.

Captura capturas de pantalla de los fallos#

Cuando un check falla, haz una captura de la página renderizada. Vale su peso en oro durante los post mortems porque captura exactamente lo que el usuario vio en el momento del fallo — no lo que dicen los logs, no lo que cree el monitor sintético, sino lo que había en la pantalla. ¿Era un 502? ¿Una página de mantenimiento? ¿Una pantalla en blanco? ¿Un challenge de Cloudflare? Lo sabrás en dos segundos en lugar de en dos horas.

Alertas multicanal#

El email es necesario pero no suficiente. El email se acumula, se agrupa y se ignora. Las alertas críticas necesitan saltarse el email y llegar a un humano directamente. Nova Uptime soporta email, WhatsApp (Baileys, sin coste por mensaje) y webhooks salientes (firmados con HMAC) para integrarse con PagerDuty, Opsgenie, Slack o lo que sea que uses para incidentes.

Configurar el stack completo con Nova Uptime#

Aquí tienes la configuración práctica, de principio a fin, en el orden aproximado en que la harías.

1. Añade el dominio#

Pega la URL en el dashboard. Nova Uptime ejecuta una comprobación HTTP inmediata, un handshake SSL, una consulta RDAP/WHOIS para la caducidad del dominio y una descarga del favicon. Ves los cuatro resultados en menos de 60 segundos.

2. Configura el intervalo de comprobación#

Plan Free: intervalo de 15 minutos. Plan Pro: hasta 59 segundos. Plan Agency: el mismo suelo de 59 segundos con límites de dominio más altos. Para la mayoría de sitios de marketing, comprobaciones cada 5 minutos están bien. Para APIs de pago, comprobaciones cada 59 segundos son lo correcto.

3. Conecta WhatsApp#

En Settings → WhatsApp, escanea el código QR una vez. A partir de ahí, cualquier alerta puede enviarse a tu número de WhatsApp sin coste por mensaje (Plan Free = 1 número, Pro = 3, Agency = 5). La entrega por WhatsApp es más rápida y más difícil de ignorar que el email.

4. Añade emails CC para el equipo#

En la página de configuración de cada dominio, añade hasta 5 emails CC. Es la lista de distribución del equipo para ese dominio concreto — la home puede alertar al responsable de marketing, la API puede alertar al ingeniero de guardia.

5. Prueba las alertas con un fallo deliberado#

Lo mejor que puedes hacer tras cablear la monitorización es romperla deliberadamente una vez. Apunta una URL monitorizada a un hostname que no exista, o revoca temporalmente el cert, y mira cómo se dispara la alerta. Si no se dispara, acabas de descubrir un bug de configuración al precio más bajo posible.

6. Sabe cuándo upgradar#

El plan gratuito cubre 5 dominios y es suficiente para proyectos personales y equipos pequeños. Las dos razones para hacer upgrade son: (a) has superado los 5 dominios, o (b) necesitas intervalos de comprobación por debajo de 15 minutos. Detalles en la página de precios.

Estrategia de alertas: evitar la fatiga#

La forma más rápida de arruinar un stack de monitorización es alertar de más. Tras tres falsos positivos en una semana, todos los ingenieros del equipo empiezan a ignorar el canal, y ahora tienes una monitorización con valor negativo.

Tres reglas generales:

Severidad por niveles. Avisos de caducidad de dominio a 30 días son informativos — solo email. Avisos SSL a 7 días son advertencias — email más un canal de Slack. Sitio caído 2+ minutos es crítico — WhatsApp, móvil vibrando, paging al de guardia. No envíes todo por todos los canales.

Pausa durante mantenimientos planificados. Si estás desplegando, ejecutando una migración de base de datos o rotando un cert, pausa el monitor relevante durante la ventana de mantenimiento. Nova Uptime tiene pausa por dominio y un toggle global "pausar todas las notificaciones" en Settings. (La monitorización continúa — solo se pausan las notificaciones, así que puedes revisar los logs después.)

Limita las alertas de "sigue caído". Una vez que un dominio se ha reportado como caído, no necesitas una notificación cada minuto. Nova Uptime envía la alerta inicial y luego recordatorios cada hora (por email y WhatsApp) hasta que el dominio se recupera. La alerta de recuperación siempre se dispara al instante.

Enruta por canal. El email es bueno para resúmenes, informes semanales y alertas informativas. WhatsApp es bueno para alertas críticas que necesitan un humano en los próximos 5 minutos. Los webhooks son buenos para automatización (auto-creación de incidencias en PagerDuty, posts en Slack, disparo de runbooks).

Casos de desastre del mundo real#

Algunos casos notables que conviene conocer:

LinkedIn, octubre 2022 — caducidad SSL de varias horas en un subdominio que afectó a la entrega de mensajes. El sitio principal siguió arriba; el problema quedó enmascarado hasta que los clientes lo reportaron.
Cloudflare, 2021 — una mala configuración de la cadena intermedia provocó problemas generalizados en sitios usando el servicio de cert edge de Cloudflare. El leaf cert era válido; la cadena estaba incompleta.
GitHub Status, varias incidencias — la propia página de status, en distintos momentos, ha servido certs caducados o ha tenido problemas de registro de dominio. La lección es que la meta-monitorización (lo que te dice cuándo la monitorización está rota) también es algo que necesita monitorización.

Checklist de configuración#

Repasa esta lista y tendrás defensa por capas:

Conclusión#

La monitorización de dominios, las alertas SSL y la monitorización de uptime no son tres herramientas que se unen con cinta americana. Son tres capas de una estrategia única de defensa en profundidad, y cualquier stack de monitorización que cubra solo una o dos de ellas acabará fallándote en el peor momento posible. Nova Uptime te da las tres en un solo dashboard con alertas por email y WhatsApp en el plan gratuito. Regístrate gratis y monitoriza hasta cinco dominios en menos de cinco minutos.

Lecturas relacionadas#

Monitorización de uptime para aplicaciones SaaS — playbook de monitorización multi-tenant para equipos SaaS
Guía de configuración de política DMARC — el complemento del lado email a la monitorización de dominios
Comprobador gratuito de caducidad SSL — análisis puntual de certificado
Comprobador gratuito de caducidad de dominio — consulta RDAP/WHOIS con estado del periodo de gracia
Comprobador gratuito de salud de email — asegúrate de que tus emails de alerta llegan de verdad

Monitorización de dominios con alertas SSL: la guía de configuración completa para 2026