Caída de GitHub de agosto de 2026: 2.900 millones de contribuciones de código al mes

GitHub estuvo inaccesible casi ocho horas el 17 de agosto de 2026 y publicó, tres días después, la cifra que explica la caída: el volumen de código depositado cada mes se ha duplicado desde abril. Qué cambia esta ola para quien encarga un software.

La caída de GitHub de agosto de 2026 duró 7 horas y 47 minutos, el día 17. En su explicación del 20 de agosto de 2026, GitHub descarta cualquier cambio de código y describe una saturación de capacidad, respaldada por una cifra: las contribuciones mensuales de código pasaron de 1.400 millones en abril a 2.900 millones.

Lo que se detuvo ese día

La interrupción no afectó solo a una página web. Se llevó por delante el acceso a las cuentas, las cadenas de automatización que construyen y prueban los programas, las interfaces para máquinas, las solicitudes de fusión y las incidencias, además del asistente de código de la empresa. Para un equipo cuya jornada pasa por esta plataforma, el día se detuvo. Era el segundo incidente notable del mes, tras un fallo en las cadenas de automatización el 6 de agosto, y ninguno de los dos procedía de una modificación realizada por GitHub.

La duplicación y lo que cuenta

Un volumen de entregas de código que se duplica desde abril no se explica por una ola de contrataciones. GitHub no identifica la causa de ese crecimiento; el período coincide con la puesta en circulación, mediante IA, de código escrito deprisa, en cantidad, por personas que no lo escribían hace dos años. La plataforma que recibe todo eso cedió bajo el peso antes de que nadie se preocupara. La cifra también es una advertencia de calidad: producir más código nunca ha significado producir más software útil, y nadie ha duplicado el tiempo de revisión a la vez.

Qué pierde un responsable cuando cae la plataforma

Si el único ejemplar de tu producto vive en un servicio remoto, tu producto se detiene cuando ese servicio se detiene. La caída se lleva el trabajo en curso, pero también el historial de versiones, la posibilidad de volver a la de anteayer y el despliegue de la corrección urgente que querías publicar esta mañana. Dos caídas con un día de diferencia en agosto de 2026, una en GitHub el 17 y otra en un proveedor de IA el 16, recordaron a todos cuántos eslabones remotos sostienen una jornada normal de trabajo.

La copia local y lo que no sustituye

En Maestro, el código y los documentos de tu producto viven en tu Mac, y el historial de versiones se lee y se restaura desde tu equipo. La copia de seguridad en línea es opcional y va a tu propia cuenta. El 17 de agosto habría quedado bloqueada: imposible enviar la copia de seguridad del día. El trabajo, en cambio, habría continuado. Eso no significa que afirmemos que una copia local basta para todo: no protege frente al robo del ordenador, no sustituye el trabajo en equipo y una plataforma remota sigue siendo el mejor lugar para compartir un proyecto con un proveedor. La elección del lugar se plantea desde el primer día.

Lo que la ola hace a la revisión

La contrapartida de la duplicación se ve en tu propio proyecto. Más código escrito deprisa significa más código que nadie ha leído, y un responsable que no lee código se encuentra ante una pila sobre la que no puede opinar. El único punto de apoyo sigue siendo el documento: qué debe hacer el producto, escrito en francés, validado por ti antes de que empiece la construcción, y una verificación que falle cuando el resultado se aparte de él.

Comprobar esta noche dónde vive tu producto

Tres comprobaciones caben en quince minutos. Abre la carpeta de tu producto en tu equipo y mira si contiene los propios archivos o un simple acceso directo a un servicio. Busca la última copia de seguridad y anota su fecha. Por último, pregunta a tu proveedor o a tu herramienta qué ocurre durante ocho horas de indisponibilidad de la plataforma que utiliza. Si la respuesta es «esperamos», ya conoces el precio de la próxima caída.