Una caída de GitHub interrumpió flujos de ChatGPT y Codex sin que OpenAI estuviera completamente fuera de servicio

El servicio principal puede estar activo mientras el trabajo falla. OpenAI informó el 20 de julio errores elevados en flujos de ChatGPT y Codex que dependían de GitHub. El incidente afectó sobre todo a Codex web y a revisiones de pull requests, y estuvo relacionado con una interrupción parcial de la API de GitHub y degradación de GitHub Actions. OpenAI marcó la recuperación completa unas horas después. La lección técnica es importante: el estado de una aplicación no describe necesariamente el estado de la cadena completa que necesita una persona para terminar una tarea.

Las dependencias externas cambian la definición de disponibilidad. Un flujo de desarrollo puede requerir autenticación, lectura del repositorio, creación de una rama, ejecución de pruebas, acceso a acciones y publicación de comentarios. Aunque el modelo responda correctamente, la tarea queda incompleta si uno de esos servicios no entrega datos o rechaza operaciones. Para un negocio, “la IA funciona” no debería significar que la ventana abre. Debe significar que el proceso crítico logra llegar a su resultado y que cada dependencia necesaria está disponible dentro de parámetros acordados.

El fallo visible suele aparecer lejos de la causa. Un usuario puede ver una revisión detenida, un error de permisos o una respuesta incompleta, aunque el problema real esté en una API externa. Sin trazabilidad, el equipo pierde tiempo cambiando instrucciones, reiniciando conversaciones o culpando al modelo. Un registro mínimo debería guardar la solicitud, las herramientas llamadas, el momento, la respuesta de cada proveedor y el último paso confirmado. Eso permite distinguir entre un error lógico del agente, una indisponibilidad de tercero y una configuración interna incorrecta.

La recuperación requiere conservar el punto de avance. Cuando una integración falla, repetir toda la tarea puede duplicar comentarios, ramas, correos o cambios de archivos. Los flujos maduros usan operaciones idempotentes: antes de crear algo, comprueban si ya existe; antes de reanudar, leen el último estado válido. En desarrollo, eso puede significar reutilizar una rama y volver a ejecutar solo las pruebas pendientes. En ventas o contenido, implica no registrar dos veces un cliente ni enviar dos mensajes de confirmación por el mismo evento.

Los estados públicos son una fuente, no toda la investigación. La página de OpenAI explicó qué componentes estaban afectados y relacionó el problema con GitHub. Para operar bien, un equipo también necesita revisar el estado del proveedor dependiente, sus propios registros y el alcance real entre usuarios. Una interrupción puede afectar solo ciertas regiones, planes o funciones. La comunicación interna debe diferenciar “incidente confirmado”, “impacto observado” y “causa todavía bajo investigación” para no convertir una hipótesis en certeza.

La continuidad no exige duplicar todas las plataformas. Mantener dos proveedores completos para cada función suele ser caro y complejo. Es más útil definir alternativas por nivel de criticidad. Una revisión de código puede esperar y reanudarse; una publicación urgente quizá necesite una vía manual; un pago no debería repetirse sin confirmación. El plan de contingencia debe indicar qué tareas se pausan, cuáles cambian de canal y quién autoriza continuar sin automatización. Así se protege el resultado sin construir una segunda empresa tecnológica en paralelo.

La acción práctica es dibujar la cadena y sus puntos de parada. Selecciona tres procesos dependientes de herramientas externas y enumera cada sistema que interviene. Para cada uno, registra señal de salud, error esperable, evidencia guardada, tiempo máximo de espera y paso alternativo. Después simula la caída de una integración y comprueba si el equipo sabe continuar sin duplicar acciones. El incidente de OpenAI y GitHub recuerda que la resiliencia no consiste en prometer que nada falla, sino en saber exactamente qué quedó hecho, qué falta y cómo reanudar cuando la dependencia vuelve.