Historial de interrupciones de Circle Ci

1. 21 de octubre de 2026 a las 19:31 UTCidentified

   Algunos usuarios pueden ver tiempos de espera aumentados para el gen2 Docker empleo debido a problemas de capacidad.

2. 21 de octubre de 2026 a las 20:03 UTCidentified

   Estamos agregando capacidad adicional para ayudar a mitigar el problema. Nota: Todavía estamos viendo retrasos de hasta 20 minutos en 2xlarge.

3. 21 de octubre de 2026 a las 20:22 UTCidentified

   Los tiempos de espera para 2x trabajos de taquilla se están recuperando. Seguiremos actualizando a medida que la capacidad llegue en línea.

4. 21 de octubre de 2026 a las 20:35 UTCidentified

   Los tiempos de espera para 2x trabajos de taquilla son ahora menos de 60 segundos. Los tiempos de espera para otros tamaños de recursos no fueron impactados por este incidente y permanecen menos de 10 segundos.

5. 21 de octubre de 2026 a las 20:40 UTCmonitoring

   Hemos visto una recuperación completa de los tiempos de espera para los puestos de docker.

6. 21 de octubre de 2026 a las 20:54 UTCresolved

   Los tiempos de espera para empleos gen2 Docker se han recuperado y los trabajos se ejecutan dentro de los tiempos normales de espera.

7. 22 de octubre de 2026 a las 23:29 UTCpostmortem

   ## Summary De 15:44 a 20:55 UTC el 21 de octubre, los clientes que ejecutan trabajos de Gen 2 Docker vieron aumentar los tiempos de espera para sus trabajos. Los retrasos fueron más largos en la clase de recursos 2xlarge, donde los trabajos esperaron hasta 20 minutos. El incidente fue causado por la disponibilidad limitada de las instancias en la nube que habíamos configurado para satisfacer la demanda, en particular para 2 trabajos más grandes. En respuesta, nuestro equipo de ingeniería configuraba tipos de instancia adicionales, configuraba agrupaciones adicionales de Docker Gen 2. Para 20:55 UTC, los tiempos de espera habían vuelto a la normalidad y el incidente se resolvió. Después de que el incidente se resolvió, ampliamos nuestra flota de Docker Gen 2 en regiones de nubes adicionales, y seguimos apoyando activamente las regiones de nubes adicionales para evitar incidentes similares en el futuro. La página de estado original se puede encontrar aquí: [21 de octubre - Mayor Docker gen2 wait times](https://status.circleci.com/incidents/5jb50gh55gtj). ## Background Cuando CircleCI ejecuta un trabajo de Docker, lo programamos en uno de varios grupos de instancias de nube, y cada instancia es capaz de ejecutar múltiples trabajos aislados. Programar un trabajo en una instancia en la nube es un clásico [“problema de empaquetado debines”](https://en.wikipedia.org/wiki/Bin packing problem): encontrar la capacidad disponible que se ajuste a la CPU, la memoria y el almacenamiento de la clase de recursos solicitada. Las clases de recursos más grandes como 2xlarge son más difíciles de adaptarse que las más pequeñas, que empacan juntas más ajustadamente. Proporcionamos casos de nube usando una lista clasificada de tipos de instancia. Si el proveedor de la nube no puede suministrar nuestra primera opción, retrocedemos al siguiente tipo de la lista. Además mantenemos un tamaño mínimo de la flota: un número mínimo de casos se mantienen en funcionamiento, de modo que no renunciamos a la capacidad cuando la demanda es baja. Por encima del tamaño mínimo de la flota, añadimos instancias a medida que aumenta la demanda. Cuando no hay suficiente capacidad para ejecutar una carga de trabajo, esperamos que funcione hasta que la capacidad esté disponible. ## What Happened \(Todas las veces UTC\) A partir de las 15:44, el 21 de octubre, la demanda de la clase de recursos Gen 2 2xlarge aumentó bruscamente, y no proveimos la capacidad adicional lo suficientemente rápido como para mantenerse al día. Nuestro equipo de ingeniería comenzó a investigar. Para 19:25, los tiempos de espera para la clase de recursos Gen 2xlarge habían llegado a 20 minutos, y los tiempos de espera para otras clases de recursos habían aumentado también. Para 19:56, nuestro equipo de ingeniería había configurado tipos de instancia adicionales a la flota Gen 2 para obtener más capacidad en línea, y para 19:59, estábamos proporcionando esos tipos de instancia. A las 20:11, añadimos varios grupos adicionales de Gen 2 y aumentamos el tamaño mínimo de la flota en esos grupos. A las 20:35, el número de puestos de trabajo solicitados volvió a niveles normales, y para las 20:41, el 95% de los 2xgrandes empleos estaban empezando en 4 segundos. Hemos resuelto el incidente a las 20:55. Después de resolver este incidente, añadimos regiones cloud adicionales para los empleos de Docker para hacer más capacidad disponible. ## Future Prevention and Process Improvement Ya hemos adoptado las siguientes medidas para mejorar los tiempos de inicio de empleo, incluida la capacidad de contratación de más lugares, la reserva de más capacidad para las grandes clases de recursos y la aplicación de un suministro más rápido. **Hemos añadido regiones adicionales para empleos de Docker.** Recientemente hemos añadido regiones cloud adicionales para trabajos de Máquina, y ahora hemos hecho lo mismo para los trabajos de Docker. ** Continuaremos añadiendo regiones de nube adicionales para trabajos de Docker y Machine**. **Hemos añadido más grupos gen 2**. Configuramos varios grupos adicionales de Gen 2 para programar trabajos más rápidamente, y para hacer más capacidad total disponible. ** Hemos ampliado el conjunto de tipos de instancias en la nube que usamos y hemos elevado nuestro tamaño mínimo de flota.** Hemos configurado tipos adicionales de instancia. También hemos aumentado el tamaño mínimo de la flota para el Gen 2 para satisfacer la demanda de base actual. **Hemos modificado nuestro programador de trabajo para priorizar la programación de clases de recursos más grandes.** Hemos cambiado la forma en que programamos empleos para equilibrar los tiempos de espera más equitativamente en las clases de recursos, y para empaquetar los trabajos de manera más eficiente en los casos disponibles. Conclusión La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver este incidente. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 20 de octubre de 2026 a las 15:58 UTCinvestigating

   Estamos viendo tiempos de espera aumentados para algunos trabajos de macOS usando la clase de recursos m4pro.large. Estamos investigando y proporcionaremos otra actualización pronto. Gracias por su paciencia.

2. 20 de octubre de 2026 a las 16:32 UTCmonitoring

   Los clientes que ejecutan trabajos de macOS en la clase de recursos m4pro.large todavía están viendo tiempos de espera aumentados, con algunos trabajos esperando hasta 30 minutos para empezar. Seguiremos monitoreando esto y compartiremos otra actualización en breve.

3. 20 de octubre de 2026 a las 17:02 UTCmonitoring

   Los tiempos de espera para m4pro.large siguen siendo elevados debido a la gran demanda pesada. Todos los m4pro.medium son normales. Estamos monitoreando activamente, apreciamos la paciencia.

4. 20 de octubre de 2026 a las 17:31 UTCmonitoring

   Los tiempos de espera para trabajos de macOS en la clase de recursos m4pro.grande se están recuperando. Jobs using Xcode 27.0 are now waiting about ~3.5 minutes on average, down from about ~40 minutes at the peak. Los trabajos que utilizan Xcode 26.6 y 26.4.1 siguen trabajando a través de un atraso, que está aclarando. Los tiempos de espera en m4pro.medium son normales. Compartiremos otra actualización en cuanto continuemos monitoreando.

5. 20 de octubre de 2026 a las 18:14 UTCresolved

   Los tiempos de espera para trabajos de macOS en la clase de recursos m4pro.grande han vuelto a la normalidad. Le agradecemos su paciencia mientras los atrasos se despejaron.

Traducido automáticamente desde la actualización oficial del incidente.

1. 14 de octubre de 2026 a las 14:47 UTCinvestigating

   Desde aproximadamente 14:00 UTC, los clientes que ejecutan trabajos de macOS que utilizan Xcode 26.6.0 en la clase de recursos grandes M4 Pro están experimentando retrasos en el inicio de trabajos. Los tiempos de espera han llegado a 30 minutos o más. Gracias por su paciencia mientras nuestros ingenieros investigan. Proporcionaremos otra actualización a las 15:30 UTC.

2. 14 de octubre de 2026 a las 15:17 UTCidentified

   Los retrasos que comienzan trabajos de macOS que usan Xcode 26.6.0 se han recuperado. Desde aproximadamente 15:11 UTC, los trabajos de macOS que usan Xcode 26.4 están experimentando retrasos comenzando, con tiempos de espera de unos 30 minutos. Gracias por su paciencia mientras nuestros ingenieros trabajan para resolver esto. Proporcionaremos otra actualización para 15:45 UTC.

3. 14 de octubre de 2026 a las 16:01 UTCresolved

   Entre aproximadamente 14:00 UTC y 15:51 UTC el 14 de octubre, los clientes que ejecutan trabajos macOS que usan Xcode 26.6.0 o Xcode 26.4 experimentaron retrasos en el inicio de trabajos. A partir de aproximadamente 14:00 UTC, los trabajos que utilizan Xcode 26.6.0 en la clase de recursos grandes M4 Pro esperaron 30 minutos o más para comenzar, y estos retrasos se recuperaron a aproximadamente 15:12 UTC. Desde aproximadamente 15:11 UTC, trabajos que utilizan Xcode 26.4 esperó unos 30 minutos para empezar. La cuestión se ha resuelto y toda la funcionalidad afectada ha vuelto a la normalidad. Le agradecemos su paciencia mientras nuestro equipo trabajó en implementar una solución.

Traducido automáticamente desde la actualización oficial del incidente.

1. 9 de octubre de 2026 a las 11:33 UTCidentified

   Hay un retraso en nuestra infraestructura de datos que causa retrasos antes de construir datos y algunas notificaciones se vuelven visibles. Estamos trabajando en una mitigación.

2. 9 de octubre de 2026 a las 13:00 UTCidentified

   Lo que ha impactado: Los clientes activan oleoductos, y los clientes dependen de webhooks y notificaciones de correo electrónico y Slack. ¿Qué puedes esperar? Desde las 11:15 UTC: - Las tuberías siguen siendo creadas mientras esto está en curso pero aún no procesada, por lo que la retrigación puede resultar en tuberías duplicadas. - No se envían webhooks outbound y notificaciones transaccionales (Slack y email). - Los estados de tuberías pueden no ser visibles. - Los datos de carga de uso en la página de uso del proyecto serán escalonados. Gracias por su paciencia mientras nuestros ingenieros trabajan para resolver esto. Siguiente actualización: Proporcionaremos otra actualización a las 13:30 UTC.

3. 9 de octubre de 2026 a las 13:30 UTCidentified

   Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Lo que ha impactado: Los clientes activan oleoductos, y los clientes dependen de webhooks y notificaciones de correo electrónico y Slack. ¿Qué puedes esperar? - Desde las 13:00 UTC, se están procesando oleoductos de nuevo y se están iniciando trabajos. - La mayoría de los trabajos están empezando en unos 4 minutos, y algunos están esperando hasta unos 10 minutos. Las tuberías disparadas durante el incidente siguen siendo procesadas y pueden tardar más tiempo en empezar. - Se han reanudado los sorteos y las notificaciones. - Las tuberías siguen siendo procesadas desde el atraso, por lo que la retrigación puede resultar en tuberías duplicadas. Gracias por su paciencia mientras nuestros ingenieros trabajan para resolver esto. Siguiente actualización: Proporcionaremos otra actualización para las 14:00 UTC.

4. 9 de octubre de 2026 a las 14:00 UTCidentified

   Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). ¿Qué ha afectado? Los clientes ejecutan flujos de trabajo y empleos, y los clientes ven los datos de uso en la página Uso del Proyecto. ¿Qué puedes esperar? - Las tuberías están siendo procesadas de nuevo, incluyendo las desencadenadas durante el incidente. - Desde aproximadamente 13:25 UTC, los flujos de trabajo y los empleos han comenzado con crecientes retrasos a medida que trabajamos a través del atraso. La mayoría de los trabajos están empezando en unos 10 minutos, y algunos están esperando hasta unos 25 minutos. - Esperamos trabajar a través de este atraso alrededor de 14:35 UTC. - Los flujos de trabajo de los oleoductos desencadenados durante el incidente todavía están esperando para empezar, por lo que la retrigación puede resultar en flujos de trabajo duplicados. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros trabajan para resolver esto. Siguiente actualización Proporcionaremos otra actualización a las 14:30 UTC.

5. 9 de octubre de 2026 a las 14:29 UTCidentified

   Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). ¿Qué ha afectado? Los clientes ejecutan flujos de trabajo y empleos, y los clientes ven los datos de uso en la página Uso del Proyecto. ¿Qué puedes esperar? - Las demoras en el inicio de los flujos de trabajo y el empleo están mejorando. La mayoría de los puestos de trabajo comienzan en unos 3 minutos, desde unos 10 minutos a las 13:50 UTC. - Algunos flujos de trabajo de oleoductos desencadenados durante el incidente siguen esperando hasta unos 40 minutos para empezar. Trabajar a través del atraso está tomando un poco más de lo esperado. Ahora esperamos aclararlo alrededor de las 14:45 UTC. - Los flujos de trabajo de los oleoductos desencadenados durante el incidente todavía están esperando para empezar, por lo que la retrigación puede resultar en flujos de trabajo duplicados. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros trabajan para resolver esto. Siguiente actualización Proporcionaremos otra actualización para las 15:00 UTC.

6. 9 de octubre de 2026 a las 14:43 UTCidentified

   Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. Lo que impacta Los clientes ejecutan flujos de trabajo y empleos, y los clientes ven los datos de uso en la página Uso del Proyecto. ¿Qué puedes esperar? - El atraso de los flujos de trabajo de los oleoductos provocó durante el incidente despejado a unas 14:40 UTC. - La mayoría de los trabajos comienzan en unos 30 segundos, y algunos esperan hasta unos 3 minutos. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros continúan trabajando en el tema subyacente. Siguiente actualización Proporcionaremos otra actualización para 15:10 UTC.

7. 9 de octubre de 2026 a las 14:54 UTCmonitoring

   Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. Lo que impacta Los clientes ejecutan flujos de trabajo y empleos, y los clientes ven los datos de uso en la página Uso del Proyecto. ¿Qué puedes esperar? - El atraso de tuberías y flujos de trabajo del incidente se ha despejado. - Desde las 14:45 UTC, la mayoría de los flujos de trabajo y empleo comienzan en unos 15 segundos, y los tiempos de inicio continúan regresando a la normalidad. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros monitorean la recuperación. Siguiente actualización Proporcionaremos otra actualización para 15:20 UTC.

8. 9 de octubre de 2026 a las 15:32 UTCmonitoring

   Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. ¿Qué ha afectado? Los clientes que ven tuberías, flujos de trabajo y puestos de trabajo en la interfaz de usuario CircleCI y los clientes que ven los datos de uso en la página de uso del proyecto. ¿Qué puedes esperar? - Los flujos de trabajo y los empleos están funcionando a tiempo. - La UI CircleCI está a unos 30 minutos. Los nuevos flujos de trabajo y cambios de estado pueden tardar tanto en aparecer. - Nuestros ingenieros están trabajando activamente para acelerar el procesamiento para que la UI pueda ponerse al día. - Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros trabajan para reducir este retraso. Siguiente actualización Proporcionaremos otra actualización para las 16:00 UTC.

9. 9 de octubre de 2026 a las 16:02 UTCmonitoring

   Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. ¿Qué ha afectado? Clientes que ejecutan flujos de trabajo y trabajos, clientes que ven tuberías, flujos de trabajo y trabajos en la interfaz de usuario CircleCI, y clientes que ven los datos de uso en la página de uso del proyecto. ¿Qué puedes esperar? - Desde las 15:15 UTC, los flujos de trabajo y los empleos han comenzado con crecientes demoras. La mayoría de los trabajos están empezando en unos 4 minutos, y algunos están esperando hasta unos 20 minutos. - La IU CircleCI permanece a unos 30 minutos en promedio, y algunas actualizaciones están tomando más tiempo. Los nuevos flujos de trabajo y cambios de estado pueden tardar tanto en aparecer. - Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros trabajan para reducir estos retrasos. Siguiente actualización Proporcionaremos otra actualización a las 16:30 UTC.

