Historial de interrupciones de Circle Ci

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.

1. 17 de agosto de 2026 a las 14:04 UTCidentified

   GitHub ha informado de un incidente que está afectando a la oleoducto CircleCI provocando y registrando: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Trabajos que están en vuelos se están ejecutando, pero el estado reportando a GitHub Pull Solicita puede fallar.

2. 17 de agosto de 2026 a las 14:25 UTCidentified

   Seguimos viendo altas tasas de error en las API de GitHub y el tráfico reducido de webhook. Seguiremos proporcionando actualizaciones a medida que se disponga de más información.

3. 17 de agosto de 2026 a las 15:49 UTCidentified

   Continuamos viendo altas tasas de error en las API de GitHub y el tráfico reducido de webhook. Los clientes que utilizan GitHub como VCS pueden experimentar impacto en su experiencia de plataforma CircleCI como resultado. Esto está directamente relacionado con el incidente que GitHub está experimentando: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Proporcionaremos actualizaciones a medida que se disponga de más información.

4. 17 de agosto de 2026 a las 16:22 UTCmonitoring

   Hemos empezado a observar una mejor estabilidad en las API de GitHub. Seguiremos monitoreando mientras se recuperan.

5. 17 de agosto de 2026 a las 17:01 UTCmonitoring

   Las tasas de error y las demoras de GitHub API parecen haberse recuperado. Seguiremos vigilando.

6. 17 de agosto de 2026 a las 17:23 UTCmonitoring

   Algunas de las API de GitHub todavía están degradadas, lo que da lugar a un pequeño número de fallos relacionados con actualizaciones de estado y procesamiento de ganchos. Seguiremos haciendo todo lo posible para mitigar estos efectos.

7. 17 de agosto de 2026 a las 19:05 UTCresolved

   Las API de GitHub parecen estar operando normalmente.

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

1. 15 de agosto de 2026 a las 13:58 UTCresolved

   Tras el mantenimiento planificado que terminó a las 13:00 UTC el 15 de agosto, algunos efectos en el procesamiento del trabajo continuaron durante aproximadamente 30 minutos más allá de la ventana que anunciamos. Algunos clientes continuaron viendo retrasos en el inicio de trabajos, junto con un pequeño número de empleos que fallaron con errores de infraestructura, hasta aproximadamente 13:30 UTC. Esto se ha resuelto y el procesamiento del trabajo 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 la implementación de una solución y disculpa por cualquier inconveniente que el impacto prolongado pueda haber causado.

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

1. 12 de agosto de 2026 a las 16:33 UTCidentified

   GitHub is currently experiencing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h). Customers who use GitHub as their VCS may experience impact to their CircleCI platform experience as a result, impacting checkout and workflows. We will provide another update as we have more information to share. Thank you for your patience.

2. 12 de agosto de 2026 a las 16:43 UTCresolved

   The issue impacting customers who use GitHub as their VCS while GitHub was undergoing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h) has now been resolved. GitHub has resolved the underlying issue and the affected functionality has returned to normal. We thank you for your patience.

1. 11 de agosto de 2026 a las 17:42 UTCresolved

   Between 13:50 UTC and approximately 17:30 UTC on August 11, 2026, some customers experienced delays of up to an hour in pipeline status updates and in notification delivery. Between 16:40 UTC and 17:00 UTC within that same window, a small number of customers also saw newly created pipelines fail to process, appearing in an errored state in the UI and API. The issue has been resolved and all affected functionality has returned to normal. Customers whose pipelines errored during that window can retrigger them. We thank you for your patience while our team worked on implementing a fix.

1. 6 de agosto de 2026 a las 13:06 UTCinvestigating

   Usage API data is delayed for 8/5/2026. All prior data remains available. We are investigating. Thank you for your patience.

2. 6 de agosto de 2026 a las 15:06 UTCidentified

   The issue has been identified and a fix is in progress.

3. 6 de agosto de 2026 a las 19:33 UTCmonitoring

   A fix is in place and is being monitored. Thanks for your patience.

4. 6 de agosto de 2026 a las 19:54 UTCresolved

   The Usage API issue has been resolved. Data has been loaded for yesterday, 8/5/2026. We appreciate your patience.

1. 5 de agosto de 2026 a las 16:58 UTCinvestigating

   Estamos viendo un problema con el servicio de Insights donde los datos de las últimas 24 horas están retrasados. Estamos investigando.

2. 5 de agosto de 2026 a las 17:46 UTCinvestigating

   We are continuing to investigate and will update as we know more.

3. 5 de agosto de 2026 a las 18:25 UTCidentified

   We have identified the issue, and are working with our upstream provider to resolve it now.

4. 5 de agosto de 2026 a las 21:01 UTCresolved

   The upstream issue has been resolved, and the insights data from the last 24 hours has caught up. Thank you for your patience.

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

