La caída de GitHub del 17 de agosto afectó descargas, Actions y Copilot: esto es lo que sabemos
La interrupción de GitHub fue generalizada: los errores llegaron aproximadamente al 20% en la web y las API, y al 50% en las descargas de archivos y contenido sin formato de repositorios.[5][16] El incidente comenzó alrededor de las 13:40 UTC y afectó Pull Requests, Issues, Actions, Webhooks, operaciones Git, Pages,...
La interrupción de GitHub fue generalizada: los errores llegaron aproximadamente al 20% en la web y las API, y al 50% en las descargas de archivos y contenido sin formato de repositorios.[5][16]
El incidente comenzó alrededor de las 13:40 UTC y afectó Pull Requests, Issues, Actions, Webhooks, operaciones Git, Pages, Copilot y funciones empresariales de autenticación y aprovisionamiento.[6][7][16]
GitHub identificó un componente problemático y aplicó medidas correctivas, pero todavía no ha publicado la causa raíz; la compañía anunció un análisis técnico posterior.[16][52]
La caída llega tras ocho incidentes registrados en julio y en medio del plan de GitHub para rediseñar su infraestructura con una capacidad de hasta 30 veces mayor que la anterior.[17][33][34]
What happened during GitHub’s worldwide outage on August 17, 2026—including when it began, the scale of its impact on repository downloads,AI-generated editorial illustration of a widespread GitHub service disruption.
Prompt de IA
Create a landscape editorial hero image for this Studio Global article: What happened during GitHub’s worldwide outage on August 17, 2026—including when it began, the scale of its impact on repository downloads,. Article summary: GitHub’s August 17 outage was a broad, cascading disruption rather than a Git-only failure: repository-content downloads, the web site, APIs, collaboration tools, automation, Copilot, and some enterprise-management funct. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fak
openai.com
La caída de GitHub del 17 de agosto de 2026 fue mucho más que un fallo al navegar por repositorios. La interrupción afectó el tráfico web y de las API, las descargas de archivos comprimidos y contenido sin formato, Pull Requests, Issues, Actions, Webhooks, las operaciones Git, Pages, GitHub Copilot y algunas funciones empresariales de autenticación y aprovisionamiento.
En el momento de mayor impacto, aproximadamente el 20% de las solicitudes web y de API devolvía errores. En el caso de las descargas de archivos comprimidos y del contenido sin formato de los repositorios, la tasa rondó el 50%.
La principal cautela es que el registro público todavía no permite determinar la causa raíz. GitHub aseguró que había identificado un componente problemático y que estaba aplicando medidas correctivas, pero indicó que publicaría un análisis técnico detallado más adelante.
Una recuperación por etapas
GitHub comenzó a investigar los problemas de rendimiento alrededor de las 13:40 UTC, las 9:40 de la mañana en la costa este de Estados Unidos, el 17 de agosto. La incidencia se extendió rápidamente por servicios que los equipos de desarrollo utilizan para acceder al código, revisar cambios, ejecutar automatizaciones y entregar software.
Studio Global AI
Continúe su investigación
Esta página incluye una respuesta respaldada por fuentes que puede continuar dentro de Studio Global.
¿Cuál es la respuesta corta a "La caída de GitHub del 17 de agosto afectó descargas, Actions y Copilot: esto es lo que sabemos"?
La interrupción de GitHub fue generalizada: los errores llegaron aproximadamente al 20% en la web y las API, y al 50% en las descargas de archivos y contenido sin formato de repositorios.[5][16]
¿Cuáles son los puntos clave a validar primero?
La interrupción de GitHub fue generalizada: los errores llegaron aproximadamente al 20% en la web y las API, y al 50% en las descargas de archivos y contenido sin formato de repositorios.[5][16] El incidente comenzó alrededor de las 13:40 UTC y afectó Pull Requests, Issues, Actions, Webhooks, operaciones Git, Pages, Copilot y funciones empresariales de autenticación y aprovisionamiento.[6][7][16]
¿Qué debo hacer a continuación en la práctica?
GitHub identificó un componente problemático y aplicó medidas correctivas, pero todavía no ha publicado la causa raíz; la compañía anunció un análisis técnico posterior.[16][52]
A las 12:36 p. m. EDT, GitHub comunicó que la plataforma mostraba señales claras de recuperación después de identificar el componente implicado y aplicar medidas correctivas. Sin embargo, el servicio todavía no se había estabilizado por completo.
La restauración no fue simultánea. Mientras varios servicios principales volvían a operar, Copilot seguía presentando problemas de autenticación en algunas aplicaciones. Otros registros sitúan el final de la interrupción general alrededor de las 21:15 UTC, por lo que el incidente completo duró bastante más que la primera fase de degradación severa.
¿Qué tan grave fue la caída?
Los datos más claros proceden de las propias métricas de GitHub:
Experiencia web y tráfico de API: alrededor de un 20% de errores.
Descargas de archivos comprimidos y contenido sin formato: aproximadamente un 50% de errores.
Servicios de desarrollo: Pull Requests, Issues, Actions, Webhooks, operaciones Git y Pages sufrieron degradaciones o interrupciones en distintos momentos.
Asistencia de programación con IA: GitHub Copilot también resultó afectado y continuó siendo un problema activo después de que varios servicios centrales se recuperaran.
Identidad empresarial: se registraron problemas con la autenticación SAML y OIDC, el aprovisionamiento SCIM y Team Sync, lo que podía impedir que algunas organizaciones iniciaran sesión o administraran permisos con normalidad.
Estas cifras representan tasas de error, no el porcentaje de usuarios de GitHub que perdió el acceso. Un 20% de errores en las API no significa que exactamente el 20% de los clientes estuviera desconectado. Del mismo modo, el 50% corresponde a las solicitudes de descarga afectadas, no a todo el tráfico de los repositorios.
Por qué el momento agravó el impacto
La interrupción comenzó un lunes por la mañana en Estados Unidos, coincidiendo con el inicio de la semana laboral para muchos equipos de ingeniería. Ese horario es especialmente sensible: el primer ciclo de trabajo suele incluir acceso al código, revisiones, integración continua, despliegues y automatizaciones.
Además, Actions, Pull Requests, API y Webhooks estuvieron entre los servicios afectados. Por eso, los equipos podían encontrarse con fallos en varios pasos conectados de su proceso de entrega, en lugar de sufrir un problema aislado en una sola función.
Los registros de sitios de seguimiento también variaron según la hora y la metodología. Un informe señaló más de 10.000 reportes en Downdetector a las 8:12 a. m., hora del Pacífico, mientras que otro situó el máximo cerca de los 3.000 reportes. Estas cifras no deben interpretarse como un conteo exacto de usuarios afectados: estos servicios contabilizan avisos enviados por usuarios y sus totales dependen de la región, el momento y el método de recopilación.
Qué hizo GitHub y qué sigue sin explicar
Las actualizaciones públicas de la compañía permiten establecer tres puntos:
Los ingenieros investigaron problemas elevados de rendimiento en varios servicios.
GitHub identificó un componente problemático y aplicó medidas correctivas.
La compañía siguió implementando mitigaciones después de que los principales servicios comenzaran a recuperarse, incluido el trabajo para resolver fallos intermitentes de autenticación en Copilot.
Lo que no está confirmado es cuál era ese componente, qué acción correctiva exacta se ejecutó o si la presión sobre la capacidad provocó directamente este incidente. El aumento del tráfico asociado con la IA y las limitaciones de infraestructura forman parte de la conversación más amplia de GitHub sobre fiabilidad, pero no deben presentarse como la causa demostrada de la caída del 17 de agosto antes de que se publique el análisis posterior.
El contexto de los problemas de fiabilidad de 2026
La interrupción de agosto llegó después de un periodo complicado. El informe de disponibilidad de GitHub registró ocho incidentes en julio. Uno de ellos, ocurrido el 8 de julio, duró más de siete horas y afectó a la interfaz web, las API REST y GraphQL, Actions, Packages, Copilot y las operaciones Git en algunos entornos de Enterprise Cloud.
GitHub también ha descrito un desafío de infraestructura de mayor escala. En su comunicación sobre disponibilidad, la compañía afirmó que el tráfico crecía rápidamente, impulsado en buena medida por los flujos de desarrollo asistidos por IA y los llamados flujos agénticos. Entre las medidas anunciadas están trasladar más capacidad a Azure, separar servicios y reducir los puntos de fallo compartidos.
La magnitud del plan resulta significativa. Según información sobre la estrategia de infraestructura, el objetivo original de multiplicar por diez la capacidad tuvo que revisarse: GitHub pasó a diseñar para una escala de 30 veces la que tenía entonces. Otros informes también describieron esfuerzos relacionados con Azure y capacidad adicional en varias nubes, incluida AWS, aunque esos planes no explican por sí solos la caída de agosto.
El contexto importa porque GitHub ya no es únicamente un lugar para almacenar repositorios Git. También funciona como capa de colaboración, plataforma de automatización, sistema de identidad y servicio de asistencia de programación con IA. Cuando fallan dependencias compartidas, un solo incidente puede interrumpir al mismo tiempo el acceso al código, las revisiones, las compilaciones, los despliegues, los Webhooks y la ayuda de Copilot.
Qué deberían revisar las organizaciones
La caída no demuestra que los desarrolladores estén a punto de abandonar GitHub, ni existen pruebas suficientes para anticipar una migración masiva e inminente. Sí muestra por qué las organizaciones que dependen de GitHub para entregar software en producción deberían revisar sus supuestos de continuidad.
Entre las medidas prácticas están mantener copias de seguridad o réplicas de los repositorios, conservar configuraciones de CI/CD que puedan trasladarse a otra plataforma, documentar procedimientos de lanzamiento de emergencia y asegurarse de que los equipos sepan operar si SSO, Webhooks o los ejecutores alojados dejan de estar disponibles.
Estas medidas no eliminan el riesgo de depender de una plataforma, pero pueden reducir el alcance de la próxima interrupción. La evaluación definitiva del incidente del 17 de agosto dependerá del análisis técnico que GitHub aún debe publicar. Hasta entonces, la conclusión más sólida es más limitada: GitHub sufrió una interrupción amplia y en cascada, con efectos especialmente graves en las descargas de repositorios y en los flujos de trabajo conectados; la recuperación fue gradual y la causa subyacente todavía no se ha explicado públicamente.