10. 9 de octubre de 2026 a las 16:32 UTCmonitoring

    Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. Desde las 15:15 UTC, los flujos de trabajo y los empleos han comenzado de nuevo con retrasos. ¿Qué ha afectado? Clientes que ejecutan flujos de trabajo y trabajos, clientes que ven tuberías, flujos de trabajo y trabajos en la interfaz de usuario CircleCI, y clientes que ven los datos de uso en la página de uso del proyecto. ¿Qué puedes esperar? - Las demoras que comienzan los flujos de trabajo y los empleos han dejado de aumentar y están empezando a facilitarse. La mayoría de los trabajos comienzan en unos 4 minutos, y algunos están esperando hasta unos 25 minutos. - La UI CircleCI está a unos 20 minutos detras, a unos 30 minutos. Los nuevos flujos de trabajo y cambios de estado pueden tardar tanto en aparecer. - Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros trabajan para reducir estos retrasos. Siguiente actualización Proporcionaremos otra actualización para las 17:00 UTC.

11. 9 de octubre de 2026 a las 17:06 UTCmonitoring

    Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. Desde las 15:15 UTC, los flujos de trabajo y los empleos han comenzado de nuevo con retrasos. Lo que impacta Clientes que ejecutan flujos de trabajo y trabajos, clientes que ven tuberías, flujos de trabajo y trabajos en la interfaz de usuario CircleCI, y clientes que ven los datos de uso en la página de uso del proyecto. ¿Qué puedes esperar? - Las demoras que comienzan los flujos de trabajo y los trabajos se mantienen estables. La mayoría de los trabajos comienzan dentro de unos 4 minutos, y algunos están esperando hasta unos 8 minutos, a partir de unos 25 minutos. - La IU CircleCI permanece a unos 20 minutos de media, y algunas actualizaciones están tomando más tiempo. Los nuevos flujos de trabajo y cambios de estado pueden tardar tanto en aparecer. - Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros trabajan para reducir estos retrasos. Siguiente actualización Proporcionaremos otra actualización para las 17:30 UTC.

12. 9 de octubre de 2026 a las 17:34 UTCidentified

    Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. Desde las 15:15 UTC, los flujos de trabajo y los empleos han comenzado de nuevo con retrasos. Lo que impacta Los clientes activan oleoductos y flujos de trabajo y puestos de trabajo, los clientes ven oleoductos, flujos de trabajo y puestos de trabajo en la interfaz de usuario CircleCI y los clientes ven los datos de uso en la página de uso del proyecto. ¿Qué puedes esperar? - Desde las 17:00 UTC, las demoras han aumentado significativamente. La mayoría de los trabajos están tomando unos 12 minutos para empezar, y algunos están esperando hasta unos 30 minutos. - Desde las 17:15 UTC, algunos trabajos no están empezando. - Las tuberías se procesan más lentamente, por lo que algunos pueden tardar más en empezar. - La UI CircleCI está más de una hora atrás. Los nuevos flujos de trabajo y cambios de estado pueden tardar tanto en aparecer. - Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. - Los datos de carga de uso en la página de uso del proyecto están estancados. Gracias por su paciencia mientras nuestros ingenieros trabajan para resolver esto. Siguiente actualización Proporcionaremos otra actualización para las 18:00 UTC.

13. 9 de octubre de 2026 a las 18:08 UTCidentified

    Desde las 11:15 UTC, los clientes han experimentado trastornos en tuberías y notificaciones. Entre las 11:15 UTC y alrededor de las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron redhooks y notificaciones transaccionales (Slack y email). Entre las 13:00 UTC y las 14:40 UTC, los flujos de trabajo y los empleos comenzaron con retrasos mientras trabajamos a través del atraso. Desde las 15:15 UTC, los flujos de trabajo y los empleos han comenzado de nuevo con retrasos. Lo que impacta Los clientes activan oleoductos y flujos de trabajo y puestos de trabajo, los clientes ven oleoductos, flujos de trabajo y puestos de trabajo en la interfaz de usuario CircleCI y los clientes ven los datos de uso en la página de uso del proyecto. Qué esperar - Desde las 17:00 UTC, estamos viendo un aumento de retrasos. La mayoría de los trabajos están tomando unos 25 minutos para empezar, y algunos están esperando hasta una hora. - Desde las 17:15 UTC, algunos flujos de trabajo en curso han fracasado y un pequeño número de puestos de trabajo no están empezando. - Los nuevos oleoductos están siendo apagados y están tomando más tiempo para empezar. - La UI CircleCI está más de una hora atrás. Los nuevos flujos de trabajo y cambios de estado pueden tardar tanto en aparecer. - Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. - Los datos de carga de uso en la página de uso del proyecto están estancados. Nuestros ingenieros siguen trabajando para resolver el problema que se examina. Siguiente actualización Proporcionaremos otra actualización para las 18:30 UTC.

14. 9 de octubre de 2026 a las 18:32 UTCidentified

    Lo que ha cambiado desde nuestra última actualización * La UI CircleCI está a una hora de retraso, y hasta unos 90 minutos para algunas actualizaciones. Los flujos de trabajo y los empleos ya pueden haber funcionado, o pueden estar funcionando, incluso si la UI los muestra como no iniciado o no los muestra en absoluto. * Los trabajos que se están ejecutando están empezando más rápido. La mayoría comienza ahora dentro de unos 15 minutos, desde unos 28 minutos, aunque algunos todavía están esperando más de una hora. * Los nuevos oleoductos se retrasan cada vez más. * Algunos flujos de trabajo siguen fallando. Los flujos de trabajo que no podían ser procesados a tiempo están siendo marcados como fallidos. * Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. Sigue en curso: Los datos de carga de uso en la página de uso del proyecto están estancados. Siguiente actualización Proporcionaremos otra actualización para las 19:00 UTC.

15. 9 de octubre de 2026 a las 18:57 UTCidentified

    Lo que ha cambiado desde nuestra última actualización * Los trabajos comienzan más rápido. La mayoría comienza ahora en unos 8 minutos, bajando de unos 15 minutos, y las esperas más largas han bajado de más de una hora a unos 45 minutos. * La UI CircleCI está empezando a ponerse al día, pero todavía está detrás. Los flujos de trabajo y los empleos ya pueden haber funcionado, o pueden estar funcionando, incluso si la UI los muestra como no iniciado o no los muestra en absoluto. * Las tuberías están siendo procesadas más rápido, pero las nuevas tuberías todavía se retrasan. Continúa * Algunos flujos de trabajo y trabajos todavía están fallando. * Por favor, evite retriggering workflows that don't yet appear in the UI, as this may create duplicates. * Los datos de carga de uso en la página de uso del proyecto están estancados. Siguiente actualización Proporcionaremos otra actualización para las 19:30 UTC.

16. 9 de octubre de 2026 a las 19:29 UTCidentified

    Desde nuestra última actualización, los empleos comienzan más rápido: la mayoría comienza en unos 6 minutos, a partir de unos 8 minutos. La UI CircleCI se está poniendo al día, pero todavía una hora atrás. Se están procesando nuevas tuberías a medida que llegan. Los empleos pueden haber funcionado incluso si la UI aún no los muestra, así que por favor evite retriggering workflows that don't appear in the UI. Proporcionaremos otra actualización para las 20:00 UTC.

17. 9 de octubre de 2026 a las 20:06 UTCidentified

    Los trabajos comienzan más rápido y menos están fallando: la mayoría de los trabajos comienzan en unos 4 minutos, bajando de unos 6 minutos, y las esperas más largas han bajado de unos 30 minutos a unos 20 minutos. Las tuberías de antes en el incidente se están trabando. La interfaz de usuario CircleCI todavía está detrás, y algunas actualizaciones antiguas pueden tardar más en aparecer. Los empleos pueden haber funcionado incluso si la UI aún no los muestra, así que por favor evite retriggering workflows that don't appear in the UI. Proporcionaremos otra actualización para las 20:30 UTC.

18. 9 de octubre de 2026 a las 21:22 UTCidentified

    Desde alrededor de 20:48 UTC, no están empezando los nuevos flujos de trabajo y empleos. Hemos pausado temporalmente el inicio de nuevos trabajos para que nuestros sistemas puedan ponerse al día en el trabajo ya en curso, incluyendo actualizaciones retrasadas a la interfaz de usuario de CircleCI y API. Las actualizaciones más antiguas están apareciendo en la interfaz de usuario y la API mientras este atraso se aclara. Nuevos oleoductos todavía están siendo aceptados y apagados Por favor, evite retriggering pipelines or workflows during this time, as this may create duplicates once work resumes. Proporcionaremos otra actualización a las 22:00 UTC.

19. 9 de octubre de 2026 a las 22:09 UTCidentified

    Desde nuestra última actualización, la mayoría de los oleoductos que se retrasaron antes en el incidente han sido procesados, y sus flujos de trabajo se espera para empezar. Los nuevos flujos de trabajo y los empleos permanecen pausados mientras nos preparamos para reanudar el trabajo con seguridad. Las actualizaciones retrasadas siguen apareciendo en la interfaz de usuario de CircleCI y API. Por favor, siga evitando retriggering tuberías o flujos de trabajo, ya que esto puede crear duplicados una vez que se reanude el trabajo. Proporcionaremos otra actualización a las 22:30 UTC.

20. 9 de octubre de 2026 a las 22:28 UTCidentified

    Desde nuestra última actualización, hemos comenzado gradualmente a reanudar el trabajo, y algunos flujos de trabajo y trabajos desconcertados están empezando de nuevo. La mayoría del trabajo desconcertado todavía está esperando, y los trabajos que comienzan pueden haber esperado más de una hora. Estamos aumentando la tasa cuidadosamente para evitar sobrecargar nuestros sistemas. Las actualizaciones retrasadas siguen apareciendo en la interfaz de usuario de CircleCI y API. Por favor, continúe evitando retriggering tuberías o flujos de trabajo, ya que esto puede crear duplicados como curriculum vitae de trabajo. Proporcionaremos otra actualización a las 23:00 UTC.

21. 9 de octubre de 2026 a las 23:00 UTCidentified

    Ha comenzado un gran número de flujos de trabajo y puestos de trabajo desconcertados, y la interfaz de usuario y API de CircleCI han captado y están mostrando actualizaciones normalmente con pocos retrasos. Seguimos trabajando a través del trabajo pendiente. Los trabajos de la cola pueden haber esperado aproximadamente una hora o más para empezar, y algunos trabajos de Linux están esperando hasta unos 10 minutos para tener capacidad. Por favor, siga evitando que se repita mientras el trabajo solicitado continúa en proceso. Proporcionaremos otra actualización a las 23:30 UTC.

22. 9 de octubre de 2026 a las 23:38 UTCidentified

    Todavía estamos trabajando a través de un importante atraso de los flujos de trabajo y empleos apagados. Los tiempos de espera están mejorando pero siguen siendo más largos de lo normal y algunos trabajos han esperado más de una hora. La interfaz de usuario de CircleCI y la API permanecen al día. Por favor, evite retriggering tuberías o flujos de trabajo mientras el atraso se aclara, ya que esto puede crear duplicados. Proporcionaremos otra actualización para las 00:00 UTC.

23. 9 de octubre de 2026 a las 23:59 UTCidentified

    Desde nuestra última actualización, el atraso de los flujos de trabajo y puestos de trabajo desconocidos, a partir de las 23:47 UTC. Los flujos de trabajo y los empleos están empezando en segundos, y la interfaz de usuario y API de CircleCI están actualizados. Estamos monitoreando nuestros sistemas para asegurarnos de que permanezcan estables. Proporcionaremos otra actualización para las 00:30 UTC.

24. 10 de octubre de 2026 a las 0:45 UTCidentified

    Los flujos de trabajo y los empleos han seguido empezando normalmente, en segundos, y la interfaz de usuario y API de CircleCI permanecen al día. Las notificaciones de Slack y email retrasadas antes en el incidente siguen siendo entregadas. Los datos de carga de uso en la página de uso del proyecto están estancados. Continuamos monitoreando nuestros sistemas de cerca y proporcionaremos otra actualización para 01:15 UTC.

25. 10 de octubre de 2026 a las 1:23 UTCmonitoring

    Los flujos de trabajo y los empleos están empezando y funcionando normalmente, y la interfaz de usuario y API de CircleCI están actualizados. Continuamos monitoreando nuestros sistemas de cerca para asegurarnos de que permanezcan estables. Proporcionaremos otra actualización para las 02:00 UTC.

26. 10 de octubre de 2026 a las 2:08 UTCresolved

    Entre las 11:15 UTC y las 23:47 UTC el 9 de octubre, los clientes experimentaron retrasos y fallas en tuberías, flujos de trabajo y empleo, junto con retrasos en la IU CircleCI, API y notificaciones. De las 11:15 a las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron webhooks y Slack y notificaciones de correo electrónico. De unas 13:00 a 14:40 UTC, los flujos de trabajo y los trabajos comenzaron con retrasos mientras trabajamos a través del atraso. De unas 15:15 a 20:48 UTC, los flujos de trabajo y los empleos comenzaron con crecientes retrasos, de hasta una hora, y la interfaz de usuario y API de CircleCI cayeron hasta cerca de 2 horas. Durante este tiempo, algunos empleos no comenzaron y algunos flujos de trabajo en curso fallaron. De 20:48 a aproximadamente 22:10 UTC, nos detuvimos temporalmente iniciando nuevos flujos de trabajo y trabajos para que nuestros sistemas pudieran recuperarse. Los nuevos oleoductos fueron aceptados y apagados durante este tiempo. De unas 22:10 a 23:47 UTC, reanudaron los flujos de trabajo y los trabajos solicitados y fueron procesados. Algunos de ellos habían esperado hasta cerca de 2 horas. La cuestión se ha resuelto y toda la funcionalidad afectada ha vuelto a la normalidad. Los datos de carga de uso en la página de uso del proyecto aún no están actualizados y se actualizarán una vez que nuestros backfills de datos se completen. Los clientes cuyos empleos fallaron durante esta ventana pueden regir trabajos afectados. Le agradecemos su paciencia mientras nuestros ingenieros trabajaron en implementar una solución.