1. 4 de agosto de 2026 a las 19:27 UTCinvestigating

   We are experiencing increased queue times for Windows, Android, and GPU jobs due to capacity constraints with a third-party infrastructure provider. Jobs will continue to be processed but may take longer than usual to start. Thank you for your patience while our engineers work to resolve this.

2. 4 de agosto de 2026 a las 19:59 UTCmonitoring

   We're starting to see queue times slowly recovering. We'll be monitoring this situation, we appreciate your patience.

3. 4 de agosto de 2026 a las 20:33 UTCmonitoring

   Queue times continue to gradually recover with our third-party infrastructure provider, though we've seen a slight uptick in the last 30 mins. We're keeping an eye on this and will keep you updated as things get back to normal. Again, thank you for your patience.

4. 4 de agosto de 2026 a las 21:16 UTCmonitoring

   Queue times for both Android and Windows jobs, which had been recovering, have started to rise again. This continues to be related to capacity constraints with our third-party infrastructure provider. We'll continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

5. 4 de agosto de 2026 a las 21:46 UTCmonitoring

   Queue times for both Android and Windows jobs continue to be volatile, with sharp swings up and down. This remains related to capacity constraints with our third-party infrastructure provider. Our team will continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

6. 4 de agosto de 2026 a las 22:20 UTCmonitoring

   Queue times for both Android and Windows jobs, affected by capacity constraints with our third-party infrastructure provider, have been recovering significantly for the last half hour. We're continuing to monitor for a bit longer to confirm they return to normal levels. We appreciate your patience.

7. 4 de agosto de 2026 a las 23:40 UTCresolved

   Queue times for Android and Windows jobs have reduced significantly over the last hour. You may still notice brief, isolated queuing at times, but this is no longer at incident-level impact. This was related to capacity constraints with a third-party infrastructure provider. We thank you for your patience while we monitored the situation. If you have any issues, please reach out to our Support team.

