A las 15:40 horas de Chile del 24 de julio de 2026, GitHub publicó una actualización concreta: investigaba errores al crear Pull Requests. Tres minutos después confirmó disponibilidad degradada en ese componente. Para un usuario ocasional puede parecer una función más; para un equipo de software, es con frecuencia la puerta de entrada de cualquier cambio a producción.

## El punto donde el código se convierte en trabajo compartido

Un Pull Request no guarda por sí solo el código de un desarrollador. Su función es proponer que una serie de commits pase de una rama a otra y abrir un espacio para discutir, revisar y validar el cambio. GitHub explica que allí se reúnen la conversación, los commits, los checks y los archivos modificados.

Cuando ese espacio no se puede crear o presenta disponibilidad degradada, el trabajo local puede seguir. Los desarrolladores conservan sus ramas y commits, pueden ejecutar pruebas en sus equipos y documentar lo que falta. Lo que se frena es la coordinación formal: pedir revisión, registrar comentarios, obtener aprobaciones y cumplir requisitos antes del merge.

Esa diferencia evita dos exageraciones. La primera sería afirmar que todos los desarrolladores quedaron sin poder programar. La segunda, suponer que el incidente no tuvo impacto porque Git seguía funcionando localmente. Entre ambos extremos existe una interrupción operativa real.

## Cómo se propaga un bloqueo de revisión

Los equipos maduros suelen proteger la rama principal. Exigen una o más aprobaciones, checks exitosos, conversaciones resueltas o validaciones de seguridad. Estas reglas reducen errores y dejan trazabilidad, pero también hacen que el Pull Request sea un paso obligatorio.

Si no es posible abrir una solicitud, el revisor no recibe el contexto habitual. Si la solicitud existe pero carga de forma intermitente, puede ser difícil comentar o aprobar. Y si un sistema externo espera el evento de apertura o actualización, su ejecución puede retrasarse aunque el servicio externo esté sano.

No todos los proyectos sufren de la misma forma. Un repositorio personal sin reglas de rama puede continuar casi sin cambios. Un equipo regulado que necesita evidencia de aprobación no debería saltarse el proceso por una interrupción breve. Un proyecto con una corrección urgente necesita un procedimiento excepcional previamente definido, no una improvisación.

## Lo que confirmaron GitHub y los usuarios

GitHub confirmó cinco hitos: investigación de rendimiento degradado, errores al crear Pull Requests, disponibilidad degradada, mitigación aplicada y monitoreo de estabilidad. La ficha oficial no entregó una cifra de organizaciones o personas afectadas y tampoco afirmó que todo GitHub estuviera fuera de servicio.

Durante una incidencia, usuarios de distintas regiones pueden reportar síntomas en redes o comunidades técnicas. Esos testimonios sirven para entender experiencias, pero no permiten calcular por sí solos el alcance. Un titular responsable puede señalar que numerosos usuarios reportaron problemas sin convertir esos reportes en una medición oficial.

También es importante no mezclar eventos. Horas antes, GitHub había resuelto otro incidente que sí incluyó API Requests, Actions, Copilot, Issues, Pages y Pull Requests. El episodio posterior analizado aquí fue registrado como un incidente independiente y afectó oficialmente solo a Pull Requests.

## Qué puede hacer un equipo mientras espera

La primera medida es conservar el trabajo. Hacer commits locales descriptivos reduce la posibilidad de perder contexto. La segunda es comprobar GitHub Status y la ficha específica del incidente antes de reintentar la misma operación muchas veces.

Si una creación de Pull Request falló, conviene verificar que no haya quedado registrada antes de repetirla. Duplicar solicitudes o reejecutar automatizaciones sin revisar su estado puede generar trabajo adicional cuando el servicio se recupera.

Los responsables técnicos deberían comunicar qué está bloqueado y qué puede avanzar. Documentación, pruebas locales, revisión por pares fuera de la plataforma bajo un procedimiento aprobado o preparación de cambios posteriores pueden continuar. El objetivo no es eludir controles, sino usar el tiempo sin introducir riesgos nuevos.

## Después de la mitigación

A las 15:59 horas de Chile, GitHub informó que había aplicado una mitigación. A las 16:02 señaló que la degradación estaba mitigada y que monitoreaba la estabilidad. “Monitoring” no significa que los equipos deban asumir de inmediato que cada operación previa terminó correctamente.

Al recuperar el servicio, es prudente revisar Pull Requests pendientes, checks disparados, comentarios duplicados y merges que hayan quedado a medio camino. Los equipos que usan integraciones externas también deberían confirmar si recibieron los eventos esperados.

La noticia principal mantiene la cronología oficial y el estado del incidente. Este artículo explica el efecto sobre el trabajo cotidiano: una degradación de pocos minutos puede interrumpir el lugar donde el código se revisa, se aprueba y se convierte en una entrega compartida.