El 30 de abril de 2025, desde las 15:46 UTC, Healthchecks.io experimentó una interrupción significativa de aproximadamente treinta minutos debido a un fallo en su base de datos. Este incidente afectó la disponibilidad del servicio, generando preocupación entre los usuarios y poniendo a prueba los protocolos de manejo de crisis del equipo técnico. El análisis posterior reveló que la causa más probable fue una inestabilidad en el hardware del servidor de base de datos, derivando en un fallo crítico que llevó a la caída del servidor PostgreSQL mediante un error de segmentación (segfault) y el eventual bloqueo total del servidor, el cual dejó de responder incluso a las señales de ping. Este fallo obligó a un reinicio manual para restaurar el funcionamiento de la plataforma.
Posteriormente, se migró la base de datos a un hardware diferente con el fin de minimizar la probabilidad de que un problema similar se repitiera. Antes de la caída total, las herramientas de monitoreo detectaron anomalías en el servidor de base de datos, indicando un aumento anormal en la temperatura, en el uso de la CPU y en la actividad de entrada/salida. Estos signos, visibles en la plataforma Netdata, sugirieron que la falla no fue repentina, sino precedida por un período de inestabilidad. Diez minutos antes del bloqueo, las temperaturas del CPU mostraron picos mientras que las temperaturas de los discos NVMe descendían de manera inesperada, un comportamiento atípico que generó sospechas sobre la calidad y el estado del hardware involucrado. El momento en que comenzó el bloqueo completo del servidor coincidió con un error crítico registrado en los logs del sistema, específicamente en el proceso PostgreSQL.
Los registros indicaron un fallo de segmentación en la memoria, que impidió la ejecución correcta del motor de base de datos. Esta situación generó que el servidor dejara de responder a cualquier tipo de consulta, afectando todas las operaciones que dependían de esta base de datos. La respuesta inmediata del equipo técnico estuvo condicionada por la ubicación del responsable. En ese momento, se encontraba fuera de su estación de trabajo, lo que complicó la actuación rápida. Disponía de una laptop con herramientas de despliegue, aunque no completamente actualizadas, lo que llevó a la decisión de regresar a su computadora principal para manejar la recuperación con mayor seguridad y control.
Esta elección, aunque supuso un retardo de algunos minutos, buscó evitar errores que podrían agravar la situación. La estrategia de recuperación inicialmente contempló dos opciones. La primera fue un reinicio general del servidor problemático, con la esperanza de que esta acción restaurara su estabilidad sin necesidad de medidas más invasivas. La segunda, que se consideró pero no se ejecutó en primera instancia, consistía en promover el servidor de respaldo a primario para continuar con la operación sin interrupciones. Esta última opción comportaba el riesgo de generar un escenario de "cerebro dividido" (split-brain), donde dos servidores podrían actuar simultáneamente como principales, causando inconsistencias en los datos y problemas en la sincronización.
Finalmente, la decisión de realizar un reinicio manual fue acertada, ya que tras aproximadamente veinte minutos el servidor volvió a estar operativo y la base de datos retomó su funcionamiento normal. Sin embargo, este incidente puso en evidencia una vulnerabilidad estructural importante: la base de datos representa un punto único de fallo dentro del ecosistema. Mientras que la infraestructura cuenta con mecanismos automáticos para gestionar fallos en servidores web o balanceadores de carga, el manejo de la base de datos sigue siendo esencialmente manual y depende directamente de la intervención del equipo técnico. Consciente de esta limitación, el equipo de Healthchecks.io emprendió una pronta migración a nuevo hardware para reducir el riesgo de futuras caídas.
El proveedor de servidores empleados es Hetzner, conocido por sus servidores bare metal, los cuales ofrecen un control completo sobre el hardware dedicado. Los servidores antiguos estaban basados en modelos EX101, con procesadores Intel Core i9-13900, 64GB de memoria ECC y dos unidades NVMe de 1.92TB cada una. Con el fin de diversificar y mejorar la calidad del hardware, la elección recayó en un modelo EX130-S, que cuenta con CPUs Intel Xeon 5412U, 128GB de RAM ECC y discos NVMe de 3.84TB, modificaciones que dotan al nuevo entorno de una mayor capacidad, potencialmente mejor estabilidad y una arquitectura diferente.
Para garantizar que el hardware nuevo cumpliera con las expectativas de rendimiento y fiabilidad, se realizaron pruebas de estrés utilizando la herramienta stressapptest durante dos horas continuas, sin detectar errores de corrección en la memoria ECC. Tras estas pruebas, se procedió a la instalación del sistema operativo y la configuración del entorno PostgreSQL usando scripts de despliegue previamente establecidos. Se habilitó la replicación de datos hacia los nuevos servidores, asegurando que la integridad y la disponibilidad se mantuvieran durante el proceso de migración. Después de una jornada completa de operación bajo observación y sin incidencia, se ejecutó la conmutación por fallo (failover) hacia el nuevo servidor, culminando la transición. Este evento destaca la importancia de mantener un monitoreo constante y riguroso sobre el estado tanto lógico como físico de los sistemas críticos.
Aspectos como la temperatura del CPU y los discos, la carga en la CPU y la actividad en los dispositivos de almacenamiento son indicadores esenciales que pueden anticipar problemas graves si muestran anomalías relevantes. Sin embargo, también evidencia que, aunque con un monitoreo avanzado, ciertos problemas de hardware pueden desarrollarse de manera rápida y compleja, demandando protocolos claros y efectivos de respuesta. Además, la experiencia refleja el desafío que supone automatizar la gestión de la base de datos en entornos de producción, sobre todo cuando se deben evitar escenarios como el split-brain, que pueden comprometer la consistencia de los datos y la confiabilidad del sistema global. La elección de mantener un procedimiento manual para este tipo de fallos, aunque requiere más tiempo, puede evitar consecuencias aún más graves. En conclusión, la caída de la base de datos del 30 de abril de 2025 en Healthchecks.
io fue un incidente provocado, en gran medida, por problemas de hardware y la consecuente inestabilidad que esto generó. La rápida detección de anomalías, la respuesta oportuna y el procedimiento ordenado para resolver el fallo limitaron el tiempo de inactividad a media hora aproximadamente, pero también sirvieron como una llamada de atención para mejorar la infraestructura y los procesos asociados. La migración a servidores con mayor capacidad y posiblemente mejor calidad marca un paso importante hacia la reducción de riesgos futuros. Asimismo, el evento resalta cómo, en sistemas complejos, la combinación de supervisión continua, buena toma de decisiones humanas y mejora constante del entorno tecnológico es vital para garantizar la disponibilidad y confiabilidad esperadas por los usuarios. Los aprendizajes obtenidos en este caso permiten a Healthchecks.
io fortalecer su capacidad de respuesta ante fallos similares y trabajar en soluciones que hagan que el servicio sea cada vez más robusto, minimizando cualquier interrupción. En un mundo donde la continuidad y el acceso inmediato a los datos son críticos para operaciones y clientes, esta experiencia refuerza el valor de invertir en infraestructuras resilientes y en protocolos comprendidos y ejecutados con precisión.