1. 24 de julio de 2026 a las 16:35 UTCidentified

   GitHub está experimentando una degradación de los servicios (https://www.githubstatus.com/incidents/yjysg0xrl67m). Los clientes que utilizan GitHub como VCS pueden experimentar impacto en su experiencia de plataforma CircleCI como resultado, lo que impacta el checkout y los flujos de trabajo. Proporcionaremos otra actualización ya que tenemos más información que compartir. Gracias por su paciencia.

2. 24 de julio de 2026 a las 17:41 UTCresolved

   Se ha resuelto la cuestión que afecta a los clientes que utilizan GitHub como VCS mientras que GitHub estaba experimentando una degradación de los servicios (https://www.githubstatus.com/incidents/yjysg0xrl67m). GitHub ha resuelto el problema subyacente y la funcionalidad afectada ha vuelto a la normalidad. Le agradecemos su paciencia.

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

1. 22 de julio de 2026 a las 19:57 UTCinvestigating

   Estamos investigando retrasos en el inicio de trabajos utilizando la clase de recursos gen3.

2. 22 de julio de 2026 a las 23:17 UTCinvestigating

   Seguimos investigando tiempos elevados de espera que afectan a los clientes utilizando los ejecutantes de máquinas gen3. Los empleos afectados pueden tardar más de lo habitual en empezar. Proporcionaremos otra actualización tan pronto como tengamos más información para compartir.

3. 23 de julio de 2026 a las 0:31 UTCinvestigating

   Hemos identificado el problema y estamos trabajando con nuestro proveedor para resolver la disponibilidad de recursos gen 3. El Gen 1 y el Gen 2 están plenamente operativos.

4. 23 de julio de 2026 a las 2:05 UTCresolved

   Entre 19:24 UTC los días 22 de julio y 01:50 UTC el 23 de julio, los clientes que utilizaron la máquina de previsualización gen3 (Linux VM) clases de recursos experimentaron retrasos y, en algunos casos, trabajos que no comenzaron. Hemos eliminado las clases de recursos del gen3 mientras abordamos cuestiones de estabilidad que los afectan. Lamentablemente, se cancelaron los flujos de trabajo que no pudimos proporcionar capacidad de cálculo durante este período. Los clientes afectados deben cambiar su clase de recursos del gen3 al gen2 y rehacer esos flujos de trabajo. Le agradecemos su paciencia mientras nuestro equipo trabajó para resolver esto.

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

1. 22 de julio de 2026 a las 6:13 UTCmonitoring

   Un subconjunto de clientes puede haber experimentado errores de carga app.circleci.com a partir de 03:18 UTC. Se ha implementado una solución y estamos monitoreando para la recuperación completa. Gracias por su paciencia mientras nuestros ingenieros confirman la recuperación. Vamos a proporcionar otra actualización en breve.

2. 22 de julio de 2026 a las 6:27 UTCresolved

   Entre 03:18 UTC y 06:04 UTC el 22 de julio de 2026, un subconjunto de clientes no pudieron acceder a app.circleci.com. La cuestión se ha resuelto y el acceso 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. 20 de julio de 2026 a las 0:35 UTCidentified

   Hemos identificado un problema con las solicitudes de GitHub API que pueden hacer que algunos clientes vean los flujos de trabajo pegados en un estado en funcionamiento o los flujos de trabajo no comienzan. GitHub ha reportado incidentes en las API https://www.githubstatus.com/incidents/ph5nns5y4gxj https://www.githubstatus.com/incidents/8vfyvq16hzh9 Estamos monitoreando la estabilidad de las API de GitHub y actualizaremos esta página ya que hay más información disponible.

2. 20 de julio de 2026 a las 1:24 UTCidentified

   También estamos viendo errores procesamiento webhooks del evento push debido al upstream API outage. Los usuarios pueden necesitar reiniciar los oleoductos para estos eventos de presión.

3. 20 de julio de 2026 a las 1:36 UTCmonitoring

   Estamos viendo signos de recuperación de la API GitHub. Nos quedaremos en un estado de monitoreo para verificar que la tasa de error de API se ha recuperado.

4. 20 de julio de 2026 a las 1:45 UTCresolved

   Las tasas de error de GitHub API se han recuperado a niveles normales. Durante el incidente, algunos clientes pueden haber visto tuberías que no comienzan o no reciben actualizaciones de estado. Algunos oleoductos pueden estar atrapados en un estado de funcionamiento. * Usted debe re-push compromete o utilizar la UI para activar manualmente tuberías que no iniciaron. * Las tuberías en un estado de funcionamiento atascado deben ser canceladas y repetidas. Si encuentras problemas, contacta con CircleCI support.

5. 23 de julio de 2026 a las 21:10 UTCpostmortem

   ## Summary El 20 de julio de 2026 de 00:22 a 01:45 UTC, los clientes de CircleCI usando nuestras integraciones GitHub experimentaron fallos en funcionamiento de tuberías y flujos de trabajo experimentados que se estancan. Durante este incidente, algunos oleoductos disparados por los usuarios usando GitHub no iniciaron o ejecutaron como oleoductos de error. Los clientes cuyos oleoductos fallaron o corrieron como oleoductos de error durante esta ventana deben volver a ejecutarlos. This was caused by an [upstream API degradation at GitHub](https://www.githubstatus.com/incidents/ph5nns5y4gxj), which impacted many GitHub APIs that CircleCI uses to trigger and run pipelines. Para 01:45 UTC, GitHub APIs recuperados, y los oleoductos de clientes corrieron normalmente. La página original del estado de CircleCI se puede encontrar [aquí] (https://status.circleci.com/incidents/9lvbbbs9l87b). ## What Happened \(todas las veces UTC\) Inicio 00:22 el 20 de julio de 2026, GitHub comenzó a devolver errores elevados para las siguientes solicitudes de API: * `applicaciones/*/token` * `repos/*/commits` * `repos/*/*/contentos/* * `repos/*/*/hooks` * `repos/*/*/hooks/* * `repos/*/*/keys` * `repos/*/*/pulls` * `repos/*/*/statuses/* CircleCI se basa en estas solicitudes para activar y ejecutar correctamente los oleoductos. A las 00:22, nuestro monitoreo interno nos alertó sobre el problema. Nuestro equipo comenzó a investigar, y encontró que un pequeño número de oleoductos pertenecientes a proyectos de GitHub no comenzaron o corrieron como oleoductos de error. Esto incluía tuberías programadas y flujos de trabajo. Además, un pequeño número de flujos de trabajo de clientes experimentó trabajos atascados y requirió una repetición del flujo de trabajo para fijar. A las 01:45, GitHub recuperó y el procesamiento del oleoducto volvió a los niveles operativos normales. Sólo los oleoductos desencadenados durante la ventana del incidente se vieron afectados, y los clientes deberían volver a administrar esos oleoductos. ## Future Prevention and Process Improvement Estamos trabajando activamente para mejorar la resiliencia del procesamiento de oleoductos durante las interrupciones del servicio GitHub para reducir el impacto del cliente de incidentes similares en el futuro. Estamos analizando características que ayudarán a los clientes a recuperarse con pasos manuales reducidos después de que los incidentes se resuelvan. 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. 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. 16 de julio de 2026 a las 23:04 UTCinvestigating

   Estamos investigando un problema en el que los clientes pueden ver errores cargando la aplicación web CircleCI y firmando, junto con tuberías y flujos de trabajo programados que no comienzan o llegan tarde. This is related to an ongoing incident affecting GitHub. Puede seguir el estado de GitHub en https://www.githubstatus.com/incidents/gxycch3076xk. Nuestros ingenieros están investigando activamente. Proporcionaremos otra actualización tan pronto como tengamos más información para compartir.

2. 16 de julio de 2026 a las 23:42 UTCidentified

   Continuamos viendo altas tasas de fracaso de las API GitHub que están impactando el procesamiento de login y flujo de trabajo. Seguiremos monitoreando la API GitHub para su recuperación.

3. 17 de julio de 2026 a las 0:09 UTCmonitoring

   ¿Qué está pasando? El incidente que afecta a GitHub ha sido mitigado y ahora está siendo monitoreado en el lado de GitHub. Puede seguir el estado de GitHub en https://www.githubstatus.com/. ¿Qué puedes esperar? El acceso a la aplicación web CircleCI, el registro y el procesamiento de tuberías y flujos de trabajo están volviendo a la normalidad. Todavía puede ver errores intermitentes o retrasos de tuberías programadas y flujos de trabajo como sistemas estabilizados. Gracias por su paciencia mientras monitorizamos la recuperación completa.

4. 17 de julio de 2026 a las 0:26 UTCresolved

   Un incidente que afectó a la API de GitHub causó que los clientes de CircleCI experimentaran errores cargando la aplicación web y firmando, junto con tuberías y flujos de trabajo programados que no iniciaron o se retrasaron. GitHub ha resuelto el incidente subyacente (https://www.githubstatus.com/) y toda la funcionalidad afectada ha regresado a la normalidad. Los clientes cuyos trabajos o o oleoductos fracasaron pueden reponerlos. Las tuberías programadas y los flujos de trabajo que se perdieron durante el incidente no se ejecutarán automáticamente y tendrán que ser re-triggered. Le agradecemos su paciencia.

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

1. 14 de julio de 2026 a las 22:54 UTCidentified

   El 13 de julio entre las 15:30 UTC y las 22:40 UTC, experimentamos retrasos en el inicio de trabajos en Docker (Gen 2) clases de recursos debido a limitaciones de capacidad de nuestro proveedor de nube. Los retrasos alcanzaron aproximadamente 1 minuto 48 segundos. Continuamos experimentando estos retrasos de nuevo desde aproximadamente 15:45 UTC. Hasta ahora, los retrasos han alcanzado aproximadamente 1 minuto 19 segundos. Trabajamos con nuestro proveedor de nube para añadir capacidad y actualizaremos este incidente a medida que la situación cambie.

2. 15 de julio de 2026 a las 0:32 UTCresolved

   El 13 de julio entre las 15:30 UTC y las 22:40 UTC, experimentamos retrasos en el inicio de trabajos en Docker (Gen 2) clases de recursos debido a limitaciones de capacidad de nuestro proveedor de nube. La misma cuestión se repitió el 14 de julio entre las 15:45 UTC y las 22:50 UTC. Las demoras alcanzaron hasta 25 minutos el 13 de julio y hasta 24 minutos el 14 de julio. Las clases de recursos media+ y 2 X-grande+ vieron las esperas más largas. Actualizaciones anteriores en este incidente reportaron cifras basadas en tiempos de espera promedio, que no reflejaron el impacto máximo que algunos clientes podrían haber experimentado. Los tiempos de espera han vuelto a la normalidad. Continuamos trabajando con nuestro proveedor de nube para añadir capacidad antes del próximo período de pico. Gracias por su paciencia.

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

1. 14 de julio de 2026 a las 2:49 UTCinvestigating

   Actualmente estamos investigando errores de login que afectan a algunos clientes usando Bitbucket como su proveedor de identidad.

2. 14 de julio de 2026 a las 3:29 UTCinvestigating

   Nuestro equipo continúa investigando errores de login que afectan a algunos clientes usando Bitbucket como su proveedor de identidad.

3. 14 de julio de 2026 a las 3:51 UTCinvestigating

   ¿Qué ha afectado? Algunos clientes ingresan con una identidad relacionada con Bitbucket son afectados. Esto también puede incluir clientes conectados con GitHub pero tienen una identidad Bitbucket vinculada en su cuenta. Además, algunos clientes están experimentando flujos de trabajo que no están comenzando o actualizando. ¿Qué puedes esperar? Los clientes afectados pueden ver errores de inicio de sesión. Algunos clientes también pueden notar flujos de trabajo que no comienzan o no actualizan como se espera. Gracias por su paciencia mientras nuestros ingenieros investigan. Siguiente actualización Vamos a proporcionar otra actualización tan pronto como tengamos más información para compartir

4. 14 de julio de 2026 a las 4:21 UTCmonitoring

   ¿Qué ha afectado? Algunos clientes ingresaban con una identidad vinculada con Bitbucket fueron afectados. Esto también puede haber incluido clientes conectados con GitHub que tienen una identidad Bitbucket vinculada en su cuenta. Algunos clientes también experimentaron flujos de trabajo que no estaban comenzando o actualizando. ¿Qué puedes esperar? Se ha desplegado una solución. Estamos monitoreando la situación para confirmar la recuperación completa. Siguiente actualización Proporcionaremos una actualización si algo cambia

5. 14 de julio de 2026 a las 5:15 UTCresolved

   Se ha resuelto el problema en el que los clientes inician sesión con una identidad relacionada con Bitbucket experimentaron errores de inicio de sesión, y algunos clientes experimentaron flujos de trabajo que no comenzaron o no actualizaron. Lo que todavía puede experimentar y necesita hacer - Si utiliza Bitbucket como su método de inicio de sesión, por favor regístrese y vuelva a autenticar la integración CircleCI Bitbucket en su cuenta. - Si alguno de tus flujos de trabajo está atascado o mostrando cheques de estado perdidos, por favor reimprimelos para recoger la solución. - Si sigues experimentando problemas después de tomar estos pasos, por favor contacta con CircleCI Support. Le agradecemos su paciencia mientras nuestro equipo trabajó en implementar una solución.

6. 14 de julio de 2026 a las 22:31 UTCpostmortem

   ## Summary Desde 01:33 UTC hasta 05:18 UTC el 14 de julio de 2026, los clientes con una identidad vinculada a Bitbucket no pudieron iniciar sesión en CircleCI, y algunos clientes experimentaron flujos de trabajo que no comenzaron o actualizaron, debido a un cambio en cómo Bitbucket informa de los permisos de cuenta de servicio OAuth. A las 05:07 UTC, implementamos una solución que corrigió cómo nuestros sistemas leyeron el campo de permisos actualizados. Algunos clientes necesitaban iniciar sesión y reacondicionar su integración de Bitbucket después de desplegar la solución. Nuestros sistemas continuaron procesando el trabajo atrasado hasta las 08:39 UTC. Agradecemos a nuestros clientes su paciencia mientras resolvimos este incidente. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación. The status page for this incident can be found [here](https://status.circleci.com/incidents/gsyjwybg477g). ## Background CircleCI admite iniciar sesión con una cuenta GitHub, una cuenta Bitbucket o un correo electrónico y contraseña. Cuando un cliente entra con una identidad vinculada a Bitbucket, o cuando CircleCI necesita refrescar el acceso del cliente en su nombre, intercambiamos una ficha de autorización con el servicio OAuth de Bitbucket. Este intercambio incluye una lista de permisos, o "scopios", el cliente nos ha concedido, que Bitbucket y CircleCI utilizan para confirmar lo que CircleCI está autorizado a hacer en nombre del cliente. ## What Happened \(Todas las veces UTC\) On April 8, 2026, [Bitbucket announced a change to its OAuth service](https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3139): it would be renaming the field used to report a customer's granted permissions. Bitbucket llevó a cabo un período de transición durante el cual estaban disponibles los nombres antiguos y nuevos de campo, y luego se quitó completamente el antiguo nombre de campo el 4 de mayo de 2026. Nuestros sistemas no habían sido actualizados para reconocer el nuevo nombre de campo, por lo que una vez que Bitbucket eliminaba completamente el antiguo, las solicitudes que dependían de él comenzaron a fracasar. A las 01:33 el 14 de julio de 2026, nuestros sistemas comenzaron a no procesar permisos información devuelta para cuentas vinculadas a Bitbucket, porque nuestros sistemas todavía esperaban la antigua estructura de permisos. Esto causó que fracasaran los intentos de login de todas las cuentas vinculadas a Bitbucket, incluso para los clientes que ingresan con GitHub pero tienen una identidad Bitbucket vinculada a su cuenta. A las 01:59, el monitoreo automatizado alertó a nuestro equipo de ingeniería a un aumento de errores en los sistemas afectados. El equipo comenzó a investigar inmediatamente, confirmó el impacto del cliente a las 02:38, y alertó a los clientes a través de nuestra página de estado a las 02:51. A las 03:00, el equipo había aislado los fracasos del campo de Bitbucket renombrado. A partir de las 03:17, las actualizaciones de estado de flujo de trabajo para los oleoductos Bitbucket pertenecientes a clientes con un token de acceso vencido comenzaron a ser bajadas. El cheque de permisos de Bitbucket se utiliza ampliamente a través de nuestra plataforma, y estos fallos de permisos también afectaron algunos de nuestros sistemas internos de procesamiento de empleo. Esto causó que un subconjunto de flujos de trabajo se quedara atascado sin un estado final, y causó algunas solicitudes de pull para mostrar cheques de estado perdidos o atascados. A las 04:21, el equipo implementó una solución inicial que resolvió el problema subyacente, restaurando el flujo de inicio de sesión y devolviendo nuestro sistema de permisos internos a la operación normal. Algunos clientes afectados necesitaban iniciar sesión y volver a conectarse para recoger la solución. Para el 05:07, el equipo implementó dos correcciones adicionales para que nuestros sistemas comenzaran a aceptar el nuevo formato de campo de permisos de Bitbucket. Resolvimos el incidente a las 05:18. Algunos clientes necesitaban iniciar sesión y volver a autenticar su integración de Bitbucket antes de que su cuenta se recuperara completamente. Nuestros sistemas continuaron procesando un trabajo atrasado, regresando a niveles normales en aproximadamente 08:39. ## Future Prevention and Process Improvement Estamos tomando las siguientes medidas para prevenir una recurrencia y mejorar nuestro tiempo de respuesta: **Estamos endureciendo nuestro código de autorización contra los cambios de API de arriba.** Este incidente ocurrió porque nuestro sistema no manejaba con gracia un campo renombrado en una respuesta de un proveedor de identidad de terceros. Actualizaremos inmediatamente nuestro código de autorización para que campos inesperados o desaparecidos de GitHub, Bitbucket y GitLab sean manejados con seguridad. **Estamos mejorando cómo rastreamos los cambios del proveedor.** Actualmente ya monitorizamos los cambios de nuestros proveedores de identidad para exactamente este tipo de cambio de ruptura, pero no añadimos este cambio de proveedor en particular a nuestro monitoreo a tiempo para atraparlo antes de que se enviara. Estamos auditando y ampliando este monitoreo para que los anuncios de proveedores lleguen a nuestro equipo antes de que afecten a los clientes. **Estamos mejorando cómo clasificamos y comunicamos los incidentes en sus primeros minutos.** La clasificación inicial de este incidente no reflejaba inmediatamente su severidad del cliente. Estamos refinando nuestra herramienta de incidentes y orientación para ayudar a los ingenieros a identificar y comunicar el impacto del cliente más rápidamente. **Estamos mejorando la resiliencia de nuestro oleoducto de procesamiento de flujo de trabajo**. Un fallo en la corriente baja en este incidente causó que algunas actualizaciones de estado de flujo de trabajo se retiraran en lugar de volver a retificar o claramente sobresale. Estamos revisando el comportamiento de reingreso y manejo de errores de este sistema de manera que las fallas aguas abajo similares son más visibles y más fáciles de recuperar. 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. 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. 13 de julio de 2026 a las 21:52 UTCinvestigating

   Hemos recibido algunos informes de problemas de red intermitentes entre nuestra infraestructura de mac y un proveedor de VCS de nuevo. Estamos investigando y proporcionaremos actualizaciones.

2. 13 de julio de 2026 a las 22:21 UTCinvestigating

   Todavía estamos investigando estos problemas de red intermitente. Actualizaremos de nuevo en breve, apreciamos su paciencia.

3. 13 de julio de 2026 a las 23:13 UTCinvestigating

   Hemos sido capaces de reproducir el tema, pero todavía parece ser muy intermitente. Continuamos trabajando con nuestro proveedor de infraestructura de Mac para ayudar a diagnosticar el problema. Volveremos a actualizar pronto.

4. 13 de julio de 2026 a las 23:35 UTCmonitoring

   Hemos identificado el problema. Algunos clientes pueden experimentar trabajos que cuelgan o no progresan durante los pasos de la búsqueda de Github debido a problemas intermitentes de redes. Nuestros ingenieros están monitorizando activamente. Mientras tanto, hemos visto el éxito con aumentar el no output timeout a 15 - 20 min para permitir más tiempo para las fetches Github. This can be done by following this community guide: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

5. 14 de julio de 2026 a las 13:59 UTCidentified

   Desafortunadamente todavía hay algunos clientes que pueden estar experimentando empleos que cuelgan o no progresan durante los pasos de la búsqueda de Github debido a problemas de networking intermitente continuos con nuestro proveedor de infraestructura Mac. Nuestros ingenieros están trabajando activamente con ellos para resolver esto. Apreciamos su paciencia. Mientras tanto, hemos visto el éxito con aumentar el no output timeout a 15 - 20 min para permitir más tiempo para las fetches Github. This can be done by following this community guide: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

6. 14 de julio de 2026 a las 15:35 UTCidentified

   Nuestro proveedor de infraestructura Mac está probando cambios en su configuración de red en un esfuerzo por aislar la fuente del problema. Estamos validando activamente si esto resuelve el impacto y seguirá con otra actualización pronto. Mientras tanto, el aumento del no output timeout a 15-20 min sigue ayudando: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

7. 14 de julio de 2026 a las 16:31 UTCidentified

   Hemos identificado el problema como algunas rutas inbound del proveedor VCS afectado causando significativamente menor ancho de banda disponible que está afectando negativamente tiempos de regue. Trabajamos con nuestro proveedor de infraestructura de Mac para intentar desplazar el tráfico de entrada a una ruta diferente, sin embargo este proceso puede tardar un largo período de tiempo para completar. Seguiremos proporcionando actualizaciones a medida que estén disponibles. Como hemos compartido en actualizaciones anteriores, aumentar el no output timeout a 15-20 min sigue ayudando: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

8. 14 de julio de 2026 a las 16:58 UTCmonitoring

   Nuestro proveedor de infraestructura Mac ha cambiado las rutas de entrada y estamos viendo recuperación en tiempos de embrague VCS. Seguiremos vigilando esta cuestión en las próximas horas. Volveremos a actualizar pronto.

9. 14 de julio de 2026 a las 18:28 UTCmonitoring

   Continuamos viendo una recuperación lenta y progresiva en tiempos de embrague VCS. Seguiremos monitoreando y actualizando pronto. Apreciamos su paciencia.

10. 14 de julio de 2026 a las 20:18 UTCinvestigating

    Empezamos a ver a VCS resucitando. Nuestro equipo de ingeniería está investigando y trabajando activamente con nuestro proveedor de infraestructura Mac para resolver esto. De nuevo, apreciamos su paciencia.

11. 14 de julio de 2026 a las 22:15 UTCmonitoring

    Nuestro proveedor de infraestructura Mac ha cambiado más tráfico a proveedores de red de trabajo y estamos empezando a ver una recuperación significativa de nuevo en tiempos de embrague VCS. Como siempre, nuestro equipo de ingeniería continuará monitoreando esto de cerca y proporcionaremos otra actualización pronto.

12. 14 de julio de 2026 a las 23:18 UTCresolved

    Seguimos viendo una importante recuperación de tiempo de VCS en las últimas dos horas. Vamos a resolver este incidente, y nuestro equipo de ingeniería seguirá monitoreando de cerca. Apreciamos enormemente su paciencia mientras trabajamos a través de esto con nuestro proveedor de infraestructura Mac. Por favor, contacte con nuestro equipo de soporte si tiene algún problema.

13. 16 de julio de 2026 a las 1:56 UTCpostmortem

    ## Summary De 18:00 UTC el 13 de julio de 2026 a 23:18 UTC el 14 de julio de 2026, algunos clientes que trabajan en la flota de macOS de CircleCI experimentaron trabajos que colgaron o no lograron progresar durante los pasos de GitHub. Para estos clientes, GitHub buscar pasos que normalmente tomarían 1-2 minutos tomó 20-30 minutos, y tiempo fuera. El problema fue causado por un problema de capacidad y enrutamiento en la ruta de red entre nuestro proveedor de infraestructura Mac y GitHub, y los problemas de redes intermitentes asociados desaceleraron las hembras de GitHub. Durante todo el incidente, nuestro equipo trabajó directamente con nuestro proveedor de infraestructura Mac para identificar y desviar el tráfico de las rutas de red afectadas. Resolvimos una ocurrencia inicial a las 19:40 UTC el 13 de julio. El problema se repitió a las 21:52 UTC ese mismo día, reabrimos el incidente, y fue resuelto completamente por 23:18 UTC el 14 de julio. Nuestra flota de macOS tuvo un problema similar hace varias semanas. De 20:18 UTC el 24 de junio de 2026 a 03:09 UTC el 25 de junio de 2026, los clientes experimentaron un [incidente similar](https://status.circleci.com/incidents/gvysjmkf4ct9) afectando la capacidad de los trabajos de macOS para llegar a GitHub. Ese incidente también fue causado por un problema de enrutamiento de redes en nuestro proveedor de infraestructura Mac. Damos las gracias a nuestros clientes por su paciencia mientras trabajamos a través de este incidente. Vea a continuación las acciones específicas que CircleCI y nuestro proveedor de infraestructura Mac estarán tomando. Por favor, contacte con nuestro equipo de apoyo con cualquier pregunta o preocupación. Las páginas sobre el estado de este incidente pueden encontrarse [aquí](https://status.circleci.com/incidents/n1tc2lw9q7l0) y [aquí](https://status.circleci.com/incidents/7cnl777wp9qz). ## Background Los trabajos de los macOS de CircleCI se organizan en un proveedor de infraestructura Mac de terceros. Ese proveedor se conecta a Internet más amplio, incluyendo servicios como GitHub, sobre múltiples rutas de red redundantes. Cuando uno de esos caminos está experimentando una capacidad reducida o un problema de enrutamiento, los empleos que están buscando código o dependencias de un destino a lo largo de ese camino de red pueden frenar o colgar intermitentemente, incluso cuando la plataforma de CircleCI, el proveedor de infraestructura de terceros, y el servicio de destino están operando normalmente. ## What Happened \(Todas las veces UTC\) A las 18:00 del 13 de julio, algunos clientes que trabajaban en macOS comenzaron a experimentar fallos intermitentes y retrasos en la búsqueda de código y dependencias de GitHub. Abrimos una investigación y alertamos a nuestros clientes a través de nuestra página de estado a las 18:55. Para 19:04, nuestro proveedor de infraestructura de Mac identificó un aumento de latencia en una de sus rutas de red y el tráfico redireccionado alrededor de ella. Se recuperaron tiempos, y movimos el incidente a `Monitoring` a las 19:29, y a `Resolved` a las 19:40. At 20:44 UTC, customers reported that the issue had returned. Reabrimos el incidente y actualizamos nuestra página de estado para 'Investigar' a las 21:52. Durante las siguientes dos horas, trabajamos estrechamente con nuestro proveedor de infraestructura para reunir datos de diagnóstico en un esfuerzo por aislar la ruta de red afectada. Mientras tanto, publicamos guías que recomiendan que los clientes aumenten su configuración de 'no output timeout' a 15-20 minutos, para permitir más tiempo para que las heces GitHub terminen durante las desaceleraciones intermitentes, y movió la página de estado a 'Monitoring' a las 23:35. Después de publicar la guía en torno a 23:35 UTC el 13 de julio, esperábamos que la cuestión de la red subyacente mejorara durante la noche a la mañana. No lo hizo. A las 13:59 UTC el 14 de julio, confirmamos que los clientes seguían experimentando fallos intermitentes y trasladaron la página de estado a 'Investigating'. Nuestro equipo de ingeniería reprodujo el fracaso directamente utilizando nuestras propias herramientas de prueba, lo que ayudó a confirmar que este fue un problema general `git-fetch` en lugar de algo específico para cualquier herramienta de construcción particular, imagen de contenedor, o actualización de software. A las 15:35, actualizamos la página de estado para compartir que nuestro proveedor de infraestructura estaba probando cambios en su configuración de red para aislar la fuente del problema. A las 16:31, actualizamos nuevamente la página de estado para compartir que identificamos la causa como el ancho de banda de entrada reducido en una ruta específica, y que estábamos trabajando con nuestro proveedor para cambiar el tráfico a una ruta diferente. A las 16:36, nuestro proveedor de infraestructura identificó las rutas de red afectadas y desplazó el tráfico de ellas, recogió los tiempos, y a las 16:58, actualizamos la página de estado a `Monitoring`. Por la tarde, algunos clientes volvieron a ver tiempos lentos de captura, y trasladamos la página de estado de nuevo a 'Investigación' a 20:18. Nuestro proveedor de infraestructura identificó dos caminos de red adicionales con rendimiento degradado y tráfico desplazado lejos de ellos para 22:07. Algunas veces se estabilizaron en la hora siguiente, y marcamos el incidente `Resolvado` a las 23:18. En total, los clientes que ejecutan trabajos de Mac pueden haber experimentado desaceleraciones de trabajo intermitente o fracasos por partes de la ventana entre las 18:00 UTC los 13 y 23:18 UTC el 14 de julio. Nuestro proveedor de infraestructura ha reportado resultados de pruebas limpias en toda su red y cree que el problema de capacidad subyacente se originó más arriba, más cerca de GitHub, en lugar de dentro de su propia red. Seguimos monitoreando esto de cerca. ## Future Prevention and Process Improvement Estamos tomando las siguientes medidas para prevenir una recurrencia y mejorar nuestro tiempo de respuesta: **Estamos construyendo monitoreo automatizado adicional para el rendimiento de la flota de macOS GitHub-fetch.** Nuestro amplio monitoreo automatizado no atrapó este incidente. Ahora estamos añadiendo monitoreo de extremo a extremo para las heces GitHub en particular, con el fin de detectar temas similares proactivamente. **Estamos trabajando directamente con nuestro proveedor de infraestructura de Mac en una detección más rápida y proactiva.** Estamos pidiendo a nuestro proveedor que construya monitoreo que pueda detectar una ruta de red degradada y redirigir a su alrededor automáticamente, en lugar de confiar en CircleCI para identificar y solicitar un redireccionamiento durante un incidente activo. **Estamos convirtiendo la herramienta de diagnóstico que construimos durante este incidente en una capacidad permanente.** Esto nos permitirá detectar y reproducir esta clase de falla de red a la demanda yendo adelante, en lugar de asimilar infraestructura de pruebas durante un incidente activo. **Estamos revisando nuestro proceso de respuesta a incidentes para una ventana de confirmación suficiente antes de marcar un incidente relacionado con la red Resolved.** Esto se repite brevemente después de una resolución temprana y prematura; estamos formalizando un período mínimo de monitoreo confirmado-limpia antes de cerrar incidentes de este tipo. Seguiremos proporcionando actualizaciones regulares en el camino a medida que continúe la investigación y la rehabilitación. **Estamos moviendo activamente de un único proveedor para la infraestructura de Mac** ** a múltiples proveedores.** Esto permitirá que CircleCI traduzca las cargas de trabajo de los clientes entrantes al proveedor más disponible y de mejor desempeño. 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. 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. 13 de julio de 2026 a las 18:55 UTCinvestigating

   Hemos recibido informes de problemas de red intermitentes entre nuestra infraestructura de mac y un proveedor de VCS. Estamos investigando y proporcionaremos actualizaciones.

2. 13 de julio de 2026 a las 19:11 UTCidentified

   Trabajamos con nuestro proveedor de infraestructura de Mac para intentar una mitigación. Actualizará de nuevo en breve.

3. 13 de julio de 2026 a las 19:29 UTCmonitoring

   Nuestro proveedor de infraestructura Mac ha implementado una solución, estamos empezando a ver recuperación. Estamos monitoreando y volveremos a actualizar pronto.

4. 13 de julio de 2026 a las 19:40 UTCresolved

   Hemos confirmado la solución con nuestro proveedor de infraestructura y pruebas exitosas en nuestro extremo. Si los clientes continúan viendo cualquier carrera fallida, por favor vuelva a correr para una conexión exitosa y llegue a Soporte si hay otros problemas.

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