27. 12 de octubre de 2026 a las 22:32 UTCpostmortem

    ## Summary Entre las 11:15 UTC y las 23:47 UTC el 9 de octubre, los clientes de CircleCI experimentaron retrasos y fallos durante horas a través de tuberías, flujos de trabajo y empleo, junto con retrasos en la interfaz de usuario de CircleCI, API y notificaciones. * De las 11:15 a las 13:00 UTC, se crearon oleoductos pero no procesados, y no se enviaron webhooks y Slack y notificaciones de correo electrónico. * De las 13:00 a las 14:40 UTC, los flujos de trabajo y los trabajos comenzaron con retrasos mientras trabajábamos a través del atraso. * De 15:15 a 20:48 UTC, los flujos de trabajo y los empleos comenzaron con crecientes retrasos, de hasta una hora, y la interfaz de usuario y API de CircleCI cayeron hasta cerca de 2 horas. Durante este tiempo, algunos empleos no comenzaron y algunos flujos de trabajo en curso fallaron. * De 20:48 a 22:10 UTC, nos detuvimos temporalmente iniciando nuevos flujos de trabajo y trabajos para que nuestros sistemas pudieran recuperarse. Los nuevos oleoductos fueron aceptados y apagados durante este tiempo. * De 22:10 a 23:47 UTC, se reanudaron los flujos de trabajo y los empleos solicitados y se procesaron con éxito. Algunos de ellos habían esperado hasta cerca de 2 horas. * Para las 23:47, el incidente fue mitigado. La página de estado para este incidente se puede encontrar en [ 9 de octubre - Delay in data appearing in UI and API](https://status.circleci.com/incidents/6cfhhlr4rmm0). Los clientes experimentaron un incidente similar a principios de la semana en [6 de octubre - Retrasos en tuberías, flujos de trabajo, datos de la interfaz de usuario y notificaciones] (https://status.circleci.com/incidents/z4hbq8h49j8c). Múltiples servicios CircleCI utilizan Temporal respaldado por Postgres como un mecanismo de cola confiable, y ambos incidentes tuvieron la misma causa: la tasa de escrituras a la instancia Postgres de Temporal fue más rápida que el registro de transacciones de Postgres podría archivar esos escritos. En ambos casos, esto causó retrasos de varias horas en el procesamiento de tuberías y notificaciones de estado. Evaluamos varias atenuaciones, luego se detuvo el nuevo flujo de trabajo para que el sistema pudiera recuperarse con seguridad, y se desplegó gradualmente. Luego hemos acelerado el trabajo hasta que nuestros sistemas vuelvan a la normalidad. Para resolver permanentemente el cuello de botella, tenemos trabajo dividido en múltiples instancias temporales, cada una con su propia base de datos independiente y grupos de trabajadores, y cargamos balance a través de ellos. Ya habíamos programado trabajo de infraestructura a partir de la semana del 12 de octubre que habría eliminado este cuello de botella exacto e impedido estos incidentes. Así que a partir del 19:11 el 9 de octubre nuestro equipo de ingeniería implementó, probó y lanzó una versión más simple de estos cambios dentro de unas pocas horas. Añadimos además nuevas alertas y sintonizamos las bases de datos subyacentes para mejorar el rendimiento bajo alta carga. Los clientes cuyo trabajo falló durante esta ventana pueden reeducarlos. ## Background Para ejecutar trabajos de clientes, CircleCI ejecuta una serie de pasos: aceptamos oleoductos de clientes; asignamos empleos para esos oleoductos a los trabajadores; entregamos actualizaciones de estado para esos oleoductos y empleos; y cobramos a los clientes por los créditos que consumen esos empleos. Cada uno de estos pasos es implementado por un servicio independiente, con colas fiables en el medio. Históricamente hemos implementado estas colas confiables con RabbitMQ en la parte superior del almacenamiento duradero, con retroceso exponencial y colas de cartas muertas para la confiabilidad. Durante el último año, hemos vuelto a aplicar cada vez más nuestras confiables colas en [Temporal] (https://temporal.io/), que ofrece mejores garantías de durabilidad y fiabilidad sobre un modelo de programación más simple y potente. Nuestro servicio de construcción \(que convierte un oleoducto config en un plan ejecutable\), nuestro servicio orquestador de flujo de trabajo \(que distribuye tareas a los trabajadores\), nuestro servicio de notificación \(que entrega actualizaciones de estado\), y nuestro servicio de carga \(que cobra a los clientes por créditos\) ahora utilizan Temporal. Temporal almacena el estado para sus flujos de trabajo y actividades \(llamado “historia”\) en una base de datos, y este es el único componente en una instancia Temporal que es sincrónico y stateful. Como consecuencia, la capacidad de una instancia temporal para aceptar y ejecutar flujos de trabajo depende de la tasa de escritura de su base de datos de respaldo. También hemos configurado Temporal para eliminar los flujos de trabajo y actividades completados de su historia 3 días después de completarlos. En el momento de este incidente, usamos una sola instancia temporal agrupada respaldada por una instancia multi-AZ Postgres RDS para todas estas colas confiables. Mientras que una instancia de RDS Multi-AZ es resistente a fallos de zona, mantiene la consistencia de la base de datos a través de un solo script-ahead-log \(WAL\). En el momento en que había configurado nuestra instancia Postgres para almacenar su WAL en un volumen de registro dedicado \(DLV\) por lo que los escritos de registro no compitieron con los datos escritos. La base de datos archiva el registro continuamente al almacenamiento de copia de seguridad, y sólo puede reutilizar el espacio en el volumen después de que el registro haya sido archivado. Si la base de datos escribe registros más rápido que los archivos, el volumen llena y Postgres no tiene espacio para escribir su registro WAL. Entonces la base de datos deja de aceptar los escritos entrantes y va completamente solo de lectura. Un DLV RDS se limita a 1TB de almacenamiento y 3000 IOPS y por AWS estos límites son codificados y no pueden aumentarse. ## What Happened \(Todas las veces UTC\) Uno de los factores que contribuyeron al incidente del 6 de octubre fue que estábamos procesando una alta tasa de eliminaciones de la historia temporal al mismo tiempo que el trabajo entrante, que a su vez puso presión en la base de datos de respaldo. Para resolver el incidente del 6 de octubre, cambiamos los ajustes de limpieza en las tablas más grandes de Temporal y trasladamos el registro de transacción a su volumen dedicado. Estos cambios eliminaron la principal fuente de registros de transacciones, pero no consideraron los escritos adicionales de registro de borraciones programadas. Debido a que hemos configurado Temporal para eliminar los flujos de trabajo y las actividades completados de su historia 3 días después de que terminen, la historia del 6 de octubre estaba programada para ser borrada el 9 de octubre. A partir de las 08:00 el 9 de octubre, Temporal comenzó a procesar las eliminaciones programadas, y como consecuencia, el espacio libre en el Postgres DLV comenzó a caer precipitadamente, de 0.8TB a las 08:00 a 0.1TB a las 10:10. Nuestro monitoreo alertó a las 10:28 y declaramos un incidente a las 10:31. Mientras nuestro equipo de infraestructura estaba investigando, a las 11:15 el DLV se quedó sin espacio y la instancia Postgres fue leída. Esto detuvo todo el procesamiento Temporal en sus pistas. A las 11:42, reiniciamos Postgres para mover el registro WAL del DLV al volumen de datos y utilizar el espacio de disco de repuesto e IOPS allí. Esta maniobra había mitigado el incidente el 6 de octubre y sabíamos que tardaría unos 60 minutos. Mientras que la base de datos estaba descansando, comenzamos a implementar varias técnicas de descarga de carga en el río Temporal: * Comenzamos a investigar si deberíamos eliminar las cargas de trabajo en conjunto para mantener el resto en movimiento, pero en última instancia decidimos que esto no proporcionaría ningún valor. * At 12:29, we flagged off credit charge updates, which represented 12% of Temporal activities. Esto dejó la página de uso de tuberías con datos de carga de establos, hasta que lo volveríamos a rellenar, pero no perdería datos o evitaría que los oleoductos corrieran. A las 12:59, la base de datos estaba atrasada y comenzó a procesar trabajos que habían colado desde las 11:15 y para las 14:40, este atraso había despejado y los trabajos estaban comenzando a tiempo. Sin embargo, antes de las 15:15, los retrasos devueltos como limpieza de enrutamiento de la base de datos habían caído muy atrás en las tablas de usos de Temporal para rastrear el trabajo apagado y programado. Esas tablas normalmente tienen decenas de miles de filas eliminadas esperando la limpieza, pero por la tarde, tuvieron decenas de millones de filas. Cada operación Temporal tuvo que leer más allá de esas filas, por lo que la base de datos pasó mucho más tiempo de procesamiento en cada uno y Temporal corrió más lento. Esto dio lugar a que los clientes continuaran viendo retrasos por hora en el inicio de los oleoductos y en actualizaciones de estado. Durante las próximas horas intentamos varias mitigacións, incluyendo: * Manipulación de valores de configuración temporal para reducir la presión de la base de datos. Esto tuvo un efecto mínimo. * Trabajos manuales de vacío para limpiar filas muertas en Postgres. Esto terminó compitiendo por la CPU con las propias consultas, y finalmente fue contraproducente. Los cancelamos a las 17:45 para aliviar la presión sobre la carga de la base de datos. * Comenzamos a intentar trasladar todas las maletas de notificación a una instancia temporal separada. Esto representó el 18% de las actividades temporales. Terminamos con éxito las notificaciones móviles para 17:07. * A las 17:16, implementamos con éxito una optimización en nuestra representación del estado del oleoducto, que la redujo en un 5%. Que a su vez redujo el tamaño de la base de datos escribe y, por lo tanto, la presión de datos en el registro de Postgres WAL. Ninguna de estas medidas mitigó plenamente la cuestión. Para 20:48, nos dimos cuenta de que Postgres estaba ahora agitando en la base de datos CPU y ya no estaba embotellado en las escrituras de registro. Nos dimos cuenta además de que nuestros sistemas de corriente avanzada estaban presentando nuevos trabajos y también reintroduciendo trabajos que anteriormente se habían presentado y fracasado. Reconociendo que estábamos en una tormenta clásica de reingreso, detuvimos todo el trabajo entrante y de reingreso y lo dejamos colar, para que la base de datos pueda completar completamente el trabajo en proceso. Luego lentamente hemos acelerado el trabajo de búsqueda de 22:07 para mantener la base de datos a una carga sostenible. Esto tuvo éxito a las 23:47 cuando se había iniciado todo el trabajo solicitado, y cerramos el incidente a las 02:08 el 10 de octubre. ## Future Prevention and Process Improvement ## Multiple Temporal Instances En paralelo con la mitigación y resolución de incidentes, a partir de 19:11 el 9 de octubre, también comenzamos a levantar múltiples instancias temporales endurecidas y a implementar la capacidad de carga-equilibrio entrando trabajo entre ellos. Cada una de las múltiples instancias Temporales mantiene su propia base de datos independiente y grupos de trabajadores, por lo que está aislado de los otros. Como elemento de acción postmortem del incidente del 6 de octubre, ya habíamos programado trabajos de infraestructura que habrían eliminado el cuello de botella de una sola instancia temporal y la base de datos Postgres, a partir del 12 de octubre y esperando tomar 2 semanas. El 9 de octubre nos dimos cuenta de que este trabajo simplemente no podía esperar, por lo que nuestro equipo de ingeniería implementó, probó y lanzó una versión más simple de los cambios previstos dentro de unas pocas horas. Estos cambios terminaron con éxito a las 01:45 el 10 de octubre. **Además, estamos cambiando cómo almacenamos y monitorizamos los registros de transacciones.** Nuestra base de datos Temporal ya no utiliza el volumen de registro de tamaño fijo. Estamos añadiendo alertas sobre cuán lejos está el archivo de registro y cuán rápido escribe la base de datos registros, para que podamos actuar horas antes de lo que hicimos el 9 de octubre. **También estamos revisando el calendario de eliminación del Temporal.** Temporal elimina el trabajo terminado unos días después de que funcione, por lo que un día ocupado vuelve como carga de la base de datos más adelante en la semana. Estamos cambiando cuándo y cuán rápido corren esas eliminaciones. **Estamos cambiando cómo nuestros sistemas se reinician cuando Temporal es lento.** El 9 de octubre, nuestros sistemas retrataron el trabajo fallido contra Temporal y se sumaron a su carga. Mientras nos comprometimos después del incidente del 6 de octubre, estamos cambiando nuestros sistemas para esperar a que Temporal se recupere así que el trabajo no se deja caer. Conclusión La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver estos incidentes. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 8 de octubre de 2026 a las 13:00 UTCidentified

   Los clientes pueden estar experimentando tiempos elevados de espera para trabajos de máquina. Estamos trabajando para resolver esto.

2. 8 de octubre de 2026 a las 13:34 UTCidentified

   Los clientes que utilizan trabajos de máquina Linux están experimentando tiempos elevados de espera, promediando unos 11 minutos, con las esperas más largas superiores a 30 minutos en el medio, el brazo.medio y el brazo.grandes clases de recursos. Nuestros ingenieros han identificado el problema y están trabajando en una solución. Proporcionaremos otra actualización para las 14:00 UTC.

3. 8 de octubre de 2026 a las 14:04 UTCidentified

   Los clientes que utilizan empleos de máquinas Linux están experimentando tiempos elevados de espera, promediando unos 40 minutos, con las esperas más largas de más de 50 minutos. La mayoría de las clases de recursos de la máquina Linux se ven afectadas, incluyendo medio, grande, xlarge, 2xlarge y sus equivalentes de Arm. Nuestros ingenieros han identificado el problema y están trabajando en una solución. Proporcionaremos otra actualización a las 14:30 UTC.

4. 8 de octubre de 2026 a las 14:37 UTCidentified

   Los clientes que utilizan trabajos de máquina Linux y Docker remoto están experimentando tiempos elevados de espera. Los tiempos de espera han comenzado a disminuir y ahora promedio unos 20 minutos, con las esperas más largas superiores a 40 minutos en algunas clases de recursos. Nuestros ingenieros han identificado el problema y están trabajando en una solución. Proporcionaremos otra actualización para las 15:00 UTC.

5. 8 de octubre de 2026 a las 15:01 UTCidentified

   Se ha implementado una solución y los tiempos de espera están disminuyendo, pero los clientes que utilizan trabajos de máquina Linux y Remote Docker siguen experimentando retrasos. Los tiempos de espera actualmente promedio alrededor de 11 minutos, con las esperas más largas de 35 minutos en algunas clases de recursos. Estamos trabajando para añadir la capacidad lo más rápido posible. Proporcionaremos otra actualización a las 15:30 UTC.

6. 8 de octubre de 2026 a las 15:31 UTCidentified

   Los tiempos de espera continúan disminuyendo, pero los clientes que utilizan trabajos de máquina Linux y Docker remoto siguen experimentando retrasos. Los tiempos de espera actualmente promedio alrededor de 6 minutos. Las esperas más largas, hasta unos 20 minutos, están en el 2x grande, el brazo.2x grande y gpu.nvidia. clases de recursos pequeños. Estamos trabajando para añadir la capacidad lo más rápido posible. Proporcionaremos otra actualización para las 16:00 UTC.

7. 8 de octubre de 2026 a las 15:59 UTCidentified

   Los tiempos de espera continúan disminuyendo, pero los clientes que utilizan trabajos de máquina Linux y Docker remoto siguen experimentando retrasos. Los tiempos de espera actualmente promedio alrededor de 90 segundos, con el más largo espera hasta alrededor de 6 minutos en algunas clases de recursos. Estamos trabajando para añadir la capacidad lo más rápido posible. Proporcionaremos otra actualización a las 16:30 UTC.

8. 8 de octubre de 2026 a las 16:09 UTCmonitoring

   Los tiempos de espera para los clientes que usan trabajos de máquina Linux y Docker remoto han vuelto a la normalidad. Estamos monitoreando para confirmar que los tiempos de espera permanecen estables mientras seguimos agregando capacidad. Proporcionaremos otra actualización a las 16:30 UTC.

9. 8 de octubre de 2026 a las 16:35 UTCresolved

   Entre las 12:40 UTC y las 16:00 UTC el 8 de octubre, los clientes que utilizan trabajos de máquina Linux y Docker remoto experimentaron tiempos elevados de espera. El problema se ha resuelto y los tiempos de espera han vuelto a la normalidad. Le agradecemos su paciencia mientras nuestro equipo trabajó en implementar una solución.

