Cuando GitHub presenta errores, la primera reacción suele ser repetir la operación. Durante el incidente de Pull Requests del 24 de julio de 2026, esa conducta podía crear solicitudes duplicadas o dejar dudas sobre qué había terminado. Una respuesta segura empieza por observar, conservar el trabajo y verificar cada etapa.

GitHub confirmó que investigaba errores al crear Pull Requests, declaró disponibilidad degradada, aplicó una mitigación y pasó a monitoreo. No informó pérdida de repositorios ni una caída completa de la plataforma. Esta guía parte de ese alcance y propone medidas que sirven para incidentes similares.

## 1. Revisa la fuente oficial

Abre GitHub Status y entra en la ficha del incidente. El panel general muestra el estado de cada componente, mientras que la ficha entrega la cronología, los servicios oficialmente afectados y la fase actual: investigating, identified, monitoring o resolved.

Comprueba la hora y el nombre del componente. Puede haber más de un incidente el mismo día. El 24 de julio, GitHub registró un evento anterior que afectó varios servicios y otro posterior limitado a Pull Requests. Mezclarlos puede llevar a diagnosticar mal un problema.

Los reportes en redes y plataformas externas ayudan a detectar síntomas, pero no reemplazan la fuente oficial. Úsalos como contexto, no como confirmación de una causa o alcance.

## 2. Conserva tus cambios localmente

Git es distribuido. Si tus archivos están solo modificados en el directorio de trabajo, crea commits locales coherentes cuando el estado del proyecto lo permita. Un commit conserva el contenido y el contexto dentro del repositorio local aunque el remoto esté degradado.

No confundas commit con push. Puedes confirmar cambios sin enviarlos de inmediato. Verifica la rama activa, revisa el diff y usa mensajes descriptivos. Evita introducir secretos o archivos temporales solo por la urgencia.

Si trabajas con cambios críticos, una copia de seguridad local adicional puede ser razonable. Debe almacenarse en un destino controlado y no sustituye las políticas normales de respaldo.

## 3. No repitas operaciones destructivas

Una interfaz que tarda en responder no demuestra que la operación haya fallado. Antes de recrear un Pull Request, actualizar una rama por la fuerza o cancelar ejecuciones, comprueba el estado actual.

Evita force push, borrado de ramas, reseteos agresivos y eliminación masiva de jobs como método de recuperación. Estas acciones pueden dificultar la reconstrucción posterior y convertir una degradación externa en pérdida o divergencia generada por el propio equipo.

Si una operación requiere privilegios elevados o cambia producción, sigue el procedimiento de aprobación habitual. Un incidente del proveedor no debería suspender controles sin una decisión autorizada.

## 4. Comprueba pipelines antes de reejecutarlos

Revisa si el workflow existe, cuál es su identificador, qué commit ejecuta y en qué estado quedó. Una ejecución puede estar en cola, retrasada, fallida o completada aunque la interfaz haya mostrado un error temporal.

GitHub permite reejecutar workflows y jobs fallidos. Hazlo sobre la ejecución correcta y después de confirmar que no hay otra activa. En integraciones externas, revisa también el panel del proveedor, los logs y la versión desplegada.

No asumas que una falla en Pull Requests significa que GitHub Actions cayó. En el incidente analizado, Actions no apareció como componente afectado. El pipeline podía quedar detenido porque el evento de Pull Request no se produjo, que es una causa distinta.

## 5. Verifica Pull Requests y despliegues al recuperarse

Cuando GitHub pasa a monitoring, la mitigación está aplicada pero el proveedor todavía observa la estabilidad. Busca solicitudes duplicadas, checks pendientes, comentarios repetidos y merges incompletos.

Después, comprueba el destino. Compara el hash del commit esperado con el artefacto o despliegue activo. Si el sistema usa entornos de vista previa, verifica cuáles siguen vigentes y elimina duplicados solo después de entender su origen.

Registra lo ocurrido. Una línea de tiempo interna con operaciones, identificadores y decisiones facilita el cierre y mejora el próximo procedimiento.

## 6. Mantén respaldos y remotos alternativos cuando se justifique

Para proyectos con exigencias altas de continuidad, un repositorio espejo puede conservar ramas y etiquetas en otra ubicación. GitHub documenta la duplicación mediante clones bare o mirror.

Un remoto alternativo debe probarse. Define quién lo actualiza, con qué frecuencia y bajo qué condiciones se usa. Considera Git LFS, permisos, secretos, Issues, Pull Requests y pipelines: el historial Git no incluye automáticamente todo el ecosistema.

No todos los proyectos necesitan dos plataformas activas. El costo y la complejidad deben ser proporcionales al impacto de una interrupción.

## 7. Comunica el alcance con precisión

Informa qué confirmó el proveedor, qué observó tu equipo y qué consecuencias siguen siendo potenciales. Por ejemplo: “GitHub confirmó disponibilidad degradada en Pull Requests; nuestro equipo no pudo crear una solicitud y el pipeline asociado no se inició”. Esa frase separa evidencia oficial, experiencia interna e impacto derivado.

Evita afirmar que GitHub fue hackeado, que perdió repositorios o que toda la plataforma cayó si no hay pruebas. La precisión reduce ansiedad y ayuda a decidir.

## Lista rápida de comprobación

Revisar GitHub Status y la ficha del incidente.

Conservar cambios mediante commits locales revisados.

Confirmar si la operación fallida realmente existe antes de repetirla.

Evitar force push, borrados y reintentos masivos.

Comprobar Pull Requests, workflows, artefactos y despliegues en ese orden.

Validar remotos alternativos y respaldos según el plan de continuidad.

La noticia principal contiene la cronología oficial del incidente. Esta guía convierte esa información en acciones concretas para proteger el trabajo sin exagerar el alcance ni improvisar cambios riesgosos.