Ningún despliegue sin monitor.

El 29 de mayo, una función para comprobaciones adicionales de política de cuotas llegó a Service Control sin feature flag y sin gestión de errores en la nueva ruta. El 12 de junio, un cambio de política produjo campos en blanco, y los binarios fallaron en todo el mundo con un error de puntero nulo. Google escribió que su primer informe de incidente llegó alrededor de una hora después de empezar los fallos, porque la propia infraestructura de Cloud Service Health estaba caída. También escribió que, para algunos clientes, la infraestructura de monitorización que ejecutaban en Google Cloud fallaba igualmente, lo que los dejó sin señal del incidente.

Qué muestra un check desde fueraEsa última frase defiende la monitorización externa con las palabras del propio operador: la monitorización en la misma plataforma cae con ella. Perstat comprueba desde fuera, desde hasta 6 regiones con quórum, y su infraestructura de sondas no funciona sobre la plataforma que vigila. Una página de estado en una infraestructura aparte habría informado a tus clientes durante esa hora.

Fuente: Informe de incidente de Google Cloud, 2025-06-12 · The Register, 2025-06-16

Un script pensado para borrar instancias de una app retirada recibió IDs de sitio en lugar de IDs de app y borró sitios de clientes enteros durante 23 minutos, a partir de las 07:38 UTC. El primer ticket de un cliente llegó a las 07:46 UTC, a los 8 minutos, y el proceso de incidente grave arrancó a las 08:17 UTC. La primera actualización de la página de estado llegó a las 09:03 UTC, a los 85 minutos, y el primer comunicado externo amplio en redes sociales, el 7 de abril, a las 41 horas. La restauración llevó hasta 14 días y solo estaba automatizada en parte.

Qué muestra un check desde fueraUn check HTTP de la URL de tu propio tenant desde varias regiones informa de la caída tras 2 checks fallidos consecutivos, sin esperar a un ticket de soporte. Algunos clientes perdieron Statuspage y Opsgenie junto con sus sitios, así que la página de estado y las alertas no deben estar en el proveedor cuya caída deben mostrar. Ninguna monitorización habría acortado los 14 días.

Fuente: Revisión post-incidente de Atlassian, 2022-04-29

El CEO escribió que la empresa renueva miles de dominios cada año con precisión, pero que el proceso de renovación automática de su dominio principal falló. El comunicado atribuyó la causa a un error humano y de proceso. Los clientes se quejaron públicamente en Twitter.

Qué muestra un check desde fueraUn check de dominio informa de la fecha de caducidad con días de antelación, desde un sistema que no depende de la renovación automática que falló. Un check DNS desde varias regiones habría informado de la pérdida de resolución tras 2 checks fallidos consecutivos. Una página de estado en otro dominio habría llevado el mensaje mientras marketo.com no resolvía, pero ningún check puede renovar el dominio.

Fuente: Base de conocimiento de Marketo (Adobe), P1 del 25 de julio de 2017 · The Drum, 2017-07-26

Al reparar la replicación, un ingeniero borró el directorio de datos del primario en lugar del secundario. Las copias con pg_dump no existían, porque el script ejecutaba pg_dump 9.2 contra PostgreSQL 9.6 y fallaba. GitLab escribió que los avisos de jobs de cron fallidos se enviaban por correo, pero esos correos no tenían DMARC activado, así que el servidor receptor los rechazaba. Las instantáneas de disco no estaban activadas para los servidores de base de datos, y solo quedaba una instantánea LVM manual con 6 horas de antigüedad.

Qué muestra un heartbeatUn heartbeat funciona como interruptor de hombre muerto: el job de copia informa tras terminar con éxito, y Perstat alerta cuando ese aviso falta, se reciba o no un correo de error. El caso muestra también que las alertas no deben depender de un único canal que puede fallar a su vez, así que el escalado debe ir por varias vías y exigir una confirmación. Un heartbeat no comprueba si la copia se puede restaurar. Eso sigue siendo tarea de una prueba de restauración.

Fuente: Post-mortem de GitLab, 2017-02-10 · The Register, 2017-02-01, sobre las 5 técnicas de copia