10. 8 de octubre de 2026 a las 17:54 UTCpostmortem

    ## **Summary** Entre el 1 de octubre y el 8 de octubre de 2026, los clientes de CircleCI experimentaron cinco incidentes separados en los que los trabajos esperaban más tiempo de lo normal para empezar, o no comenzaron. Tres de los incidentes fueron impulsados por la disponibilidad de casos limitados de nuestro proveedor de nube. Uno fue causado por un problema de configuración en nuestra infraestructura de programación, y uno por límites de memoria en un servicio interno, que planteamos durante el incidente. * **Octubre 1, 07:57 a 10:24 UTC:** Docker Gen 2 trabajos esperaron hasta 30 minutos para empezar. Un problema de configuración impidió que los servidores de programación Gen 2 usaran sus discos locales de alto rendimiento. Durante un estallido en el tráfico, los discos de retroceso saturados y la colocación de trabajo se ralentizó. * ** 7 de octubre, 13:27 a 14:06 UTC:** Trabajos de máquina esperó más de lo normal porque no podíamos adquirir suficientes máquinas virtuales de nuestro proveedor de nube. * ** 7 de octubre de 14:24 a 15:21 UTC:** Algunos empleos fallaron con un error de infraestructura, y los flujos de trabajo se retrasaron. El servicio que da a cada trabajo su configuración al inicio se agotó de la memoria y se reinicia. * ** 7 de octubre de 18:49 a 20:05 UTC:** Trabajos Docker Gen 2 esperó más de lo normal porque no podíamos adquirir suficientes instancias de nuestro proveedor de nube. * 8 de octubre, 12:48 a 16:00 UTC:** Trabajos de máquinas Linux y empleos remotos Docker esperaron hasta 50 minutos para empezar. Nuestro proveedor de nube no tenía suficiente del tipo de instancia que solicitamos, y un defecto en la lógica que elige un tipo de instancia diferente nos impidió utilizar alternativas. Los trabajos que esperaron durante estos incidentes se retrasaron, no se perdieron. Los clientes cuyos empleos fallaron con un error de infraestructura durante el incidente del 7 de octubre de 14:24 a 15:21 UTC pueden volver a ejecutarlos. Las páginas de estado originales se pueden encontrar a continuación: * [October 1 - Delays starting Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 de octubre - Retraso en la puesta en marcha de las tareas de empleo de la máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 de octubre - Elevated level of infra fails on customer jobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 de octubre - Mayor tiempo de espera para Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 de octubre - Tiempos de espera elevados para el empleo de la máquina] (https://status.circleci.com/incidents/jn756xtsy4xg) ## **Background** Cada trabajo que funciona en CircleCI necesita compute. De donde viene ese computador depende el ejecutante. Trabajos Docker funcionan en grupos de servidores que programan trabajo en una flota de instancias. El programador es el software en esos servidores que decide qué instancia ejecuta cada trabajo. Los trabajos de Gen 2 Docker corrieron en uno de esos grupos en el momento del incidente del 1 de octubre. Los trabajos de Docker Gen 1 se distribuyen en varios grupos. Trabajos de máquina, incluyendo empleos remotos Docker, conseguir una máquina virtual dedicada. Un trabajo remoto de Docker se maneja como un trabajo de máquina Linux desde sumisión a través de la provisión. Nuestro servicio de suministro de máquinas solicita a cada máquina de nuestro proveedor de nubes en una de las dos regiones que normalmente utilizamos para trabajos de máquina. Cuando el proveedor no puede suministrar el tipo de instancia que solicitamos, el servicio cae: solicita un tipo de instancia diferente, o una región diferente, de una lista que mantenemos. Un trabajo espera hasta que una máquina esté disponible. Cuando cualquier trabajo comienza, pide un servicio de configuración de trabajo para su configuración. Ese servicio funciona como un conjunto de cápsulas, que son pequeñas copias del mismo programa. Si se detienen demasiados vainas, los vainas restantes cargan más, y los trabajos no pueden comenzar hasta que el servicio se recupera. Estos caminos dependen de tres tipos de capacidad: el rendimiento de nuestros sistemas de programación, el suministro de instancias de nuestro proveedor de nube, y la memoria y el número de copias de los servicios que inician trabajos. Un déficit en cualquiera de ellos hace que los trabajos esperen o fallen. ## ** What Happened** \(Todas las veces UTC\) #### **Octubre 1: Docker Gen 2 empleos retrasados hasta 30 minutos A las 07:44, la actividad de disco en los servidores que programan empleos Gen 2 Docker aumentó al 90% de la capacidad y se quedaron allí. A las 07:57, el número de empleos Docker que esperan para empezar comenzó a crecer, y los tiempos de espera se elevaron con él. Una alerta automatizada llamó al ingeniero de guardia a las 08:08. Declaramos un incidente a las 08:42. A las 08:43, los ingenieros identificaron latencia de disco alto en los servidores de programación. Primero creían que los discos eran demasiado lentos para la carga, así que prepararon un cambio a un tipo de disco más rápido. A las 09:01, el equipo acordó dos flujos de trabajo: mover los servidores a discos más rápidos, y añadir un segundo grupo Gen 2 para que los trabajos se dividieran en dos grupos. A las 09:41, los ingenieros encontraron la causa raíz. Cada servidor de programación tiene discos rápidos conectados directamente a él, y el programador está destinado a mantener sus datos de trabajo allí. Estos servidores se ejecutan en una imagen del sistema operativo endurecida por seguridad, y en esa imagen los discos rápidos no se estaban utilizando. El programador escribió sus datos para disminuir los discos conectados a la red. El script que establece los discos rápidos falló sin un error, y una brecha en el registro en estos servidores escondió el fallo. El tráfico Gen 2 también se había vuelto cada vez más explosivo. Los discos más lentos saturados durante esas ráfagas, y el cronogramador cayó detrás. Los tiempos de espera alcanzaron el pico a las 09:54, cuando los trabajos de la clase de recursos media Gen 2 esperaban hasta 30 minutos. A las 09:55, los ingenieros aplicaron una solución que establece los discos rápidos correctamente. A las 10:11, el programador comenzó a colocar trabajos más rápido, lo que confirmó que los servidores podían mantenerse al día con nuevos trabajos. Los tiempos de espera para el Gen 2 cayeron a 13 minutos a las 10:14, 7 minutos a las 10:17, y 1 minuto 30 segundos a las 10:20. Movimos la página de estado a monitorizar a las 10:24 y resolvimos el incidente a las 10:45. A las 11:20, el segundo grupo Gen 2 comenzó a funcionar. ### ** October 7, 13:27 to 14:06: Elevated wait times for machine jobs** Declaramos un incidente a las 13:27 después de ver los tiempos elevados de cola y espera. Pusimos en la página de estado a las 13:31. A las 13:31, los ingenieros vieron que estábamos luchando para adquirir máquinas virtuales para trabajos de máquina, y que el número de trabajos que esperaban para empezar era alto principalmente para trabajos de máquina. A las 13:34, los tiempos de espera fueron elevados a través de los ejecutores. A las 13:48, los tiempos de espera comenzaron a recuperarse mientras más máquinas estaban disponibles, y resolvimos el incidente a las 14:06. ### ** October 7, 14:24 to 15:21: Job failures and workflow delays** Poco después del incidente anterior fue marcado como resuelto, declaramos un nuevo incidente a las 14:24 debido a una fuerte caída en el número de puestos de trabajo presentados a nuestros sistemas de ejecución. A las 14:26, los ingenieros vieron que las cápsulas del servicio de configuración de trabajo estaban descansando. Pods that restart leave fewer copies of the service to answer requests, and jobs that could not retrieve their settings after repeated attempts failed with an infrastructure error. Los flujos de trabajo que ya estaban funcionando esperaban actualizaciones de trabajos que no habían comenzado. A las 14:35, los ingenieros aumentaron la cantidad de memoria disponible a las vainas y aumentaron el número de vainas, lo que dio al servicio más copias para compartir la carga. También aumentamos la cantidad de memoria disponible Las presentaciones de Job comenzaron a recuperarse, y el número de mensajes que fluyen a través de nuestro sistema de flujo de trabajo volvió a niveles normales. A las 14:44, trasladamos la página de estado al monitoreo. Los Pods en el servicio de configuración de trabajo alcanzaron sus límites de memoria y reiniciaron. Aumentamos las asignaciones de memoria y los recuentos de pod, y el servicio recuperado. A las 15:13, aumentamos el número de instancias en nuestros grupos de Docker Gen 2 para que podamos trabajar a través de la acumulación de trabajos de espera rápidamente. Resolvimos el incidente a las 15:21. ### ** October 7, 18:49 to 20:05: Elevated wait times for Docker Gen 2 jobs** Declaramos un nuevo incidente a las 18:49 después de Docker Gen 2 tiempos de espera. A las 18:51, los ingenieros confirmaron que una escasez de instancias disponibles nos impidió adquirir suficiente de ellos, lo que aumentó los tiempos de espera. Los tiempos de espera difieren del tamaño de la clase de recursos. A las 19:52, los tiempos de espera promedio eran inferiores a una hora antes, ya que se disponía de más capacidad, aunque prosiguieron breves picos, y trasladamos la página de estado a monitorizar. Resolvimos el incidente a las 20.05. ### ** October 8: Linux machine and remote Docker jobs wait up to 50 minutes** Declaramos un incidente a las 12:48 después de ver un gran número de trabajos esperando para empezar y largos tiempos de espera para los trabajos de máquina y Docker remoto. A las 12:49, los ingenieros vieron que nuestro proveedor de nube no podía suministrar suficientes casos. Los retrasos continuaron subiendo mientras investigamos. A las 13:13 comenzamos a examinar la lógica que elige un tipo de instancia o región diferente cuando nuestra primera opción no está disponible. A las 13:24, sospechábamos que un defecto en esa lógica nos impedía utilizar otros tipos de instancia en nuestra región primaria, por lo que desactivamos nuestra región de retroceso y confirmamos la causa del defecto. Los ingenieros comenzaron a trabajar en una solución y la desplegaron a las 14:49. El servicio comenzó a solicitar otros tipos de instancia y comenzó máquinas en gran número. A las 14:58, la cola de trabajo esperando una máquina cayó constantemente. Los tiempos promedios de espera en las clases de recursos continuaron bajando a la hora siguiente mientras trabajamos a través del atraso de los trabajos de espera. A las 16:00, la cola de trabajo esperando una máquina limpiada y el número de trabajos de espera volvieron a la normalidad. Movimos la página de estado a monitorizar a las 16:09 y resolvimos el incidente a las 16:35. ## **Future Prevention and Process Improvement** Estamos tomando las siguientes medidas para fortalecer la resiliencia de los tiempos de inicio de trabajo, incluyendo la diversificación de la oferta, la lógica de retroceso y la detección anterior. **Estamos expandiendo nuestras regiones de computación.** En los incidentes del 7 y 8 de octubre, nuestro proveedor de nube no pudo suministrar suficientes casos en las regiones que usamos. Estamos agregando nuevas regiones a nuestra lógica de retroceso para manejar picos de demanda que superan nuestras regiones preferidas. **Estamos fijando la lógica que elige un tipo de instancia diferente.** El 8 de octubre, un defecto impidió que el servicio de suministro de máquinas utilizara otros tipos de instancia en la misma región. Hemos implementado una solución durante el incidente y ahora estamos revisando y refactorizando esta lógica en su conjunto, con pruebas, para que una escasez de un tipo de instancia mueva el trabajo a otro. **Estamos ampliando los tipos de instancia que ofrecemos y asegurando capacidad adicional.** Estamos trabajando con nuestro proveedor de cloud para reservar capacidad adicional en nuestras regiones existentes, y estamos agregando tipos de instancias que pueden funcionar. La demanda industrial de computación de alto rendimiento está creciendo. Estamos diversificando dónde y cómo generamos capacidad para que nuestros clientes estén aislados de la variación de la oferta. **Añadimos un segundo grupo de Docker Gen 2 para que las ráfagas de tráfico se distribuyan en dos grupos.** También estamos agregando alertas sobre la saturación del disco servidor de programación y sobre lo rápido que el programador coloca empleos, y una alerta que dispara cuando un servidor comienza sin sus discos rápidos en uso. Hicimos que el script de configuración de disco falla con un error, y restauramos el envío de registros de estos servidores para que un problema similar sea visible antes. La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver estos incidentes. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de octubre de 2026 a las 18:54 UTCidentified

   Hay un aumento de tiempo de espera para trabajos en Docker Gen2.

2. 7 de octubre de 2026 a las 19:00 UTCidentified

   Nota: los retrasos serán más notables para las personas que corren en Docker `xlarge` y arriba.

3. 7 de octubre de 2026 a las 19:52 UTCmonitoring

   Todavía estamos viendo picos en tiempos de espera de tarea, pero en promedio los tiempos de espera están buscando mejor para todos los Docker Gen2.

4. 7 de octubre de 2026 a las 20:05 UTCresolved

   Este incidente ha sido resuelto.

5. 8 de octubre de 2026 a las 17:54 UTCpostmortem

   ## **Summary** Entre el 1 de octubre y el 8 de octubre de 2026, los clientes de CircleCI experimentaron cinco incidentes separados en los que los trabajos esperaban más tiempo de lo normal para empezar, o no comenzaron. Tres de los incidentes fueron impulsados por la disponibilidad de casos limitados de nuestro proveedor de nube. Uno fue causado por un problema de configuración en nuestra infraestructura de programación, y uno por límites de memoria en un servicio interno, que planteamos durante el incidente. * **Octubre 1, 07:57 a 10:24 UTC:** Docker Gen 2 trabajos esperaron hasta 30 minutos para empezar. Un problema de configuración impidió que los servidores de programación Gen 2 usaran sus discos locales de alto rendimiento. Durante un estallido en el tráfico, los discos de retroceso saturados y la colocación de trabajo se ralentizó. * ** 7 de octubre, 13:27 a 14:06 UTC:** Trabajos de máquina esperó más de lo normal porque no podíamos adquirir suficientes máquinas virtuales de nuestro proveedor de nube. * ** 7 de octubre de 14:24 a 15:21 UTC:** Algunos empleos fallaron con un error de infraestructura, y los flujos de trabajo se retrasaron. El servicio que da a cada trabajo su configuración al inicio se agotó de la memoria y se reinicia. * ** 7 de octubre de 18:49 a 20:05 UTC:** Trabajos Docker Gen 2 esperó más de lo normal porque no podíamos adquirir suficientes instancias de nuestro proveedor de nube. * 8 de octubre, 12:48 a 16:00 UTC:** Trabajos de máquinas Linux y empleos remotos Docker esperaron hasta 50 minutos para empezar. Nuestro proveedor de nube no tenía suficiente del tipo de instancia que solicitamos, y un defecto en la lógica que elige un tipo de instancia diferente nos impidió utilizar alternativas. Los trabajos que esperaron durante estos incidentes se retrasaron, no se perdieron. Los clientes cuyos empleos fallaron con un error de infraestructura durante el incidente del 7 de octubre de 14:24 a 15:21 UTC pueden volver a ejecutarlos. Las páginas de estado originales se pueden encontrar a continuación: * [October 1 - Delays starting Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 de octubre - Retraso en la puesta en marcha de las tareas de empleo de la máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 de octubre - Elevated level of infra fails on customer jobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 de octubre - Mayor tiempo de espera para Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 de octubre - Tiempos de espera elevados para el empleo de la máquina] (https://status.circleci.com/incidents/jn756xtsy4xg) ## **Background** Cada trabajo que funciona en CircleCI necesita compute. De donde viene ese computador depende el ejecutante. Trabajos Docker funcionan en grupos de servidores que programan trabajo en una flota de instancias. El programador es el software en esos servidores que decide qué instancia ejecuta cada trabajo. Los trabajos de Gen 2 Docker corrieron en uno de esos grupos en el momento del incidente del 1 de octubre. Los trabajos de Docker Gen 1 se distribuyen en varios grupos. Trabajos de máquina, incluyendo empleos remotos Docker, conseguir una máquina virtual dedicada. Un trabajo remoto de Docker se maneja como un trabajo de máquina Linux desde sumisión a través de la provisión. Nuestro servicio de suministro de máquinas solicita a cada máquina de nuestro proveedor de nubes en una de las dos regiones que normalmente utilizamos para trabajos de máquina. Cuando el proveedor no puede suministrar el tipo de instancia que solicitamos, el servicio cae: solicita un tipo de instancia diferente, o una región diferente, de una lista que mantenemos. Un trabajo espera hasta que una máquina esté disponible. Cuando cualquier trabajo comienza, pide un servicio de configuración de trabajo para su configuración. Ese servicio funciona como un conjunto de cápsulas, que son pequeñas copias del mismo programa. Si se detienen demasiados vainas, los vainas restantes cargan más, y los trabajos no pueden comenzar hasta que el servicio se recupera. Estos caminos dependen de tres tipos de capacidad: el rendimiento de nuestros sistemas de programación, el suministro de instancias de nuestro proveedor de nube, y la memoria y el número de copias de los servicios que inician trabajos. Un déficit en cualquiera de ellos hace que los trabajos esperen o fallen. ## ** What Happened** \(Todas las veces UTC\) #### **Octubre 1: Docker Gen 2 empleos retrasados hasta 30 minutos A las 07:44, la actividad de disco en los servidores que programan empleos Gen 2 Docker aumentó al 90% de la capacidad y se quedaron allí. A las 07:57, el número de empleos Docker que esperan para empezar comenzó a crecer, y los tiempos de espera se elevaron con él. Una alerta automatizada llamó al ingeniero de guardia a las 08:08. Declaramos un incidente a las 08:42. A las 08:43, los ingenieros identificaron latencia de disco alto en los servidores de programación. Primero creían que los discos eran demasiado lentos para la carga, así que prepararon un cambio a un tipo de disco más rápido. A las 09:01, el equipo acordó dos flujos de trabajo: mover los servidores a discos más rápidos, y añadir un segundo grupo Gen 2 para que los trabajos se dividieran en dos grupos. A las 09:41, los ingenieros encontraron la causa raíz. Cada servidor de programación tiene discos rápidos conectados directamente a él, y el programador está destinado a mantener sus datos de trabajo allí. Estos servidores se ejecutan en una imagen del sistema operativo endurecida por seguridad, y en esa imagen los discos rápidos no se estaban utilizando. El programador escribió sus datos para disminuir los discos conectados a la red. El script que establece los discos rápidos falló sin un error, y una brecha en el registro en estos servidores escondió el fallo. El tráfico Gen 2 también se había vuelto cada vez más explosivo. Los discos más lentos saturados durante esas ráfagas, y el cronogramador cayó detrás. Los tiempos de espera alcanzaron el pico a las 09:54, cuando los trabajos de la clase de recursos media Gen 2 esperaban hasta 30 minutos. A las 09:55, los ingenieros aplicaron una solución que establece los discos rápidos correctamente. A las 10:11, el programador comenzó a colocar trabajos más rápido, lo que confirmó que los servidores podían mantenerse al día con nuevos trabajos. Los tiempos de espera para el Gen 2 cayeron a 13 minutos a las 10:14, 7 minutos a las 10:17, y 1 minuto 30 segundos a las 10:20. Movimos la página de estado a monitorizar a las 10:24 y resolvimos el incidente a las 10:45. A las 11:20, el segundo grupo Gen 2 comenzó a funcionar. ### ** October 7, 13:27 to 14:06: Elevated wait times for machine jobs** Declaramos un incidente a las 13:27 después de ver los tiempos elevados de cola y espera. Pusimos en la página de estado a las 13:31. A las 13:31, los ingenieros vieron que estábamos luchando para adquirir máquinas virtuales para trabajos de máquina, y que el número de trabajos que esperaban para empezar era alto principalmente para trabajos de máquina. A las 13:34, los tiempos de espera fueron elevados a través de los ejecutores. A las 13:48, los tiempos de espera comenzaron a recuperarse mientras más máquinas estaban disponibles, y resolvimos el incidente a las 14:06. ### ** October 7, 14:24 to 15:21: Job failures and workflow delays** Poco después del incidente anterior fue marcado como resuelto, declaramos un nuevo incidente a las 14:24 debido a una fuerte caída en el número de puestos de trabajo presentados a nuestros sistemas de ejecución. A las 14:26, los ingenieros vieron que las cápsulas del servicio de configuración de trabajo estaban descansando. Pods that restart leave fewer copies of the service to answer requests, and jobs that could not retrieve their settings after repeated attempts failed with an infrastructure error. Los flujos de trabajo que ya estaban funcionando esperaban actualizaciones de trabajos que no habían comenzado. A las 14:35, los ingenieros aumentaron la cantidad de memoria disponible a las vainas y aumentaron el número de vainas, lo que dio al servicio más copias para compartir la carga. También aumentamos la cantidad de memoria disponible Las presentaciones de Job comenzaron a recuperarse, y el número de mensajes que fluyen a través de nuestro sistema de flujo de trabajo volvió a niveles normales. A las 14:44, trasladamos la página de estado al monitoreo. Los Pods en el servicio de configuración de trabajo alcanzaron sus límites de memoria y reiniciaron. Aumentamos las asignaciones de memoria y los recuentos de pod, y el servicio recuperado. A las 15:13, aumentamos el número de instancias en nuestros grupos de Docker Gen 2 para que podamos trabajar a través de la acumulación de trabajos de espera rápidamente. Resolvimos el incidente a las 15:21. ### ** October 7, 18:49 to 20:05: Elevated wait times for Docker Gen 2 jobs** Declaramos un nuevo incidente a las 18:49 después de Docker Gen 2 tiempos de espera. A las 18:51, los ingenieros confirmaron que una escasez de instancias disponibles nos impidió adquirir suficiente de ellos, lo que aumentó los tiempos de espera. Los tiempos de espera difieren del tamaño de la clase de recursos. A las 19:52, los tiempos de espera promedio eran inferiores a una hora antes, ya que se disponía de más capacidad, aunque prosiguieron breves picos, y trasladamos la página de estado a monitorizar. Resolvimos el incidente a las 20.05. ### ** October 8: Linux machine and remote Docker jobs wait up to 50 minutes** Declaramos un incidente a las 12:48 después de ver un gran número de trabajos esperando para empezar y largos tiempos de espera para los trabajos de máquina y Docker remoto. A las 12:49, los ingenieros vieron que nuestro proveedor de nube no podía suministrar suficientes casos. Los retrasos continuaron subiendo mientras investigamos. A las 13:13 comenzamos a examinar la lógica que elige un tipo de instancia o región diferente cuando nuestra primera opción no está disponible. A las 13:24, sospechábamos que un defecto en esa lógica nos impedía utilizar otros tipos de instancia en nuestra región primaria, por lo que desactivamos nuestra región de retroceso y confirmamos la causa del defecto. Los ingenieros comenzaron a trabajar en una solución y la desplegaron a las 14:49. El servicio comenzó a solicitar otros tipos de instancia y comenzó máquinas en gran número. A las 14:58, la cola de trabajo esperando una máquina cayó constantemente. Los tiempos promedios de espera en las clases de recursos continuaron bajando a la hora siguiente mientras trabajamos a través del atraso de los trabajos de espera. A las 16:00, la cola de trabajo esperando una máquina limpiada y el número de trabajos de espera volvieron a la normalidad. Movimos la página de estado a monitorizar a las 16:09 y resolvimos el incidente a las 16:35. ## **Future Prevention and Process Improvement** Estamos tomando las siguientes medidas para fortalecer la resiliencia de los tiempos de inicio de trabajo, incluyendo la diversificación de la oferta, la lógica de retroceso y la detección anterior. **Estamos expandiendo nuestras regiones de computación.** En los incidentes del 7 y 8 de octubre, nuestro proveedor de nube no pudo suministrar suficientes casos en las regiones que usamos. Estamos agregando nuevas regiones a nuestra lógica de retroceso para manejar picos de demanda que superan nuestras regiones preferidas. **Estamos fijando la lógica que elige un tipo de instancia diferente.** El 8 de octubre, un defecto impidió que el servicio de suministro de máquinas utilizara otros tipos de instancia en la misma región. Hemos implementado una solución durante el incidente y ahora estamos revisando y refactorizando esta lógica en su conjunto, con pruebas, para que una escasez de un tipo de instancia mueva el trabajo a otro. **Estamos ampliando los tipos de instancia que ofrecemos y asegurando capacidad adicional.** Estamos trabajando con nuestro proveedor de cloud para reservar capacidad adicional en nuestras regiones existentes, y estamos agregando tipos de instancias que pueden funcionar. La demanda industrial de computación de alto rendimiento está creciendo. Estamos diversificando dónde y cómo generamos capacidad para que nuestros clientes estén aislados de la variación de la oferta. **Añadimos un segundo grupo de Docker Gen 2 para que las ráfagas de tráfico se distribuyan en dos grupos.** También estamos agregando alertas sobre la saturación del disco servidor de programación y sobre lo rápido que el programador coloca empleos, y una alerta que dispara cuando un servidor comienza sin sus discos rápidos en uso. Hicimos que el script de configuración de disco falla con un error, y restauramos el envío de registros de estos servidores para que un problema similar sea visible antes. La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver estos incidentes. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de octubre de 2026 a las 14:27 UTCinvestigating

   Estamos investigando un aumento de fallas de infra para trabajos de clientes.

