Resumen
- GitHub abrió a las 23:34 UTC del 19 de julio un incidente crítico en Actions. Los flujos nuevos podían demorarse o no arrancar y las ejecuciones en curso podían fallar.
- La incidencia llegó después a API Requests, Pages e Issues. GitHub reconoció efectos en cadena por la duración del fallo y vinculó a la misma investigación los problemas de Git LFS y carga de archivos mediante API.
- CircleCI observó pipelines sin iniciar o atrapados en estado de ejecución. OpenAI informó de fallos o retrasos en trabajos de programación dependientes de GitHub.
- GitHub dio por recuperado Actions a las 04:43 UTC y resolvió el incidente un minuto después. La explicación técnica prometida todavía no estaba publicada al cierre.
Una cadena de entrega puede partirse aunque el código siga en el repositorio y el servidor que ejecuta el trabajo siga encendido.
El incidente de GitHub lo demostró durante la madrugada del lunes. El primer aviso, a las 23:34 UTC, hablaba de degradación en Actions. Poco después, la compañía advirtió que los flujos nuevos podían retrasarse o no comenzar y que los ya iniciados podían fallar. A las 23:57 afirmó haber localizado la causa, pero no dijo cuál era.
El problema dejó de parecer una avería limitada a capacidad de ejecución. API Requests entró en interrupción parcial a las 00:07. Pages e Issues se degradaron. Otro registro de estado señaló operaciones Git LFS y cargas de archivos por API que no funcionaban. A la 01:11, GitHub confirmó la relación: la prolongación del fallo de Actions estaba causando efectos sobre otros servicios y el incidente abierto por separado pertenecía a la misma investigación.
Falló la coordinación, no sólo el cómputo
Actions convierte un evento del repositorio en un flujo, divide ese flujo en trabajos y los asigna a runners. Ese recorrido necesita algo más que procesadores. GitHub debe recibir el evento, leer el estado del repositorio, crear y encolar trabajos, comunicar resultados y conservar la historia que consumen las reglas de merge y las integraciones externas.
Por eso cada superficie puede mostrar una realidad distinta. El push existe, pero el pipeline no aparece. El trabajo termina, pero la comprobación obligatoria no recibe el estado. El archivo grande permanece en LFS, aunque la llamada que lo recupera falle. El sitio publicado continúa visible mientras la siguiente compilación de Pages queda detenida.
La recuperación fue escalonada. Pages volvió a la normalidad a la 01:37 e Issues a las 02:20. A las 02:43, GitHub dijo que Issues, las API y Pages se habían recuperado, pero seguía restaurando trabajos de Actions que utilizaban runners autogestionados o de mayor tamaño. Las API se declararon normales a las 03:03. Actions pasó a vigilancia a las 03:34 y se consideró totalmente recuperado a las 04:43.
Esos hitos no forman una cifra universal de indisponibilidad. GitHub no publicó cuántos repositorios, organizaciones, ejecuciones o regiones fueron afectados. Un cliente que sólo usó Git puede haber vivido una experiencia distinta de otro que dependía de Actions, LFS, Pages y una plataforma externa a la vez.
CircleCI revela el problema de los estados divergentes
El aviso de CircleCI explica el coste práctico mejor que una etiqueta roja. La empresa atribuyó a errores de la API de GitHub flujos que no arrancaban o seguían marcados como activos. También detectó fallos al procesar webhooks de eventos push.
Cuando la tasa de error volvió a la normalidad, CircleCI recomendó volver a disparar los pipelines que nunca comenzaron y cancelar y repetir los que seguían bloqueados. Eso significa que la recuperación del proveedor original no corrigió por sí sola la historia del sistema dependiente.
OpenAI añadió una segunda observación independiente. Su registro de servicio relacionó fallos y retrasos en flujos de programación que dependían de GitHub con la interrupción parcial de las API y la degradación de Actions. No publicó número de usuarios, trabajos fallidos ni pérdida comercial. La importancia del aviso es otra: confirma que el fallo salió de la interfaz de GitHub y apareció en un producto externo.
Ninguna de estas pruebas implica que CircleCI u OpenAI originaran el incidente. Tampoco demuestra que todas las integraciones fallaran. Sí demuestra que una dependencia compartida puede dejar diferentes plataformas con versiones distintas sobre si un trabajo existe, continúa o ha terminado.
Un runner propio sigue necesitando el plano de control
La documentación de GitHub define el runner autogestionado como una máquina desplegada y administrada por el cliente para ejecutar trabajos de Actions. La organización controla el sistema operativo, las herramientas, el hardware y el coste de mantenerlo.
Ese control puede servir para aislar redes, usar equipos especializados o cumplir requisitos de localización. No equivale a controlar todo el sistema de orquestación.
GitHub indicó que los trabajos sobre runners autogestionados y runners alojados de mayor tamaño seguían necesitando restauración cuando Issues, Pages y las API ya habían vuelto. No afirmó que las máquinas de los clientes estuvieran averiadas. El dato señala una dependencia más sutil: tener capacidad de ejecución disponible no ayuda si el evento, la cola, la asignación o el estado siguen detenidos en GitHub.
Una vía de emergencia necesita definir quién puede iniciar el trabajo sin el disparador habitual, qué versión está autorizada, cómo se aprueba el cambio y dónde queda la evidencia final. Duplicar servidores sin duplicar esas decisiones crea una reserva de cómputo, no una cadena de entrega independiente.
Repetir puede duplicar una acción ya ejecutada
El estado «fallido» o «en curso» no prueba que nada haya ocurrido fuera del pipeline. Un trabajo puede publicar un paquete, modificar infraestructura, enviar un mensaje o iniciar un despliegue antes de perder la confirmación.
Reejecutarlo de inmediato puede aplicar dos veces el mismo efecto. Antes de pulsar de nuevo, el equipo debe comparar el evento del repositorio, el historial de Actions, los registros del runner, los artefactos y el sistema de destino. Los trabajos idempotentes y los identificadores de versión verificables limitan el riesgo, pero no sustituyen esa comprobación.
La recomendación de CircleCI de cancelar y repetir responde a lo que observó en su plataforma. Cada cliente sigue siendo responsable de revisar el contenido de su pipeline. Un test detenido suele poder repetirse. Un cambio de producción aplicado a medias exige saber qué parte llegó a ejecutarse.
Falta la causa que explique el contagio
GitHub cerró el incidente a las 04:44 y prometió un análisis detallado. La cronología pública identifica las superficies afectadas y el orden de recuperación, pero no el componente inicial, el mecanismo que arrastró a las API y otros servicios ni la modificación prevista para evitar que vuelva a ocurrir.
Estos datos tampoco sustentan una intrusión, pérdida de código, pérdida de datos, fallo de un despliegue concreto o compensación contractual automática. «Crítico» es el nivel de impacto asignado por GitHub al incidente, no una medida de la pérdida de cada cliente.
La explicación que falta debería separar tres fases: el defecto inicial, la acumulación de trabajo y los efectos generados durante la restauración. Hasta que se publique, la conclusión prudente es operativa: GitHub recuperó la cadena, pero los clientes deben reconciliar evento, ejecución y destino antes de cerrar su propia incidencia.