El 17 de agosto de 2026, uno de los servidores de almacenamiento del proveedor cloud DanubeData perdió energía a las 00:32 UTC y permaneció apagado hasta que un ingeniero lo encendió manualmente a las 08:22. Durante algo más de ocho horas quedaron fuera de servicio el almacenamiento de objetos compatible con S3, el registro de contenedores y los despliegues sin servidor y de sitios estáticos. Las aplicaciones en ejecución continuaron sirviendo y no se perdió ni se corrompió ningún dato de clientes, aunque los despliegues fallidos durante la ventana no se reintentaron solos y debieron relanzarse a mano.
La página de estado detectó la caída a los tres minutos y la mantuvo pública durante toda la incidencia, pero nadie del equipo de guardia la vio: el aviso llegó únicamente por correo electrónico a las 08:18, cuando un ingeniero abrió la página por un motivo no relacionado. Esa distancia entre lo que el sistema sabía y lo que sabía una persona es, según la compañía, la verdadera incidencia.
La caída total, en lugar de parcial, se debió a la política de distribución de los fragmentos de código de borrado: aunque los objetos se reparten en seis piezas con tolerancia a la pérdida de dos, esas piezas podían coincidir en la misma máquina, así que un único servidor caído se llevó de media una pieza y media de cada objeto y, en muchos casos, dos o tres, dejando los datos ilocalizables hasta que el hardware regresó. Además, ciertos metadatos internos guardados con solo dos réplicas compartían máquina, lo que convirtió una lectura degradada en un error de conexión. DanubeData ya tiene en marcha cambios: avisos telefónicos al equipo de guardia ante cualquier incidente en la página de estado y reubicación de esos metadatos en tres copias en máquinas distintas. La redundancia a nivel de host para el almacenamiento de objetos está planificada pero pendiente de capacidad adicional.