2. 7 de octubre de 2026 a las 14:44 UTCmonitoring

   Estamos viendo señales de recuperación. Los tiempos de espera Docker Gen2 son ligeramente elevados y estamos monitoreando.

3. 7 de octubre de 2026 a las 15:21 UTCresolved

   Este incidente ha sido resuelto.

4. 8 de octubre de 2026 a las 17:55 UTCpostmortem

   ## **Summary** Entre el 1 de octubre y el 8 de octubre de 2026, los clientes de CircleCI experimentaron cinco incidentes separados en los que los trabajos esperaban más tiempo de lo normal para empezar, o no comenzaron. Tres de los incidentes fueron impulsados por la disponibilidad de casos limitados de nuestro proveedor de nube. Uno fue causado por un problema de configuración en nuestra infraestructura de programación, y uno por límites de memoria en un servicio interno, que planteamos durante el incidente. * **Octubre 1, 07:57 a 10:24 UTC:** Docker Gen 2 trabajos esperaron hasta 30 minutos para empezar. Un problema de configuración impidió que los servidores de programación Gen 2 usaran sus discos locales de alto rendimiento. Durante un estallido en el tráfico, los discos de retroceso saturados y la colocación de trabajo se ralentizó. * ** 7 de octubre, 13:27 a 14:06 UTC:** Trabajos de máquina esperó más de lo normal porque no podíamos adquirir suficientes máquinas virtuales de nuestro proveedor de nube. * ** 7 de octubre de 14:24 a 15:21 UTC:** Algunos empleos fallaron con un error de infraestructura, y los flujos de trabajo se retrasaron. El servicio que da a cada trabajo su configuración al inicio se agotó de la memoria y se reinicia. * ** 7 de octubre de 18:49 a 20:05 UTC:** Trabajos Docker Gen 2 esperó más de lo normal porque no podíamos adquirir suficientes instancias de nuestro proveedor de nube. * 8 de octubre, 12:48 a 16:00 UTC:** Trabajos de máquinas Linux y empleos remotos Docker esperaron hasta 50 minutos para empezar. Nuestro proveedor de nube no tenía suficiente del tipo de instancia que solicitamos, y un defecto en la lógica que elige un tipo de instancia diferente nos impidió utilizar alternativas. Los trabajos que esperaron durante estos incidentes se retrasaron, no se perdieron. Los clientes cuyos empleos fallaron con un error de infraestructura durante el incidente del 7 de octubre de 14:24 a 15:21 UTC pueden volver a ejecutarlos. Las páginas de estado originales se pueden encontrar a continuación: * [October 1 - Delays starting Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 de octubre - Retraso en la puesta en marcha de las tareas de empleo de la máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 de octubre - Elevated level of infra fails on customer jobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 de octubre - Mayor tiempo de espera para Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 de octubre - Tiempos de espera elevados para el empleo de la máquina] (https://status.circleci.com/incidents/jn756xtsy4xg) ## **Background** Cada trabajo que funciona en CircleCI necesita compute. De donde viene ese computador depende el ejecutante. Trabajos Docker funcionan en grupos de servidores que programan trabajo en una flota de instancias. El programador es el software en esos servidores que decide qué instancia ejecuta cada trabajo. Los trabajos de Gen 2 Docker corrieron en uno de esos grupos en el momento del incidente del 1 de octubre. Los trabajos de Docker Gen 1 se distribuyen en varios grupos. Trabajos de máquina, incluyendo empleos remotos Docker, conseguir una máquina virtual dedicada. Un trabajo remoto de Docker se maneja como un trabajo de máquina Linux desde sumisión a través de la provisión. Nuestro servicio de suministro de máquinas solicita a cada máquina de nuestro proveedor de nubes en una de las dos regiones que normalmente utilizamos para trabajos de máquina. Cuando el proveedor no puede suministrar el tipo de instancia que solicitamos, el servicio cae: solicita un tipo de instancia diferente, o una región diferente, de una lista que mantenemos. Un trabajo espera hasta que una máquina esté disponible. Cuando cualquier trabajo comienza, pide un servicio de configuración de trabajo para su configuración. Ese servicio funciona como un conjunto de cápsulas, que son pequeñas copias del mismo programa. Si se detienen demasiados vainas, los vainas restantes cargan más, y los trabajos no pueden comenzar hasta que el servicio se recupera. Estos caminos dependen de tres tipos de capacidad: el rendimiento de nuestros sistemas de programación, el suministro de instancias de nuestro proveedor de nube, y la memoria y el número de copias de los servicios que inician trabajos. Un déficit en cualquiera de ellos hace que los trabajos esperen o fallen. ## ** What Happened** \(Todas las veces UTC\) #### **Octubre 1: Docker Gen 2 empleos retrasados hasta 30 minutos A las 07:44, la actividad de disco en los servidores que programan empleos Gen 2 Docker aumentó al 90% de la capacidad y se quedaron allí. A las 07:57, el número de empleos Docker que esperan para empezar comenzó a crecer, y los tiempos de espera se elevaron con él. Una alerta automatizada llamó al ingeniero de guardia a las 08:08. Declaramos un incidente a las 08:42. A las 08:43, los ingenieros identificaron latencia de disco alto en los servidores de programación. Primero creían que los discos eran demasiado lentos para la carga, así que prepararon un cambio a un tipo de disco más rápido. A las 09:01, el equipo acordó dos flujos de trabajo: mover los servidores a discos más rápidos, y añadir un segundo grupo Gen 2 para que los trabajos se dividieran en dos grupos. A las 09:41, los ingenieros encontraron la causa raíz. Cada servidor de programación tiene discos rápidos conectados directamente a él, y el programador está destinado a mantener sus datos de trabajo allí. Estos servidores se ejecutan en una imagen del sistema operativo endurecida por seguridad, y en esa imagen los discos rápidos no se estaban utilizando. El programador escribió sus datos para disminuir los discos conectados a la red. El script que establece los discos rápidos falló sin un error, y una brecha en el registro en estos servidores escondió el fallo. El tráfico Gen 2 también se había vuelto cada vez más explosivo. Los discos más lentos saturados durante esas ráfagas, y el cronogramador cayó detrás. Los tiempos de espera alcanzaron el pico a las 09:54, cuando los trabajos de la clase de recursos media Gen 2 esperaban hasta 30 minutos. A las 09:55, los ingenieros aplicaron una solución que establece los discos rápidos correctamente. A las 10:11, el programador comenzó a colocar trabajos más rápido, lo que confirmó que los servidores podían mantenerse al día con nuevos trabajos. Los tiempos de espera para el Gen 2 cayeron a 13 minutos a las 10:14, 7 minutos a las 10:17, y 1 minuto 30 segundos a las 10:20. Movimos la página de estado a monitorizar a las 10:24 y resolvimos el incidente a las 10:45. A las 11:20, el segundo grupo Gen 2 comenzó a funcionar. ### ** October 7, 13:27 to 14:06: Elevated wait times for machine jobs** Declaramos un incidente a las 13:27 después de ver los tiempos elevados de cola y espera. Pusimos en la página de estado a las 13:31. A las 13:31, los ingenieros vieron que estábamos luchando para adquirir máquinas virtuales para trabajos de máquina, y que el número de trabajos que esperaban para empezar era alto principalmente para trabajos de máquina. A las 13:34, los tiempos de espera fueron elevados a través de los ejecutores. A las 13:48, los tiempos de espera comenzaron a recuperarse mientras más máquinas estaban disponibles, y resolvimos el incidente a las 14:06. ### ** October 7, 14:24 to 15:21: Job failures and workflow delays** Poco después del incidente anterior fue marcado como resuelto, declaramos un nuevo incidente a las 14:24 debido a una fuerte caída en el número de puestos de trabajo presentados a nuestros sistemas de ejecución. A las 14:26, los ingenieros vieron que las cápsulas del servicio de configuración de trabajo estaban descansando. Pods that restart leave fewer copies of the service to answer requests, and jobs that could not retrieve their settings after repeated attempts failed with an infrastructure error. Los flujos de trabajo que ya estaban funcionando esperaban actualizaciones de trabajos que no habían comenzado. A las 14:35, los ingenieros aumentaron la cantidad de memoria disponible a las vainas y aumentaron el número de vainas, lo que dio al servicio más copias para compartir la carga. También aumentamos la cantidad de memoria disponible Las presentaciones de Job comenzaron a recuperarse, y el número de mensajes que fluyen a través de nuestro sistema de flujo de trabajo volvió a niveles normales. A las 14:44, trasladamos la página de estado al monitoreo. Los Pods en el servicio de configuración de trabajo alcanzaron sus límites de memoria y reiniciaron. Aumentamos las asignaciones de memoria y los recuentos de pod, y el servicio recuperado. A las 15:13, aumentamos el número de instancias en nuestros grupos de Docker Gen 2 para que podamos trabajar a través de la acumulación de trabajos de espera rápidamente. Resolvimos el incidente a las 15:21. ### ** October 7, 18:49 to 20:05: Elevated wait times for Docker Gen 2 jobs** Declaramos un nuevo incidente a las 18:49 después de Docker Gen 2 tiempos de espera. A las 18:51, los ingenieros confirmaron que una escasez de instancias disponibles nos impidió adquirir suficiente de ellos, lo que aumentó los tiempos de espera. Los tiempos de espera difieren del tamaño de la clase de recursos. A las 19:52, los tiempos de espera promedio eran inferiores a una hora antes, ya que se disponía de más capacidad, aunque prosiguieron breves picos, y trasladamos la página de estado a monitorizar. Resolvimos el incidente a las 20.05. ### ** October 8: Linux machine and remote Docker jobs wait up to 50 minutes** Declaramos un incidente a las 12:48 después de ver un gran número de trabajos esperando para empezar y largos tiempos de espera para los trabajos de máquina y Docker remoto. A las 12:49, los ingenieros vieron que nuestro proveedor de nube no podía suministrar suficientes casos. Los retrasos continuaron subiendo mientras investigamos. A las 13:13 comenzamos a examinar la lógica que elige un tipo de instancia o región diferente cuando nuestra primera opción no está disponible. A las 13:24, sospechábamos que un defecto en esa lógica nos impedía utilizar otros tipos de instancia en nuestra región primaria, por lo que desactivamos nuestra región de retroceso y confirmamos la causa del defecto. Los ingenieros comenzaron a trabajar en una solución y la desplegaron a las 14:49. El servicio comenzó a solicitar otros tipos de instancia y comenzó máquinas en gran número. A las 14:58, la cola de trabajo esperando una máquina cayó constantemente. Los tiempos promedios de espera en las clases de recursos continuaron bajando a la hora siguiente mientras trabajamos a través del atraso de los trabajos de espera. A las 16:00, la cola de trabajo esperando una máquina limpiada y el número de trabajos de espera volvieron a la normalidad. Movimos la página de estado a monitorizar a las 16:09 y resolvimos el incidente a las 16:35. ## **Future Prevention and Process Improvement** Estamos tomando las siguientes medidas para fortalecer la resiliencia de los tiempos de inicio de trabajo, incluyendo la diversificación de la oferta, la lógica de retroceso y la detección anterior. **Estamos expandiendo nuestras regiones de computación.** En los incidentes del 7 y 8 de octubre, nuestro proveedor de nube no pudo suministrar suficientes casos en las regiones que usamos. Estamos agregando nuevas regiones a nuestra lógica de retroceso para manejar picos de demanda que superan nuestras regiones preferidas. **Estamos fijando la lógica que elige un tipo de instancia diferente.** El 8 de octubre, un defecto impidió que el servicio de suministro de máquinas utilizara otros tipos de instancia en la misma región. Hemos implementado una solución durante el incidente y ahora estamos revisando y refactorizando esta lógica en su conjunto, con pruebas, para que una escasez de un tipo de instancia mueva el trabajo a otro. **Estamos ampliando los tipos de instancia que ofrecemos y asegurando capacidad adicional.** Estamos trabajando con nuestro proveedor de cloud para reservar capacidad adicional en nuestras regiones existentes, y estamos agregando tipos de instancias que pueden funcionar. La demanda industrial de computación de alto rendimiento está creciendo. Estamos diversificando dónde y cómo generamos capacidad para que nuestros clientes estén aislados de la variación de la oferta. **Añadimos un segundo grupo de Docker Gen 2 para que las ráfagas de tráfico se distribuyan en dos grupos.** También estamos agregando alertas sobre la saturación del disco servidor de programación y sobre lo rápido que el programador coloca empleos, y una alerta que dispara cuando un servidor comienza sin sus discos rápidos en uso. Hicimos que el script de configuración de disco falla con un error, y restauramos el envío de registros de estos servidores para que un problema similar sea visible antes. La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver estos incidentes. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de octubre de 2026 a las 13:40 UTCinvestigating

   Los clientes pueden estar experimentando tiempos elevados de espera para Machine Job Tasks, estamos investigando la causa raíz y actualizaremos cuando sabemos más.

