El informe de GitHub muestra por qué los límites de carga importan tanto como la capacidad

El informe de disponibilidad de GitHub correspondiente a septiembre de 2026 ofrece una lección útil para cualquier equipo que opere servicios con bases de datos compartidas: la capacidad nominal no basta si los trabajos en segundo plano, los tiempos de espera y los reintentos no están coordinados con la presión real sobre el sistema.

Uno de los incidentes comenzó cuando una tarea de limpieza de datos aumentó la carga sobre una base de datos compartida. El mecanismo de seguridad de la tarea reducía las escrituras cuando las réplicas se retrasaban, pero no observaba suficientemente la carga entrante en el servidor principal. El proceso continuó hasta que el primario alcanzó su límite de conexiones. A partir de ahí, las peticiones dependientes de esa base de datos empezaron a fallar, ralentizarse o quedar pendientes. GitHub indica que aproximadamente el 96 % de las solicitudes para crear incidencias desde la interfaz web se vieron afectadas durante la ventana del incidente.

El problema se agravó por dos decisiones de diseño. Las llamadas a la base de datos no tenían un tiempo de espera corto, por lo que los manejadores permanecían bloqueados en lugar de fallar rápidamente. Además, un bucle de reintentos relacionado con la creación de tokens continuaba reenviando escrituras que ya estaban fallando. En vez de dejar que el sistema recuperase capacidad, esos reintentos mantuvieron la saturación. La combinación es conocida en sistemas distribuidos: una dependencia lenta consume recursos de los clientes y los reintentos convierten una degradación local en una carga adicional.

La respuesta descrita por GitHub consistió en reducir la carga interna y pausar el trabajo de fondo hasta que la base de datos se recuperó. Las medidas posteriores incluyen controles para regular procesos según la capacidad disponible, reducir reintentos innecesarios y limitar el impacto de las llamadas lentas. También se están mejorando los procesos de arranque para que una conectividad temporalmente degradada no impida recuperarse a los servicios.

El mismo informe describe un segundo incidente de Copilot code review. Un cambio en el servicio de ejecución empezó a entregar solo una copia limitada de los resultados a algunos clientes, aunque el flujo comunicaba que la revisión había terminado correctamente. Como el sistema no comprobaba suficientemente que la revisión completa hubiera llegado al pull request, el fallo pasó desapercibido hasta que algunas revisiones permanecieron incompletas durante más de treinta minutos.

La enseñanza común es que la observabilidad debe verificar el resultado que el usuario espera, no solo que un componente interno haya respondido con éxito. Para una aplicación, crear una tarea no equivale a completar su efecto visible. Los equipos pueden traducir esta lección en límites de tiempo explícitos, reintentos con presupuesto y retroceso, protección de trabajos de mantenimiento, métricas de saturación del primario y comprobaciones de extremo a extremo. Son controles poco vistosos, pero determinan si un incidente se limita a una degradación manejable o se propaga por toda la plataforma.