2. 7 de octubre de 2026 a las 13:52 UTCmonitoring

   Estamos viendo señales de recuperación y monitoreo de la situación.

3. 7 de octubre de 2026 a las 14:06 UTCresolved

   El incidente se ha resuelto. Gracias por su paciencia

4. 8 de octubre de 2026 a las 17:55 UTCpostmortem

   ## **Summary** Entre el 1 de octubre y el 8 de octubre de 2026, los clientes de CircleCI experimentaron cinco incidentes separados en los que los trabajos esperaban más tiempo de lo normal para empezar, o no comenzaron. Tres de los incidentes fueron impulsados por la disponibilidad de casos limitados de nuestro proveedor de nube. Uno fue causado por un problema de configuración en nuestra infraestructura de programación, y uno por límites de memoria en un servicio interno, que planteamos durante el incidente. * **Octubre 1, 07:57 a 10:24 UTC:** Docker Gen 2 trabajos esperaron hasta 30 minutos para empezar. Un problema de configuración impidió que los servidores de programación Gen 2 usaran sus discos locales de alto rendimiento. Durante un estallido en el tráfico, los discos de retroceso saturados y la colocación de trabajo se ralentizó. * ** 7 de octubre, 13:27 a 14:06 UTC:** Trabajos de máquina esperó más de lo normal porque no podíamos adquirir suficientes máquinas virtuales de nuestro proveedor de nube. * ** 7 de octubre de 14:24 a 15:21 UTC:** Algunos empleos fallaron con un error de infraestructura, y los flujos de trabajo se retrasaron. El servicio que da a cada trabajo su configuración al inicio se agotó de la memoria y se reinicia. * ** 7 de octubre de 18:49 a 20:05 UTC:** Trabajos Docker Gen 2 esperó más de lo normal porque no podíamos adquirir suficientes instancias de nuestro proveedor de nube. * 8 de octubre, 12:48 a 16:00 UTC:** Trabajos de máquinas Linux y empleos remotos Docker esperaron hasta 50 minutos para empezar. Nuestro proveedor de nube no tenía suficiente del tipo de instancia que solicitamos, y un defecto en la lógica que elige un tipo de instancia diferente nos impidió utilizar alternativas. Los trabajos que esperaron durante estos incidentes se retrasaron, no se perdieron. Los clientes cuyos empleos fallaron con un error de infraestructura durante el incidente del 7 de octubre de 14:24 a 15:21 UTC pueden volver a ejecutarlos. Las páginas de estado originales se pueden encontrar a continuación: * [October 1 - Delays starting Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 de octubre - Retraso en la puesta en marcha de las tareas de empleo de la máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 de octubre - Elevated level of infra fails on customer jobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 de octubre - Mayor tiempo de espera para Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 de octubre - Tiempos de espera elevados para el empleo de la máquina] (https://status.circleci.com/incidents/jn756xtsy4xg) ## **Background** Cada trabajo que funciona en CircleCI necesita compute. De donde viene ese computador depende el ejecutante. Trabajos Docker funcionan en grupos de servidores que programan trabajo en una flota de instancias. El programador es el software en esos servidores que decide qué instancia ejecuta cada trabajo. Los trabajos de Gen 2 Docker corrieron en uno de esos grupos en el momento del incidente del 1 de octubre. Los trabajos de Docker Gen 1 se distribuyen en varios grupos. Trabajos de máquina, incluyendo empleos remotos Docker, conseguir una máquina virtual dedicada. Un trabajo remoto de Docker se maneja como un trabajo de máquina Linux desde sumisión a través de la provisión. Nuestro servicio de suministro de máquinas solicita a cada máquina de nuestro proveedor de nubes en una de las dos regiones que normalmente utilizamos para trabajos de máquina. Cuando el proveedor no puede suministrar el tipo de instancia que solicitamos, el servicio cae: solicita un tipo de instancia diferente, o una región diferente, de una lista que mantenemos. Un trabajo espera hasta que una máquina esté disponible. Cuando cualquier trabajo comienza, pide un servicio de configuración de trabajo para su configuración. Ese servicio funciona como un conjunto de cápsulas, que son pequeñas copias del mismo programa. Si se detienen demasiados vainas, los vainas restantes cargan más, y los trabajos no pueden comenzar hasta que el servicio se recupera. Estos caminos dependen de tres tipos de capacidad: el rendimiento de nuestros sistemas de programación, el suministro de instancias de nuestro proveedor de nube, y la memoria y el número de copias de los servicios que inician trabajos. Un déficit en cualquiera de ellos hace que los trabajos esperen o fallen. ## ** What Happened** \(Todas las veces UTC\) #### **Octubre 1: Docker Gen 2 empleos retrasados hasta 30 minutos A las 07:44, la actividad de disco en los servidores que programan empleos Gen 2 Docker aumentó al 90% de la capacidad y se quedaron allí. A las 07:57, el número de empleos Docker que esperan para empezar comenzó a crecer, y los tiempos de espera se elevaron con él. Una alerta automatizada llamó al ingeniero de guardia a las 08:08. Declaramos un incidente a las 08:42. A las 08:43, los ingenieros identificaron latencia de disco alto en los servidores de programación. Primero creían que los discos eran demasiado lentos para la carga, así que prepararon un cambio a un tipo de disco más rápido. A las 09:01, el equipo acordó dos flujos de trabajo: mover los servidores a discos más rápidos, y añadir un segundo grupo Gen 2 para que los trabajos se dividieran en dos grupos. A las 09:41, los ingenieros encontraron la causa raíz. Cada servidor de programación tiene discos rápidos conectados directamente a él, y el programador está destinado a mantener sus datos de trabajo allí. Estos servidores se ejecutan en una imagen del sistema operativo endurecida por seguridad, y en esa imagen los discos rápidos no se estaban utilizando. El programador escribió sus datos para disminuir los discos conectados a la red. El script que establece los discos rápidos falló sin un error, y una brecha en el registro en estos servidores escondió el fallo. El tráfico Gen 2 también se había vuelto cada vez más explosivo. Los discos más lentos saturados durante esas ráfagas, y el cronogramador cayó detrás. Los tiempos de espera alcanzaron el pico a las 09:54, cuando los trabajos de la clase de recursos media Gen 2 esperaban hasta 30 minutos. A las 09:55, los ingenieros aplicaron una solución que establece los discos rápidos correctamente. A las 10:11, el programador comenzó a colocar trabajos más rápido, lo que confirmó que los servidores podían mantenerse al día con nuevos trabajos. Los tiempos de espera para el Gen 2 cayeron a 13 minutos a las 10:14, 7 minutos a las 10:17, y 1 minuto 30 segundos a las 10:20. Movimos la página de estado a monitorizar a las 10:24 y resolvimos el incidente a las 10:45. A las 11:20, el segundo grupo Gen 2 comenzó a funcionar. ### ** October 7, 13:27 to 14:06: Elevated wait times for machine jobs** Declaramos un incidente a las 13:27 después de ver los tiempos elevados de cola y espera. Pusimos en la página de estado a las 13:31. A las 13:31, los ingenieros vieron que estábamos luchando para adquirir máquinas virtuales para trabajos de máquina, y que el número de trabajos que esperaban para empezar era alto principalmente para trabajos de máquina. A las 13:34, los tiempos de espera fueron elevados a través de los ejecutores. A las 13:48, los tiempos de espera comenzaron a recuperarse mientras más máquinas estaban disponibles, y resolvimos el incidente a las 14:06. ### ** October 7, 14:24 to 15:21: Job failures and workflow delays** Poco después del incidente anterior fue marcado como resuelto, declaramos un nuevo incidente a las 14:24 debido a una fuerte caída en el número de puestos de trabajo presentados a nuestros sistemas de ejecución. A las 14:26, los ingenieros vieron que las cápsulas del servicio de configuración de trabajo estaban descansando. Pods that restart leave fewer copies of the service to answer requests, and jobs that could not retrieve their settings after repeated attempts failed with an infrastructure error. Los flujos de trabajo que ya estaban funcionando esperaban actualizaciones de trabajos que no habían comenzado. A las 14:35, los ingenieros aumentaron la cantidad de memoria disponible a las vainas y aumentaron el número de vainas, lo que dio al servicio más copias para compartir la carga. También aumentamos la cantidad de memoria disponible Las presentaciones de Job comenzaron a recuperarse, y el número de mensajes que fluyen a través de nuestro sistema de flujo de trabajo volvió a niveles normales. A las 14:44, trasladamos la página de estado al monitoreo. Los Pods en el servicio de configuración de trabajo alcanzaron sus límites de memoria y reiniciaron. Aumentamos las asignaciones de memoria y los recuentos de pod, y el servicio recuperado. A las 15:13, aumentamos el número de instancias en nuestros grupos de Docker Gen 2 para que podamos trabajar a través de la acumulación de trabajos de espera rápidamente. Resolvimos el incidente a las 15:21. ### ** October 7, 18:49 to 20:05: Elevated wait times for Docker Gen 2 jobs** Declaramos un nuevo incidente a las 18:49 después de Docker Gen 2 tiempos de espera. A las 18:51, los ingenieros confirmaron que una escasez de instancias disponibles nos impidió adquirir suficiente de ellos, lo que aumentó los tiempos de espera. Los tiempos de espera difieren del tamaño de la clase de recursos. A las 19:52, los tiempos de espera promedio eran inferiores a una hora antes, ya que se disponía de más capacidad, aunque prosiguieron breves picos, y trasladamos la página de estado a monitorizar. Resolvimos el incidente a las 20.05. ### ** October 8: Linux machine and remote Docker jobs wait up to 50 minutes** Declaramos un incidente a las 12:48 después de ver un gran número de trabajos esperando para empezar y largos tiempos de espera para los trabajos de máquina y Docker remoto. A las 12:49, los ingenieros vieron que nuestro proveedor de nube no podía suministrar suficientes casos. Los retrasos continuaron subiendo mientras investigamos. A las 13:13 comenzamos a examinar la lógica que elige un tipo de instancia o región diferente cuando nuestra primera opción no está disponible. A las 13:24, sospechábamos que un defecto en esa lógica nos impedía utilizar otros tipos de instancia en nuestra región primaria, por lo que desactivamos nuestra región de retroceso y confirmamos la causa del defecto. Los ingenieros comenzaron a trabajar en una solución y la desplegaron a las 14:49. El servicio comenzó a solicitar otros tipos de instancia y comenzó máquinas en gran número. A las 14:58, la cola de trabajo esperando una máquina cayó constantemente. Los tiempos promedios de espera en las clases de recursos continuaron bajando a la hora siguiente mientras trabajamos a través del atraso de los trabajos de espera. A las 16:00, la cola de trabajo esperando una máquina limpiada y el número de trabajos de espera volvieron a la normalidad. Movimos la página de estado a monitorizar a las 16:09 y resolvimos el incidente a las 16:35. ## **Future Prevention and Process Improvement** Estamos tomando las siguientes medidas para fortalecer la resiliencia de los tiempos de inicio de trabajo, incluyendo la diversificación de la oferta, la lógica de retroceso y la detección anterior. **Estamos expandiendo nuestras regiones de computación.** En los incidentes del 7 y 8 de octubre, nuestro proveedor de nube no pudo suministrar suficientes casos en las regiones que usamos. Estamos agregando nuevas regiones a nuestra lógica de retroceso para manejar picos de demanda que superan nuestras regiones preferidas. **Estamos fijando la lógica que elige un tipo de instancia diferente.** El 8 de octubre, un defecto impidió que el servicio de suministro de máquinas utilizara otros tipos de instancia en la misma región. Hemos implementado una solución durante el incidente y ahora estamos revisando y refactorizando esta lógica en su conjunto, con pruebas, para que una escasez de un tipo de instancia mueva el trabajo a otro. **Estamos ampliando los tipos de instancia que ofrecemos y asegurando capacidad adicional.** Estamos trabajando con nuestro proveedor de cloud para reservar capacidad adicional en nuestras regiones existentes, y estamos agregando tipos de instancias que pueden funcionar. La demanda industrial de computación de alto rendimiento está creciendo. Estamos diversificando dónde y cómo generamos capacidad para que nuestros clientes estén aislados de la variación de la oferta. **Añadimos un segundo grupo de Docker Gen 2 para que las ráfagas de tráfico se distribuyan en dos grupos.** También estamos agregando alertas sobre la saturación del disco servidor de programación y sobre lo rápido que el programador coloca empleos, y una alerta que dispara cuando un servidor comienza sin sus discos rápidos en uso. Hicimos que el script de configuración de disco falla con un error, y restauramos el envío de registros de estos servidores para que un problema similar sea visible antes. La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver estos incidentes. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 6 de octubre de 2026 a las 16:00 UTCinvestigating

   ¿Qué ha afectado? Los clientes que utilizan tuberías y flujos de trabajo de CircleCI, incluyendo la visualización de datos de la UI, notificaciones de salida y sorteos web. ¿Qué puedes esperar? Se están generando retrasos en las tuberías y se inician los flujos de trabajo y los empleos. Los datos de trabajo, flujo de trabajo y oleoductos pueden tardar hasta 15 minutos en aparecer en la UI. Las notificaciones de salida y los sorteos se retrasan hasta 1 minuto. Siguiente actualización Proporcionaremos otra actualización dentro de 30 minutos o ya que tenemos más información para compartir.

2. 6 de octubre de 2026 a las 16:10 UTCinvestigating

   Desde 15:47 UTC, los clientes también pueden ver trabajos fallidos, además de los retrasos reportados anteriormente. Nuestros ingenieros continúan investigando y mitigando el problema.

3. 6 de octubre de 2026 a las 16:31 UTCidentified

   A partir de las 16:02 UTC, los oleoductos están fallando por completo, por lo que no hay nuevos flujos de trabajo ni puestos de trabajo en este punto. This is in addition to the delays and failed jobs reported earlier. Nuestros ingenieros siguen trabajando para mitigar el problema, y compartiremos más información tan pronto como lo tengamos.

4. 6 de octubre de 2026 a las 16:42 UTCidentified

   A partir de las 16:39 UTC, estamos empezando a ver la recuperación de nuevos oleoductos y flujos de trabajo que se presentan, y los trabajos están empezando a funcionar de nuevo. Nuestros ingenieros continúan trabajando en la recuperación y compartirán más información tan pronto como la tengamos.

5. 6 de octubre de 2026 a las 17:21 UTCidentified

   Mientras Pipelines, flujos de trabajo y puestos de trabajo están funcionando de nuevo, los clientes pueden seguir viendo demoras más largas de lo habitual entre los empleos en un flujo de trabajo, y las notificaciones de salida se retrasan aproximadamente 1 minuto. Las notificaciones y actualizaciones de estado de su sistema de control de versiones están empezando a salir de nuevo. Nuestros ingenieros continúan trabajando para una recuperación completa.

6. 6 de octubre de 2026 a las 18:04 UTCidentified

   Los clientes siguen experimentando retrasos más largos de lo habitual entre empleos en un flujo de trabajo, así como retrasos en las notificaciones de salida. Le agradecemos su paciencia mientras nuestros ingenieros continúan investigando y trabajando para mitigar el problema. Compartiremos otra actualización dentro de los próximos 30 minutos, o antes si hay más información disponible.

7. 6 de octubre de 2026 a las 18:55 UTCidentified

   Los clientes siguen experimentando retrasos más largos de lo habitual antes de que comiencen los flujos de trabajo y los empleos, en algunos casos hasta aproximadamente 30 minutos. Esto se mejora desde antes en el incidente, pero siguen existiendo demoras. Las demoras en las notificaciones externas han mejorado. Le agradecemos su paciencia mientras nuestros ingenieros continúan trabajando para restaurar los tiempos normales de inicio de trabajo. Compartiremos otra actualización dentro de los próximos 30 minutos, o antes si hay más información disponible.

8. 6 de octubre de 2026 a las 19:16 UTCidentified

   Los clientes siguen experimentando retrasos. La mayoría comienza en aproximadamente 20 minutos, mejorada a partir de aproximadamente 40 minutos antes del incidente. Un número muy pequeño de flujos de trabajo puede haber esperado más de 1 hora. Nuestros ingenieros han hecho cambios que han mejorado la estabilidad del servicio, y el retraso restante se debe a un atraso de trabajo que se construyó durante el incidente. El atraso está disminuyendo, y estamos enfocados en limpiarlo más rápido. Compartiremos más información a medida que continúe el progreso. Le agradecemos su paciencia mientras nuestros ingenieros trabajan a través del atraso. Compartiremos otra actualización dentro de los próximos 30 minutos, o antes si hay más información disponible.

9. 6 de octubre de 2026 a las 19:51 UTCidentified

   Siguen disminuyendo los retrasos en los flujos de trabajo y los puestos de trabajo. La mayoría comienza en aproximadamente 10 minutos, mejorada a partir de aproximadamente 40 minutos antes del incidente. Un número muy pequeño de flujos de trabajo puede haber esperado más de 1 hora. Si su trabajo no comenzó, por favor vuelva a ejecutar el trabajo. Las demoras en las notificaciones externas han mejorado. El retraso restante se debe a un atraso de trabajo que se construyó durante el incidente, y que el atraso se ha reducido en más de la mitad. Esperamos que el atraso sea eliminado en aproximadamente 15 minutos. Compartiremos otra actualización una vez que se haya aclarado, o en los próximos 30 minutos a más tardar.

10. 6 de octubre de 2026 a las 20:13 UTCidentified

    Se ha aclarado el atraso de los trabajos retrasados y los flujos de trabajo están empezando de nuevo sin demoras en las notificaciones. Sin embargo, los clientes que utilizan empleos de Docker y Linux en varias clases de recursos, incluyendo medio, grande y 2xlarge gen2, pueden ahora ver trabajos esperando en la cola por unos minutos antes de empezar. Nuestros ingenieros siguen trabajando para mitigar este problema. Si su trabajo no comenzó, por favor vuelva a ejecutar el trabajo. Le agradecemos su paciencia mientras nuestros ingenieros trabajan en esto. Compartiremos otra actualización dentro de los próximos 30 minutos, o antes si hay más información disponible.

11. 6 de octubre de 2026 a las 20:31 UTCmonitoring

    Los flujos de trabajo y los empleos comienzan normalmente, y los tiempos de espera para Docker y Linux han vuelto a la normalidad. Nuestros ingenieros siguen vigilando este asunto. Si su trabajo no comenzó, por favor vuelva a ejecutar el trabajo. Le agradecemos su paciencia mientras nuestros ingenieros trabajan en esto. Compartiremos otra actualización dentro de los próximos 30 minutos, o antes si hay más información disponible.

12. 6 de octubre de 2026 a las 21:18 UTCresolved

    Entre aproximadamente 15:30 UTC y 20:30 UTC el 6 de octubre de 2026, los clientes experimentaron retrasos y fallas que afectaron a tuberías, flujos de trabajo y empleo. De aproximadamente 16:02 UTC a 16:39 UTC, los oleoductos estaban fallando y no podían iniciarse nuevos flujos de trabajo o empleos. Después de la reanudación del servicio, los flujos de trabajo y los empleos siguieron empezando con retrasos hasta aproximadamente las 20:00 UTC. Los tiempos de inicio promediaron hasta aproximadamente 40 minutos en su pico, y un número muy pequeño de flujos de trabajo esperó más de 1 hora. También se retrasaron las notificaciones y los sorteos de salida hasta aproximadamente las 19:00 UTC, por lo general en aproximadamente un minuto. Como el atraso del trabajo retrasado se despejó, el consiguiente aumento de la demanda puso presión sobre nuestra capacidad de ejecución, causando nuevos retrasos para los empleos de Docker y Linux. De aproximadamente 19:45 UTC a 20:30 UTC, estos trabajos esperaron en la cola más larga de lo habitual antes de comenzar. En el pico, alrededor de 20:05 UTC, espera alcanzar aproximadamente 8 minutos para 2xlarge gen2, 6 minutos para xlarge gen2, y menos de 5 minutos para algunas otras clases de recursos. La cuestión se ha resuelto y toda la funcionalidad afectada ha vuelto a la normalidad. Los clientes cuyos empleos fallaron durante esta ventana pueden regir trabajos afectados. Le agradecemos su paciencia mientras nuestro equipo trabajó en implementar una solución.

13. 7 de octubre de 2026 a las 22:08 UTCpostmortem

    ## Summary El 6 de octubre de 2026, de 15:30 a 20:30 UTC, los clientes de CircleCI experimentaron retrasos creando tuberías y iniciando flujos de trabajo y empleo. De 15:48 a 16:38 UTC, no se iniciaron flujos de trabajo ni empleos, y fallaron los oleoductos de 16:02 UTC. Las demoras más cortas e intermitentes comenzaron antes, a las 13:30 UTC. También se retrasaron los datos de la IU CircleCI, las notificaciones y las actualizaciones de estado de los proveedores de control de versiones. El incidente comenzó en la base de datos detrás de nuestro servicio de orquestación de flujo de trabajo, que coordina cada tubería, flujo de trabajo y trabajo en CircleCI. El mantenimiento de rutina en las tablas más grandes de la base de datos escribió registros de transacciones más rápido de lo que la base de datos podría archivarlos, y los registros llenaron el volumen de almacenamiento reservado para ellos. Para evitar que la base de datos se convierta en sólo lectura, nuestros ingenieros trasladaron los registros al principal volumen de almacenamiento de la base de datos. Ese movimiento tomó la base de datos fuera de línea durante 50 minutos. Cuando la base de datos volvió, procesó el trabajo a la mitad de su tasa normal hasta que nuestros ingenieros cambiaron una configuración de base a 18:19 UTC. Luego trabajamos a través del atraso, y los tiempos de inicio de trabajo volvieron a la normalidad para las 20:30 UTC. Los clientes cuyo trabajo falló durante esta ventana pueden reeducarlos. La página de estado original puede encontrarse [aquí](https://status.circleci.com/incidents/z4hbq8h49j8c). ## Background Cuando activas un oleoducto, CircleCI lo entrega a un servicio de orquestación de flujo de trabajo. Ese servicio rastrea el estado de cada flujo de trabajo y trabajo, decide cuándo cada trabajo está listo para funcionar, y pasa trabajos listos a nuestra flota de ejecución. También impulsa los datos de trabajo que ve en la UI y las notificaciones y los estados de compromiso que envíamos cuando termina el trabajo. El servicio de orquestación almacena su estado en una base de datos. La base de datos escribe cada cambio a un registro de transacciones antes de aplicarlo, y mantiene esos registros en un volumen de almacenamiento dedicado. archiva los registros continuamente para que pueda reutilizar ese espacio. Si el archivo cae y el volumen se llena, la base de datos deja de aceptar escritos, y ningún trabajo nuevo puede avanzar. La base de datos también ejecuta un proceso de mantenimiento periódico \(autovacuums\) en cada tabla para mantener sus registros internos válidos con el tiempo. En una tabla muy grande, este proceso lee cada página de la tabla y escribe un gran volumen de registros de transacciones. ## What Happened \(Todas las veces UTC\) A partir de las 10:02 del 6 de octubre, nuestro monitoreo planteó alertas cortas sobre errores en el servicio de orquestación. Cada alerta se despejó por sí sola en unos 15 minutos. Nuestros ingenieros habían visto alertas breves similares antes, y el sistema no mostraba otros signos de estrés, por lo que siguieron el corredor cada vez, y cada alerta se despejó por su propio camino y también comenzó a trabajar para hacer las alertas menos sensibles. Alrededor de las 12:40, junto con la carga de trabajo regular que genera sus propios registros de transacciones, el proceso de mantenimiento en varias de las tablas más grandes de la base de datos comenzó a escribir registros de transacciones adicionales más rápido de lo que la base de datos podría archivarlos, y el volumen de registro comenzó a llenar. A las 13:30, el servicio de orquestación comenzó a disminuir. A lo largo de 15:30, algunos oleoductos y empleos tardaron más en empezar, en breves estallidos. A las 13:35, nuestro monitoreo alertó de nuevo, esta vez junto con alertas relacionadas de varios otros servicios. Los ingenieros de infraestructura siguieron los registros de alerta, aclarando algunas de las alertas. Las alertas volvieron a las 14:30 y después de investigar más, declaramos un incidente a las 14:54. Deberíamos haber reconocido la combinación de alertas antes, y hemos cubierto cómo estamos arreglando eso abajo. Después de declarar el incidente, nuestros ingenieros rastrearon la desaceleración al proceso de mantenimiento \(anti-wraparound autovacuum\). La base de datos reinicia este proceso automáticamente si se cancela, por lo que nuestros ingenieros cambiaron su configuración para ayudarle a terminar más rápido. A las 15:30, los retrasos eran continuos, y algunos trabajos comenzaron a fracasar. A las 15:43, el volumen del registro de transacciones estaba cerca de lleno. Si se llena, la base de datos dejaría de aceptar los escritos y no podría funcionar ningún trabajo. Nuestros ingenieros decidieron trasladar los registros de transacción al volumen principal de almacenamiento de la base de datos, que tenía mucho espacio libre. El movimiento exigía que la base de datos se fuera de línea, y no podíamos predecir con antelación cuánto tiempo tomaría. El movimiento comenzó a las 15:47. De 15:48 a 16:38, el servicio de orquestación no pudo procesar ninguna obra. Los clientes todavía podrían desencadenar oleoductos, pero no se iniciaron flujos de trabajo ni empleos, y a partir de las 16:02 fallaron los oleoductos recién iniciados. Pusimos en nuestra página de estado a las 15:58 y la criamos a un gran outage a las 16:20. Mientras la base de datos estaba fuera de línea, nuestros ingenieros prepararon una base de datos de reemplazo como un retroceso. La base de datos original volvió primero, así que la mantuvimos en servicio. A las 16:38, la base de datos volvió en línea y el trabajo comenzó a fluir de nuevo. Con los registros de transacción y los datos regulares que ahora comparten el mismo almacenamiento, la base de datos funcionó más lentamente que antes. De 16:38 a 18:19, el servicio de orquestación procesó el trabajo a casi la mitad de su ritmo normal, y los trabajos esperaron diez minutos para comenzar, hasta unos 50 minutos al más largo. Durante ese tiempo, la base de datos tuvo que terminar de archivar su atraso de los registros de transacciones antes de poder trasladarlos a un volumen dedicado. También investigamos e implementamos varios cambios de parámetro de bases de datos para evitar nuevas operaciones de mantenimiento desde maneras de comenzar y preparar para reducir el trabajo que llega al servicio. Junto con la base de datos de reemplazo, también preparamos una pila completa del servicio durante ese tiempo para que podamos pasar a ella a riesgo de pérdida de datos y optamos contra ese movimiento. A las 18:19, nuestros ingenieros cambiaron una base de datos para cortar el tiempo que cada escritura gastaba esperando en almacenamiento. Procesando la velocidad recuperada, y el atraso comenzó a aclararse. Para aclararlo más rápido, añadimos capacidad de base de datos y servidor a los sistemas que entregan empleos a nuestra flota de ejecución. Hacia las 19:55, los nuevos empleos estaban comenzando de nuevo a tiempo. El atraso llegó a nuestra flota de ejecución. De 19:49 a 20:30, algunos empleos de Docker en clases de recursos más grandes esperaron hasta unos 10 minutos para empezar mientras la capacidad se escalaba. Para las 20:30, los tiempos de inicio de trabajo volvieron a la normalidad. Movimos la página de estado a monitorizar a las 20:32 y resolvimos el incidente a las 21:19. Unos 3.500 empleos no comenzaron durante el incidente. Los clientes pueden rehacer estos trabajos. No encontramos ninguna evidencia de que CircleCI haya trabajado más de una vez. Los clientes que reanudan un flujo de trabajo mientras que la carrera original todavía se retrasaba pueden haber visto ambas carreras completas. Los clientes del plan anual pueden trabajar con su equipo de cuenta para revisar el uso. ## Future Prevention and Process Improvement Estamos tomando las siguientes medidas para prevenir una recurrencia y mejorar nuestro tiempo de respuesta: **Estamos agregando alertas sobre las condiciones que causaron este incidente.** Nuestro monitoreo captó la desaceleración, pero no teníamos ninguna alerta sobre lo completo que era el volumen del registro de transacciones o en lo lejos que el archivo había caído detrás. Estamos agregando alertas en ambos, junto con alertas en el mantenimiento de la base de datos que los impulsa, para que podamos actuar antes. También estamos revisando todas nuestras alertas para asegurar que las alertas ruidosas o sensibles no ocultan problemas reales. **Estamos sintonizando cómo el proceso de mantenimiento \(autovacuum\) funciona en nuestra base de datos.** Estamos viendo la frecuencia y la agresividad con la que los autovacuos funcionan en nuestra base de datos. También estamos siguiendo el tamaño de estas tablas con el tiempo para que permanezcan dentro de límites seguros. **Estamos eliminando el cuello de botella de un solo registro de transacciones.** Todos los escritos del servicio de orquestación pasan a través de una base de datos y un registro de transacciones, así que cuando ese registro cayó, cada oleoducto, flujo de trabajo y trabajo se ralentizó con él. Estamos evaluando dos enfoques: dividir el servicio en múltiples instancias de base de datos, cada una con su propio registro de transacciones, y trasladarlo a una base de datos distribuida construida para difundir escritos a través de muchos nodos. Cualquier enfoque limitaría el efecto de un atraso en parte del volumen de trabajo. **Estamos haciendo que nuestros sistemas esperen que el servicio de orquestación se recupere.** Durante el incidente, algunos trabajos fallaron porque nuestros sistemas se rindieron después de volver a intentarlo. Estamos trabajando en cambiar ese comportamiento. **Estamos mejorando nuestras actualizaciones de la página de estado durante largos incidentes.** Los clientes nos dijeron que nuestras actualizaciones tempranas no dieron suficiente detalle. Estamos actualizando nuestra guía para que las actualizaciones incluyan un impacto específico y el tiempo antes. La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver este incidente. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de octubre de 2026 a las 9:06 UTCinvestigating

   Los clientes pueden experimentar retrasos en el inicio de Docker Gen 2 Jobs. Estamos trabajando para aumentar el rendimiento del sistema para acomodar esto.

2. 1 de octubre de 2026 a las 9:47 UTCidentified

   Hemos identificado la causa raíz y estamos trabajando activamente en una solución. Gracias por su paciencia.

3. 1 de octubre de 2026 a las 10:13 UTCidentified

   Se ha lanzado una solución y estamos empezando a observar la recuperación.

4. 1 de octubre de 2026 a las 10:24 UTCmonitoring

   Estamos viendo que los tiempos de cola vuelven a niveles normales, y continúan monitoreando.

5. 1 de octubre de 2026 a las 10:45 UTCresolved

   Este incidente ha sido resuelto.

6. 9 de octubre de 2026 a las 22:36 UTCpostmortem

   ## **Summary** Entre el 1 de octubre y el 8 de octubre de 2026, los clientes de CircleCI experimentaron cinco incidentes separados en los que los trabajos esperaban más tiempo de lo normal para empezar, o no comenzaron. Tres de los incidentes fueron impulsados por la disponibilidad de casos limitados de nuestro proveedor de nube. Uno fue causado por un problema de configuración en nuestra infraestructura de programación, y uno por límites de memoria en un servicio interno, que planteamos durante el incidente. * **Octubre 1, 07:57 a 10:24 UTC:** Docker Gen 2 trabajos esperaron hasta 30 minutos para empezar. Un problema de configuración impidió que los servidores de programación Gen 2 usaran sus discos locales de alto rendimiento. Durante un estallido en el tráfico, los discos de retroceso saturados y la colocación de trabajo se ralentizó. * ** 7 de octubre, 13:27 a 14:06 UTC:** Trabajos de máquina esperó más de lo normal porque no podíamos adquirir suficientes máquinas virtuales de nuestro proveedor de nube. * ** 7 de octubre de 14:24 a 15:21 UTC:** Algunos empleos fallaron con un error de infraestructura, y los flujos de trabajo se retrasaron. El servicio que da a cada trabajo su configuración al inicio se agotó de la memoria y se reinicia. * ** 7 de octubre de 18:49 a 20:05 UTC:** Trabajos Docker Gen 2 esperó más de lo normal porque no podíamos adquirir suficientes instancias de nuestro proveedor de nube. * 8 de octubre, 12:48 a 16:00 UTC:** Trabajos de máquinas Linux y empleos remotos Docker esperaron hasta 50 minutos para empezar. Nuestro proveedor de nube no tenía suficiente del tipo de instancia que solicitamos, y un defecto en la lógica que elige un tipo de instancia diferente nos impidió utilizar alternativas. Los trabajos que esperaron durante estos incidentes se retrasaron, no se perdieron. Los clientes cuyos empleos fallaron con un error de infraestructura durante el incidente del 7 de octubre de 14:24 a 15:21 UTC pueden volver a ejecutarlos. Las páginas de estado originales se pueden encontrar a continuación: * [October 1 - Delays starting Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 de octubre - Retraso en la puesta en marcha de las tareas de empleo de la máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 de octubre - Elevated level of infra fails on customer jobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 de octubre - Mayor tiempo de espera para Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 de octubre - Tiempos de espera elevados para el empleo de la máquina] (https://status.circleci.com/incidents/jn756xtsy4xg) ## **Background** Cada trabajo que funciona en CircleCI necesita compute. De donde viene ese computador depende el ejecutante. Trabajos Docker funcionan en grupos de servidores que programan trabajo en una flota de instancias. El programador es el software en esos servidores que decide qué instancia ejecuta cada trabajo. Los trabajos de Gen 2 Docker corrieron en uno de esos grupos en el momento del incidente del 1 de octubre. Los trabajos de Docker Gen 1 se distribuyen en varios grupos. Trabajos de máquina, incluyendo empleos remotos Docker, conseguir una máquina virtual dedicada. Un trabajo remoto de Docker se maneja como un trabajo de máquina Linux desde sumisión a través de la provisión. Nuestro servicio de suministro de máquinas solicita a cada máquina de nuestro proveedor de nubes en una de las dos regiones que normalmente utilizamos para trabajos de máquina. Cuando el proveedor no puede suministrar el tipo de instancia que solicitamos, el servicio cae: solicita un tipo de instancia diferente, o una región diferente, de una lista que mantenemos. Un trabajo espera hasta que una máquina esté disponible. Cuando cualquier trabajo comienza, pide un servicio de configuración de trabajo para su configuración. Ese servicio funciona como un conjunto de cápsulas, que son pequeñas copias del mismo programa. Si se detienen demasiados vainas, los vainas restantes cargan más, y los trabajos no pueden comenzar hasta que el servicio se recupera. Estos caminos dependen de tres tipos de capacidad: el rendimiento de nuestros sistemas de programación, el suministro de instancias de nuestro proveedor de nube, y la memoria y el número de copias de los servicios que inician trabajos. Un déficit en cualquiera de ellos hace que los trabajos esperen o fallen. ## ** What Happened** \(Todas las veces UTC\) #### **Octubre 1: Docker Gen 2 empleos retrasados hasta 30 minutos A las 07:44, la actividad de disco en los servidores que programan empleos Gen 2 Docker aumentó al 90% de la capacidad y se quedaron allí. A las 07:57, el número de empleos Docker que esperan para empezar comenzó a crecer, y los tiempos de espera se elevaron con él. Una alerta automatizada llamó al ingeniero de guardia a las 08:08. Declaramos un incidente a las 08:42. A las 08:43, los ingenieros identificaron latencia de disco alto en los servidores de programación. Primero creían que los discos eran demasiado lentos para la carga, así que prepararon un cambio a un tipo de disco más rápido. A las 09:01, el equipo acordó dos flujos de trabajo: mover los servidores a discos más rápidos, y añadir un segundo grupo Gen 2 para que los trabajos se dividieran en dos grupos. A las 09:41, los ingenieros encontraron la causa raíz. Cada servidor de programación tiene discos rápidos conectados directamente a él, y el programador está destinado a mantener sus datos de trabajo allí. Estos servidores se ejecutan en una imagen del sistema operativo endurecida por seguridad, y en esa imagen los discos rápidos no se estaban utilizando. El programador escribió sus datos para disminuir los discos conectados a la red. El script que establece los discos rápidos falló sin un error, y una brecha en el registro en estos servidores escondió el fallo. El tráfico Gen 2 también se había vuelto cada vez más explosivo. Los discos más lentos saturados durante esas ráfagas, y el cronogramador cayó detrás. Los tiempos de espera alcanzaron el pico a las 09:54, cuando los trabajos de la clase de recursos media Gen 2 esperaban hasta 30 minutos. A las 09:55, los ingenieros aplicaron una solución que establece los discos rápidos correctamente. A las 10:11, el programador comenzó a colocar trabajos más rápido, lo que confirmó que los servidores podían mantenerse al día con nuevos trabajos. Los tiempos de espera para el Gen 2 cayeron a 13 minutos a las 10:14, 7 minutos a las 10:17, y 1 minuto 30 segundos a las 10:20. Movimos la página de estado a monitorizar a las 10:24 y resolvimos el incidente a las 10:45. A las 11:20, el segundo grupo Gen 2 comenzó a funcionar. ### ** October 7, 13:27 to 14:06: Elevated wait times for machine jobs** Declaramos un incidente a las 13:27 después de ver los tiempos elevados de cola y espera. Pusimos en la página de estado a las 13:31. A las 13:31, los ingenieros vieron que estábamos luchando para adquirir máquinas virtuales para trabajos de máquina, y que el número de trabajos que esperaban para empezar era alto principalmente para trabajos de máquina. A las 13:34, los tiempos de espera fueron elevados a través de los ejecutores. A las 13:48, los tiempos de espera comenzaron a recuperarse mientras más máquinas estaban disponibles, y resolvimos el incidente a las 14:06. ### ** October 7, 14:24 to 15:21: Job failures and workflow delays** Poco después del incidente anterior fue marcado como resuelto, declaramos un nuevo incidente a las 14:24 debido a una fuerte caída en el número de puestos de trabajo presentados a nuestros sistemas de ejecución. A las 14:26, los ingenieros vieron que las cápsulas del servicio de configuración de trabajo estaban descansando. Pods that restart leave fewer copies of the service to answer requests, and jobs that could not retrieve their settings after repeated attempts failed with an infrastructure error. Los flujos de trabajo que ya estaban funcionando esperaban actualizaciones de trabajos que no habían comenzado. A las 14:35, los ingenieros aumentaron la cantidad de memoria disponible a las vainas y aumentaron el número de vainas, lo que dio al servicio más copias para compartir la carga. También aumentamos la cantidad de memoria disponible Las presentaciones de Job comenzaron a recuperarse, y el número de mensajes que fluyen a través de nuestro sistema de flujo de trabajo volvió a niveles normales. A las 14:44, trasladamos la página de estado al monitoreo. Los Pods en el servicio de configuración de trabajo alcanzaron sus límites de memoria y reiniciaron. Aumentamos las asignaciones de memoria y los recuentos de pod, y el servicio recuperado. A las 15:13, aumentamos el número de instancias en nuestros grupos de Docker Gen 2 para que podamos trabajar a través de la acumulación de trabajos de espera rápidamente. Resolvimos el incidente a las 15:21. ### ** October 7, 18:49 to 20:05: Elevated wait times for Docker Gen 2 jobs** Declaramos un nuevo incidente a las 18:49 después de Docker Gen 2 tiempos de espera. A las 18:51, los ingenieros confirmaron que una escasez de instancias disponibles nos impidió adquirir suficiente de ellos, lo que aumentó los tiempos de espera. Los tiempos de espera difieren del tamaño de la clase de recursos. A las 19:52, los tiempos de espera promedio eran inferiores a una hora antes, ya que se disponía de más capacidad, aunque prosiguieron breves picos, y trasladamos la página de estado a monitorizar. Resolvimos el incidente a las 20.05. ### ** October 8: Linux machine and remote Docker jobs wait up to 50 minutes** Declaramos un incidente a las 12:48 después de ver un gran número de trabajos esperando para empezar y largos tiempos de espera para los trabajos de máquina y Docker remoto. A las 12:49, los ingenieros vieron que nuestro proveedor de nube no podía suministrar suficientes casos. Los retrasos continuaron subiendo mientras investigamos. A las 13:13 comenzamos a examinar la lógica que elige un tipo de instancia o región diferente cuando nuestra primera opción no está disponible. A las 13:24, sospechábamos que un defecto en esa lógica nos impedía utilizar otros tipos de instancia en nuestra región primaria, por lo que desactivamos nuestra región de retroceso y confirmamos la causa del defecto. Los ingenieros comenzaron a trabajar en una solución y la desplegaron a las 14:49. El servicio comenzó a solicitar otros tipos de instancia y comenzó máquinas en gran número. A las 14:58, la cola de trabajo esperando una máquina cayó constantemente. Los tiempos promedios de espera en las clases de recursos continuaron bajando a la hora siguiente mientras trabajamos a través del atraso de los trabajos de espera. A las 16:00, la cola de trabajo esperando una máquina limpiada y el número de trabajos de espera volvieron a la normalidad. Movimos la página de estado a monitorizar a las 16:09 y resolvimos el incidente a las 16:35. ## **Future Prevention and Process Improvement** Estamos tomando las siguientes medidas para fortalecer la resiliencia de los tiempos de inicio de trabajo, incluyendo la diversificación de la oferta, la lógica de retroceso y la detección anterior. **Estamos expandiendo nuestras regiones de computación.** En los incidentes del 7 y 8 de octubre, nuestro proveedor de nube no pudo suministrar suficientes casos en las regiones que usamos. Estamos agregando nuevas regiones a nuestra lógica de retroceso para manejar picos de demanda que superan nuestras regiones preferidas. **Estamos fijando la lógica que elige un tipo de instancia diferente.** El 8 de octubre, un defecto impidió que el servicio de suministro de máquinas utilizara otros tipos de instancia en la misma región. Hemos implementado una solución durante el incidente y ahora estamos revisando y refactorizando esta lógica en su conjunto, con pruebas, para que una escasez de un tipo de instancia mueva el trabajo a otro. **Estamos ampliando los tipos de instancia que ofrecemos y asegurando capacidad adicional.** Estamos trabajando con nuestro proveedor de cloud para reservar capacidad adicional en nuestras regiones existentes, y estamos agregando tipos de instancias que pueden funcionar. La demanda industrial de computación de alto rendimiento está creciendo. Estamos diversificando dónde y cómo generamos capacidad para que nuestros clientes estén aislados de la variación de la oferta. **Añadimos un segundo grupo de Docker Gen 2 para que las ráfagas de tráfico se distribuyan en dos grupos.** También estamos agregando alertas sobre la saturación del disco servidor de programación y sobre lo rápido que el programador coloca empleos, y una alerta que dispara cuando un servidor comienza sin sus discos rápidos en uso. Hicimos que el script de configuración de disco falla con un error, y restauramos el envío de registros de estos servidores para que un problema similar sea visible antes. La experiencia del cliente es nuestra máxima prioridad, y nos comprometemos a mejorar continuamente la fiabilidad de nuestros sistemas para que coincidan con la confianza que nuestros clientes depositan en nosotros. Agradecemos a nuestros clientes su paciencia mientras nuestro equipo trabajó para resolver estos incidentes. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de septiembre de 2026 a las 18:13 UTCidentified

   Los clientes pueden experimentar retrasos en nuevas inscripciones y cambios de plan reflejados en su cuenta.

2. 23 de septiembre de 2026 a las 20:06 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 21 de septiembre de 2026 a las 16:22 UTCinvestigating

   Los clientes pueden experimentar retrasos en el inicio de trabajos en Linux Machine. Estamos investigando.

2. 21 de septiembre de 2026 a las 16:48 UTCmonitoring

   Los tiempos de espera de tareas para Linux Machine están volviendo a la normalidad.

3. 21 de septiembre de 2026 a las 17:09 UTCresolved

   This incident has been resolved.

Traducido automáticamente desde la actualización oficial del incidente.

1. 16 de septiembre de 2026 a las 14:55 UTCinvestigating

   Estamos investigando un retraso en la disponibilidad de datos de tuberías. Las tuberías siguen funcionando, pero los datos sobre ellas pueden retrasarse en la interfaz de usuario o API.

2. 16 de septiembre de 2026 a las 15:29 UTCidentified

   Hemos identificado el problema y estamos trabajando en una remediación. Gracias por su paciencia.

3. 16 de septiembre de 2026 a las 17:34 UTCidentified

   Los datos de la tubería están disponibles ahora como normales, con excepción de los resultados de las pruebas, que todavía pueden retrasarse. Continuamos trabajando en esto, gracias por su paciencia.

4. 16 de septiembre de 2026 a las 18:22 UTCmonitoring

   Todos los datos del oleoducto están disponibles como normales. Seguiremos monitoreando la recuperación.

5. 16 de septiembre de 2026 a las 19:30 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 15 de septiembre de 2026 a las 14:42 UTCinvestigating

   Actualmente estamos viendo un retraso en el intercambio de datos de oleoductos en la UI.

2. 15 de septiembre de 2026 a las 15:14 UTCidentified

   Estamos empezando a ver alguna recuperación.

3. 15 de septiembre de 2026 a las 17:02 UTCresolved

   Ahora se han resuelto los datos de los oleoductos que impactan en la interfaz de usuario. Le agradecemos su paciencia mientras nuestros ingenieros trabajaron en reducir los retrasos.

Traducido automáticamente desde la actualización oficial del incidente.

1. 14 de septiembre de 2026 a las 11:59 UTCinvestigating

   Debido al aumento de errores de red y retrasos estamos viendo mayores tiempos de espera para trabajos de macOS. Estamos investigando esto con nuestro proveedor de alojamiento de macOS.

2. 14 de septiembre de 2026 a las 12:36 UTCinvestigating

   Los tiempos de espera para los trabajos de macOS están disminuyendo y seguimos investigando.

3. 14 de septiembre de 2026 a las 12:48 UTCmonitoring

   Nuestro proveedor de alojamiento de macOS ha implementado una mitigación y hemos visto mejores retrasos. Seguiremos vigilando.

4. 14 de septiembre de 2026 a las 12:59 UTCresolved

   Los tiempos de espera para trabajos de macOS vuelven a la normalidad.

Traducido automáticamente desde la actualización oficial del incidente.

1. 10 de septiembre de 2026 a las 20:25 UTCidentified

   Un pequeño número de clientes puede ver errores o ser incapaz de cargar la página de tuberías para proyectos con advertencias de config deprecated, al utilizar la vista de tuberías clásicas. Los clientes en la nueva vista de tuberías no se ven afectados. Hemos identificado la causa y desplegado una solución.

2. 10 de septiembre de 2026 a las 20:25 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 10 de septiembre de 2026 a las 20:26 UTCresolved

   Este incidente ha sido resuelto. Un pequeño número de clientes que crearon oleoductos entre 18:53 UTC y 19:24 UTC que contenían config usando sintaxis de config deprecated habrán visto que sus trabajos de tipo de construcción no comienzan. Los clientes cuyos trabajos o o oleoductos fracasaron pueden reponerlos.

Traducido automáticamente desde la actualización oficial del incidente.

1. 4 de septiembre de 2026 a las 15:16 UTCinvestigating

   Hemos detectado problemas de red que afectan nuestra infraestructura Mac. Estamos investigando y proporcionaremos actualizaciones en breve. Los clientes pueden experimentar queuing durante este tiempo.

2. 4 de septiembre de 2026 a las 15:43 UTCidentified

   Hemos identificado el problema de las redes con nuestro proveedor de infraestructura Mac, y estamos trabajando con ellos para resolver el problema. Estamos empezando a ver algo de recuperación, pero esperamos que los clientes puedan ver algunas colas. Volveremos a actualizar pronto.

3. 4 de septiembre de 2026 a las 16:19 UTCmonitoring

   Nuestro proveedor de infraestructura Mac ha aplicado una solución a este problema de redes y estamos viendo que los tiempos de cola vuelven a la normalidad. Seguiremos vigilando las cosas un poco más. Volveremos a actualizar pronto.

4. 4 de septiembre de 2026 a las 16:55 UTCresolved

   No hemos visto ningún impacto más en los tiempos de cola y todo ha vuelto a la normalidad. Apreciamos su paciencia mientras trabajamos para resolver y monitorear este problema.

Traducido automáticamente desde la actualización oficial del incidente.

1. 26 de agosto de 2026 a las 15:43 UTCidentified

   Los clientes pueden experimentar errores intermitentes al ver el uso del plan UIs o llamar APIs de uso del plan. Hemos identificado la cuestión y estamos trabajando activamente para mitigar estos errores.

2. 26 de agosto de 2026 a las 16:04 UTCmonitoring

   Hemos mitigado el problema con API de uso del plan y las páginas pertinentes de la interfaz de usuario están cargando correctamente.

3. 26 de agosto de 2026 a las 16:10 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 25 de agosto de 2026 a las 23:20 UTCresolved

   Entre 19:49 UTC y 21:07 UTC el 25 de agosto de 2026, los clientes que intentan iniciar sesión en CircleCI usando GitHub no pudieron iniciar sesión, y recibieron un error de GitHub declarando que la URL de callback era inválida. Los clientes que ya estaban conectados no se vieron afectados. El problema se ha resuelto y el inicio de sesión de GitHub funciona normalmente. Le agradecemos su paciencia mientras nuestro equipo trabajó en implementar una solución.

Traducido automáticamente desde la actualización oficial del incidente.

1. 17 de agosto de 2026 a las 21:06 UTCidentified

   La causa de la cuestión ha sido identificada y estamos trabajando para solucionarla.

2. 17 de agosto de 2026 a las 21:36 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 17 de agosto de 2026 a las 21:37 UTCresolved

   Insights data is good once more. Gracias por su paciencia.

Traducido automáticamente desde la actualización oficial del incidente.