Historial de interrupciones de Cycode

1. 20 de octubre de 2026 a las 9:28 UTCinvestigating

   Hemos identificado una causa potencial de los problemas de flujo de inicio de sesión y estamos investigando más.

2. 20 de octubre de 2026 a las 9:54 UTCinvestigating

   Hemos resuelto el problema de flujo de inicio de sesión en la región de la UE.

3. 20 de octubre de 2026 a las 10:04 UTCmonitoring

   La cuestión se ha resuelto y seguimos vigilando el sistema para garantizar la estabilidad.

4. 20 de octubre de 2026 a las 15:43 UTCresolved

   El incidente se ha resuelto totalmente, y no vemos más problemas.

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

1. 18 de octubre de 2026 a las 13:10 UTCinvestigating

   Estamos investigando errores en la aplicación relacionados con el escaneado de PR y fallos de carga de violación. Seguiremos publicando nuevas actualizaciones una vez que encontremos la causa.

2. 18 de octubre de 2026 a las 13:26 UTCidentified

   Teníamos un problema con una de nuestras bases de datos de aplicaciones. La base de datos está de vuelta a las operaciones normales, pero todavía está degradada, y estamos trabajando activamente en arreglarla. La plataforma está de vuelta a operaciones normales, y las violaciones y los escaneos de PR deben funcionar normalmente.

3. 18 de octubre de 2026 a las 13:34 UTCmonitoring

   La base de datos está de vuelta a operaciones normales. Estamos monitoreando activamente para garantizar que no haya cuestiones pendientes.

4. 18 de octubre de 2026 a las 14:40 UTCresolved

   El incidente se ha resuelto totalmente, y no vemos más problemas.

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

1. 13 de octubre de 2026 a las 12:56 UTCmonitoring

   **Monitoring**: escanea API (región de EE.UU.) A principios de hoy, nuestro sistema de alerta detectó que el servicio detrás de las exploraciones API estaba reiniciando más a menudo de lo esperado, lo que causó que algunas solicitudes fallaran durante un breve período. Aumentamos la memoria disponible para el servicio, y ha sido estable desde entonces. Mantenemos el servicio bajo observación estrecha mientras finalizamos una mejora permanente.

2. 13 de octubre de 2026 a las 13:01 UTCresolved

   **Resolvido**: Breve desaceleración de la API de escáneres (región de EE.UU.) El 13 de octubre de 2026, entre 07:58 y 08:28 UTC, algunas solicitudes to the scans API in the US region failed or were slow. Las páginas de escaneado en el Cycode UI y el Cycode CLI pueden haber mostrado errores temporales, y algunos escáneres de solicitud de tira llegó unos minutos más tarde de lo habitual. Aumentamos la memoria disponible para el servicio, que resolvió completamente el tema a las 08:34 UTC. Todos los escaneos apagados terminaron poco después, y no se perdieron datos. Hemos identificado la causa y se está revisando una mejora permanente.

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

1. 13 de octubre de 2026 a las 8:30 UTCinvestigating

   GitLab está experimentando una interrupción del servicio que puede afectar la conectividad de exploración e integración de Cycode PR. El problema se origina de la infraestructura de GitLab y está fuera del control de Cycode. Estamos monitoreando la situación y proporcionaremos actualizaciones mientras GitLab trabaja para restaurar el servicio normal. Para más información, consulte la página de estado de GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3a7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3alab5a

2. 13 de octubre de 2026 a las 8:47 UTCmonitoring

   GitLab ha movido el incidente que afecta a la conectividad de exploración de PR y integración a la fase de monitoreo. GitLab ha implementado una solución y está monitoreando los resultados. Seguimos monitoreando el impacto en las integraciones de Cycode y proporcionaremos nuevas actualizaciones si es necesario. Para más información, consulte la página de estado de GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3a7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3alab5a

3. 13 de octubre de 2026 a las 11:27 UTCresolved

   GitLab ha resuelto el incidente que afecta a la conectividad de exploración e integración de PR

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

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

   El equipo está trabajando activamente con AWS e investigando lo que parece ser un problema de falla de la base de datos que afecta al entorno estadounidense. Compartiremos otra actualización tan pronto como tengamos más información.

2. 7 de octubre de 2026 a las 14:22 UTCinvestigating

   El equipo sigue trabajando con la AWS, que ha intensificado la cuestión internamente. En paralelo, estamos trabajando para restaurar la funcionalidad moviéndonos a otra base de datos. Cualquier solicitud de tirada bloqueada esperando el estado de Cycode se puede desbloquear eliminando los escaneos Cycode de los cheques esperados directamente en su SCM (Administración de Códigos de Fuente). Llegar a su representante de Cycode para ayudar con la racionalización del proceso.

3. 7 de octubre de 2026 a las 14:22 UTCinvestigating

   AWS ha confirmado que la instancia PostgreSQL afectada está actualmente en un estado de recuperación interna. El fallo esperado Multi-AZ no ocurrió como diseñado, y AWS está investigando activamente por qué. Paralelamente, continuamos trabajando para restaurar los servicios afectados utilizando un camino alternativo de base de datos para acelerar la recuperación

4. 7 de octubre de 2026 a las 14:22 UTCinvestigating

   Continuamos investigando una degradación importante en la plataforma estadounidense causada por el agotamiento de la conexión PostgreSQL. Los clientes pueden experimentar tiempos de respuesta lentos, 500 errores elevados y flujos de trabajo más lentos de PR y escáneres CLI. Hemos reducido la carga de base de datos a través de varios servicios e iniciado un fallo RDS. El equipo está trabajando activamente para restaurar el rendimiento normal.

5. 7 de octubre de 2026 a las 14:22 UTCinvestigating

   La base de datos sigue siendo plenamente operacional. Estamos trabajando en aumentar la velocidad de procesamiento más allá de lo habitual para procesar todos los atrasos lo antes posible.

6. 7 de octubre de 2026 a las 14:22 UTCinvestigating

   Hemos notado un rendimiento degradado en prod-us Flujos como Pull Request o CLI escaneado puede ser más lento de lo habitual

7. 7 de octubre de 2026 a las 14:22 UTCinvestigating

   Estamos viendo que la base de datos está restaurando sus capacidades operativas. Vemos primero Pull Request escaneando. Estamos monitoreando el sistema y aumentando el rendimiento.

8. 7 de octubre de 2026 a las 14:22 UTCinvestigating

   El sistema ha vuelto a estar plenamente operativo

9. 7 de octubre de 2026 a las 14:22 UTCresolved

   (1/2) **1. Resumen** El 5 de octubre de 2026, a partir de las 15:55 IDT, los clientes de nuestra plataforma de EE.UU. vieron respuestas lentas, errores intermitentes y retrasos en cheques de solicitud de tirada y escaneos CLI. Algunos clientes cuyos repositorios requieren cheques de petición de Cicode no pudieron fusionarse hasta que se reanudó el escaneo. La cuestión comenzó cuando un proceso de mantenimiento de antecedentes en nuestra base de datos primaria cayó y dejó de completarse, y la base de datos dejó de ahorrar nuevos datos. El servicio de restauración tardó varias horas porque la base de datos de reserva primero tuvo que procesar un gran atraso de cambios. La base de datos estaba de vuelta y la plataforma estaba disponible de nuevo por 19:43 IDT. El procesamiento retrasado entonces atrapado, y el incidente fue resuelto a las 23:24 IDT. Se analizaron las solicitudes que se perdieron durante el incidente. **2. Línea de tiempo clave (IDT)** • ** 5 de octubre de 2026, 12:55 IDT**: Un proceso de mantenimiento de bases de datos de rutina comienza a funcionar mucho más lento de lo normal. Todavía no hay impacto del cliente. • ** 5 de octubre de 2026, 14:53 IDT**: El próximo ciclo de mantenimiento comienza y no termina. • ** 5 de octubre de 2026, 15:55 IDT**: La base de datos deja de guardar nuevos datos y degrada el rendimiento de la plataforma. • ** 5 de octubre de 2026, 16:03 IDT**: La base de datos alcanza su límite de conexión. Los clientes comienzan a ver errores. • ** 5 de octubre de 2026, 16:21 IDT**: Equipo de declaración de incidentes y respuesta comprometido. • 5 de octubre de 2026, 16:24 IDT**: Primera actualización publicada en la página de estado. • ** 5 de octubre de 2026, 16:49 IDT**: Comienza la base de datos de reserva. • ** 5 de octubre de 2026, 17:00 IDT**: Caso de soporte abierto con nuestro proveedor de infraestructura en la nube. • 5 de octubre de 2026, 18:24 IDT**: La vía de recuperación alternativa comenzó en paralelo. Workaround publicado para clientes bloqueados por cheques de solicitud de tirado requeridos. • ** 5 de octubre de 2026, 19:43 IDT**: Base de datos disponible de nuevo, y la API de código y la plataforma de código Cycode son accesibles. • ** 5 de octubre de 2026, 19:54 IDT**: Reanuda la solicitud de búsqueda. • 5 de octubre de 2026, 20:20 IDT**: Aumento de la capacidad de procesamiento para aclarar los acontecimientos retardados. • ** 5 de octubre de 2026, 20:45 IDT**: Se detuvo la carga de trabajo de alto volumen para reducir la carga de la base de datos. • ** 5 de octubre de 2026, 21:56 IDT**: Retire las solicitudes perdidas durante el incidente identificado y escaneado. • ** 5 de octubre de 2026, 23:09 IDT**: Todos los servicios funcionan plenamente. • 5 de octubre de 2026, 23:24 IDT**: Un incidente resuelto. **3. Causa raíz** Nuestra base de datos gestiona un proceso de antecedentes rutinario que ahorra regularmente cambios recientes al almacenamiento permanente. Dos condiciones contribuyeron a frenar ese proceso: • ** Operaciones de datos de corta duración de alto volumen:** algunas de nuestras cargas de trabajo de procesamiento estaban creando y eliminando constantemente un gran número de estructuras de datos de corta duración. • **Una sincronización de fondo retrasada:** un proceso de sincronización de datos había caído muy atrás, lo que impidió que la base de datos se limpiara después de sí misma. El proceso de mantenimiento se desaceleró y finalmente dejó de completarse. La base de datos ya no podía guardar nuevos datos, y las solicitudes comenzaron a colarse. Nuestros servicios retrataron esas solicitudes y abrieron muchas nuevas conexiones, que utilizaron la capacidad de conexión de la base de datos. Los clientes vieron esto como errores y respuestas lentas. Hemos cambiado a nuestra base de datos de reserva. Antes de que pudiera servir al tráfico, tenía que procesar todos los cambios realizados desde el último ciclo de mantenimiento completado, alrededor de cuatro horas de actividad. Eso extendió la salida. **4. Medidas adoptadas** • Reducción de la carga en la base de datos reduciendo temporalmente el procesamiento no esencial. • Comenzó un cambio a la base de datos de reserva. • Inauguró un caso de soporte con nuestro proveedor de infraestructura en la nube y trabajó con ellos en forma escalada. • Preparado un camino de recuperación alternativo en paralelo. • Compartió una ronda de trabajo temporal para clientes bloqueados por los cheques de solicitud de tirado requeridos. • Una vez recuperada la base de datos, mayor capacidad de procesamiento para despejar los eventos retardados.

10. 7 de octubre de 2026 a las 14:22 UTCinvestigating

    La plataforma de EE.UU. está mejorando tras el anterior agotamiento de conexión RDS/PostgreSQL. AWS ha confirmado que la instancia PostgreSQL original ha regresado a un estado operativo, y estamos viendo que los escáneres de PR se procesan de nuevo. La principal degradación restante se retrasa el procesamiento impulsado por GitHub debido a un gran atraso de webhook, que continúa drenando. Seguiremos monitoreando la recuperación y proporcionaremos otra actualización a medida que el procesamiento regrese a la normalidad

11. 7 de octubre de 2026 a las 14:22 UTCinvestigating

    El último atraso sigue siendo procesado a un ritmo constante. Nuestras estimaciones muestran que las últimas partes atrasadas deben ser procesadas por completo en unos 60-90 minutos (20:30 UTC). Vemos la mayoría de los escaneos de solicitud de tirada (60% en el momento de esta actualización) se están completando en menos de 15 minutos. y este número está creciendo constantemente a un ritmo constante. Aparte de ese sistema parece operacional. Creemos que la aplicación/UI está en pleno funcionamiento.

12. 7 de octubre de 2026 a las 14:22 UTCresolved

    (2/2) • Pausó las cargas de trabajo que estaban creando grandes volúmenes de operaciones de datos de corta duración, para reducir la carga de la base de datos mientras se despejaron los acontecimientos retardados. • Escaneó las solicitudes de tirada que se perdieron durante el incidente. **4b. Action Items** • Cambiar la cantidad de datos que se escriben para reducir la carga de la base de datos. • Mover nuestra carga de trabajo de mayor volumen a su propia base de datos dedicada, por lo que un problema no puede afectar al resto de la plataforma. • Agregue alertas y monitoreo más profundo para el uso de la conexión de bases de datos y la salud de bases de datos. • Dar a cada servicio sus propias credenciales de base de datos dedicadas. • Proceso de llegada de eventos más eficientemente para acelerar la recuperación después de una interrupción. • Mejorar el monitoreo de los retrasos de procesamiento y de las alertas internas de eventos. • Revisar la configuración de capacidad y rendimiento de la base de datos para añadir más espacio.

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

1. 5 de octubre de 2026 a las 13:24 UTCinvestigating

   Hemos notado un rendimiento degradado en prod-us Flujos como Pull Request o CLI escaneado puede ser más lento de lo habitual

2. 5 de octubre de 2026 a las 14:17 UTCinvestigating

   Continuamos investigando una degradación importante en la plataforma estadounidense causada por el agotamiento de la conexión PostgreSQL. Los clientes pueden experimentar tiempos de respuesta lentos, 500 errores elevados y flujos de trabajo más lentos de PR y escáneres CLI. Hemos reducido la carga de base de datos a través de varios servicios e iniciado un fallo RDS. El equipo está trabajando activamente para restaurar el rendimiento normal.

3. 5 de octubre de 2026 a las 14:29 UTCinvestigating

   El equipo está trabajando activamente con AWS e investigando lo que parece ser un problema de falla de la base de datos que afecta al entorno estadounidense. Compartiremos otra actualización tan pronto como tengamos más información.

4. 5 de octubre de 2026 a las 15:17 UTCinvestigating

   El equipo sigue trabajando con la AWS, que ha intensificado la cuestión internamente. En paralelo, estamos trabajando para restaurar la funcionalidad moviéndonos a otra base de datos. Cualquier solicitud de tirada bloqueada esperando el estado de Cycode se puede desbloquear eliminando los escaneos Cycode de los cheques esperados directamente en su SCM (Administración de Códigos de Fuente). Llegar a su representante de Cycode para ayudar con la racionalización del proceso.

5. 5 de octubre de 2026 a las 16:10 UTCinvestigating

   AWS ha confirmado que la instancia PostgreSQL afectada está actualmente en un estado de recuperación interna. El fallo esperado Multi-AZ no ocurrió como diseñado, y AWS está investigando activamente por qué. Paralelamente, continuamos trabajando para restaurar los servicios afectados utilizando un camino alternativo de base de datos para acelerar la recuperación

6. 5 de octubre de 2026 a las 16:58 UTCinvestigating

   Estamos viendo que la base de datos está restaurando sus capacidades operativas. Vemos primero Pull Request escaneando. Estamos monitoreando el sistema y aumentando el rendimiento.

7. 5 de octubre de 2026 a las 17:31 UTCinvestigating

   La base de datos sigue siendo plenamente operacional. Estamos trabajando en aumentar la velocidad de procesamiento más allá de lo habitual para procesar todos los atrasos lo antes posible.

8. 5 de octubre de 2026 a las 18:17 UTCinvestigating

   La plataforma de EE.UU. está mejorando tras el anterior agotamiento de conexión RDS/PostgreSQL. AWS ha confirmado que la instancia PostgreSQL original ha regresado a un estado operativo, y estamos viendo que los escáneres de PR se procesan de nuevo. La principal degradación restante se retrasa el procesamiento impulsado por GitHub debido a un gran atraso de webhook, que continúa drenando. Seguiremos monitoreando la recuperación y proporcionaremos otra actualización a medida que el procesamiento regrese a la normalidad

9. 5 de octubre de 2026 a las 19:06 UTCinvestigating

   El último atraso sigue siendo procesado a un ritmo constante. Nuestras estimaciones muestran que las últimas partes atrasadas deben ser procesadas por completo en unos 60-90 minutos (20:30 UTC). Vemos la mayoría de los escaneos de solicitud de tirada (60% en el momento de esta actualización) se están completando en menos de 15 minutos. y este número está creciendo constantemente a un ritmo constante. Aparte de ese sistema parece operacional. Creemos que la aplicación/UI está en pleno funcionamiento.

10. 5 de octubre de 2026 a las 20:09 UTCinvestigating

    El sistema ha vuelto a estar plenamente operativo

11. 5 de octubre de 2026 a las 20:24 UTCresolved

    **1. Resumen** El 5 de octubre de 2026, a partir de las 15:55 IDT, los clientes de nuestra plataforma de EE.UU. vieron respuestas lentas, errores intermitentes y retrasos en cheques de solicitud de tirada y escaneos CLI. Algunos clientes cuyos repositorios requieren cheques de petición de Cicode no pudieron fusionarse hasta que se reanudó el escaneo. La cuestión comenzó cuando un proceso de mantenimiento de antecedentes en nuestra base de datos primaria cayó y dejó de completarse, y la base de datos dejó de ahorrar nuevos datos. El servicio de restauración tardó varias horas porque la base de datos de reserva primero tuvo que procesar un gran atraso de cambios. La base de datos estaba de vuelta y la plataforma estaba disponible de nuevo por 19:43 IDT. El procesamiento retrasado entonces atrapado, y el incidente fue resuelto a las 23:24 IDT. Se analizaron las solicitudes que se perdieron durante el incidente. **2. Línea de tiempo clave (IDT)** • ** 5 de octubre de 2026, 12:55 IDT**: Un proceso de mantenimiento de bases de datos de rutina comienza a funcionar mucho más lento de lo normal. Todavía no hay impacto del cliente. • ** 5 de octubre de 2026, 14:53 IDT**: El próximo ciclo de mantenimiento comienza y no termina. • ** 5 de octubre de 2026, 15:55 IDT**: La base de datos deja de guardar nuevos datos y degrada el rendimiento de la plataforma. • ** 5 de octubre de 2026, 16:03 IDT**: La base de datos alcanza su límite de conexión. Los clientes comienzan a ver errores. • ** 5 de octubre de 2026, 16:21 IDT**: Equipo de declaración de incidentes y respuesta comprometido. • 5 de octubre de 2026, 16:24 IDT**: Primera actualización publicada en la página de estado. • ** 5 de octubre de 2026, 16:49 IDT**: Comienza la base de datos de reserva. • ** 5 de octubre de 2026, 17:00 IDT**: Caso de soporte abierto con nuestro proveedor de infraestructura en la nube. • 5 de octubre de 2026, 18:24 IDT**: La vía de recuperación alternativa comenzó en paralelo. Workaround publicado para clientes bloqueados por cheques de solicitud de tirado requeridos. • ** 5 de octubre de 2026, 19:43 IDT**: Base de datos disponible de nuevo, y la API de código y la plataforma de código Cycode son accesibles. • ** 5 de octubre de 2026, 19:54 IDT**: Reanuda la solicitud de búsqueda. • 5 de octubre de 2026, 20:20 IDT**: Aumento de la capacidad de procesamiento para aclarar los acontecimientos retardados. • ** 5 de octubre de 2026, 20:45 IDT**: Se detuvo la carga de trabajo de alto volumen para reducir la carga de la base de datos. • ** 5 de octubre de 2026, 21:56 IDT**: Retire las solicitudes perdidas durante el incidente identificado y escaneado. • ** 5 de octubre de 2026, 23:09 IDT**: Todos los servicios funcionan plenamente. • 5 de octubre de 2026, 23:24 IDT**: Un incidente resuelto. **3. Causa raíz** Nuestra base de datos gestiona un proceso de antecedentes rutinario que ahorra regularmente cambios recientes al almacenamiento permanente. Dos condiciones contribuyeron a frenar ese proceso: • ** Operaciones de datos de corta duración de alto volumen:** algunas de nuestras cargas de trabajo de procesamiento estaban creando y eliminando constantemente un gran número de estructuras de datos de corta duración. • **Una sincronización de fondo retrasada:** un proceso de sincronización de datos había caído muy atrás, lo que impidió que la base de datos se limpiara después de sí misma. El proceso de mantenimiento se desaceleró y finalmente dejó de completarse. La base de datos ya no podía guardar nuevos datos, y las solicitudes comenzaron a colarse. Nuestros servicios retrataron esas solicitudes y abrieron muchas nuevas conexiones, que utilizaron la capacidad de conexión de la base de datos. Los clientes vieron esto como errores y respuestas lentas. Hemos cambiado a nuestra base de datos de reserva. Antes de que pudiera servir al tráfico, tenía que procesar todos los cambios realizados desde el último ciclo de mantenimiento completado, alrededor de cuatro horas de actividad. Eso extendió la salida. **4. Medidas adoptadas** • Reducción de la carga en la base de datos reduciendo temporalmente el procesamiento no esencial. • Comenzó un cambio a la base de datos de reserva. • Inauguró un caso de soporte con nuestro proveedor de infraestructura en la nube y trabajó con ellos en forma escalada. • Preparado un camino de recuperación alternativo en paralelo. • Compartió una ronda de trabajo temporal para clientes bloqueados por los cheques de solicitud de tirado requeridos. • Una vez recuperada la base de datos, mayor capacidad de procesamiento para despejar los eventos retardados. • Pausó las cargas de trabajo que estaban creando grandes volúmenes de operaciones de datos de corta duración, para reducir la carga de la base de datos mientras se despejaron los acontecimientos retardados. • Escaneó las solicitudes de tirada que se perdieron durante el incidente. **4b. Action Items** • Cambiar la cantidad de datos que se escriben para reducir la carga de la base de datos. • Mover nuestra carga de trabajo de mayor volumen a su propia base de datos dedicada, por lo que un problema no puede afectar al resto de la plataforma. • Agregue alertas y monitoreo más profundo para el uso de la conexión de bases de datos y la salud de bases de datos. • Dar a cada servicio sus propias credenciales de base de datos dedicadas. • Proceso de llegada de eventos más eficientemente para acelerar la recuperación después de una interrupción. • Mejorar el monitoreo de los retrasos de procesamiento y de las alertas internas de eventos. • Revisar la configuración de capacidad y rendimiento de la base de datos para añadir más espacio.

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

1. 7 de octubre de 2026 a las 14:14 UTCresolved

   El sistema está plenamente operativo, sin que se observen cuestiones en curso. Este incidente ya está resuelto.

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

   A las 2:00 PM EDT (18:00 UTC), identificamos un aumento significativo de carga que afecta a la base de datos de autenticación. Para mitigar el problema, realizamos una actualización de instancia. Una breve interrupción de las conexiones de bases de datos puede haber ocurrido durante la actualización. La plataforma es estable y seguimos vigilando de cerca la situación.

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

1. 28 de septiembre de 2026 a las 19:08 UTCmonitoring

   A las 2:00 PM EDT (18:00 UTC), identificamos un aumento significativo de carga que afecta a la base de datos de autenticación. Para mitigar el problema, realizamos una actualización de instancia. Una breve interrupción de las conexiones de bases de datos puede haber ocurrido durante la actualización. La plataforma es estable y seguimos vigilando de cerca la situación.

2. 28 de septiembre de 2026 a las 20:45 UTCresolved

   El sistema está plenamente operativo, sin que se observen cuestiones en curso. Este incidente ya está resuelto.

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

1. 7 de octubre de 2026 a las 14:14 UTCresolved

   Resolved

2. 7 de octubre de 2026 a las 14:14 UTCinvestigating

   Componente GitHub: Pull Request Original GitHub incident:

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

1. 8 de octubre de 2026 a las 8:42 UTCinvestigating

   Componente GitHub: Pull Request Original GitHub incident:

2. 8 de octubre de 2026 a las 8:42 UTCresolved

   Resolved

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

1. 13 de septiembre de 2026 a las 10:36 UTCinvestigating

   Componente GitHub: Pull Request Original GitHub incident:

2. 13 de septiembre de 2026 a las 18:53 UTCresolved

   Resolved

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

1. 7 de octubre de 2026 a las 14:04 UTCmonitoring

   Se observó un punto agudo en la utilización de memoria MemoryDB en prod-us, incluyendo el uso de swap activo. Se ha aplicado la mitigación. Las métricas de MemoryDB se han mantenido estables desde entonces, y el retraso de procesamiento disminuye rápidamente

2. 7 de octubre de 2026 a las 14:04 UTCinvestigating

   Hemos notado un rendimiento degradado en prod-us Flujos como Pull Request o CLI escaneado puede ser más lento de lo habitual

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

   Las métricas de MemoryDB son estables, el lag de procesamiento se ha recuperado, y el sistema ahora está totalmente operativo.

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

1. 8 de septiembre de 2026 a las 16:53 UTCinvestigating

   Hemos notado un rendimiento degradado en prod-us Flujos como Pull Request o CLI escaneado puede ser más lento de lo habitual

2. 8 de septiembre de 2026 a las 17:21 UTCmonitoring

   Se observó un punto agudo en la utilización de memoria MemoryDB en prod-us, incluyendo el uso de swap activo. Se ha aplicado la mitigación. Las métricas de MemoryDB se han mantenido estables desde entonces, y el retraso de procesamiento disminuye rápidamente

3. 8 de septiembre de 2026 a las 17:26 UTCresolved

   Las métricas de MemoryDB son estables, el lag de procesamiento se ha recuperado, y el sistema ahora está totalmente operativo.

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

1. 7 de octubre de 2026 a las 14:14 UTCresolved

   El sistema ha vuelto a estar plenamente operativo.

2. 7 de octubre de 2026 a las 14:14 UTCinvestigating

   Hemos notado un rendimiento degradado en prod-eu. La degradación del rendimiento está afectando toda la aplicación y todos los flujos (**como Pull Request o CLI scan**) pueden ser más lentos de lo habitual. Nuestra investigación inicial sugiere una carga excesiva en la base de datos compartida, haciendo que la lectura y la escritura sean más lentas. El equipo sigue investigando.

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

1. 8 de septiembre de 2026 a las 9:53 UTCinvestigating

   Hemos notado un rendimiento degradado en prod-eu. La degradación del rendimiento está afectando toda la aplicación y todos los flujos (**como Pull Request o CLI scan**) pueden ser más lentos de lo habitual. Nuestra investigación inicial sugiere una carga excesiva en la base de datos compartida, haciendo que la lectura y la escritura sean más lentas. El equipo sigue investigando.

2. 8 de septiembre de 2026 a las 10:52 UTCresolved

   El sistema ha vuelto a estar plenamente operativo.

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

1. 7 de octubre de 2026 a las 14:14 UTCresolved

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/0xbhq84v4mt

2. 7 de octubre de 2026 a las 14:14 UTCinvestigating

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/0xbhq84v4mt

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

1. 8 de octubre de 2026 a las 8:42 UTCresolved

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/0xbhq84v4mt

2. 8 de octubre de 2026 a las 8:42 UTCinvestigating

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/0xbhq84v4mt

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

1. 1 de septiembre de 2026 a las 15:10 UTCinvestigating

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/0xbhq84v4mt

2. 1 de septiembre de 2026 a las 16:05 UTCresolved

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/0xbhq84v4mt

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

1. 8 de octubre de 2026 a las 8:42 UTCinvestigating

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/nrbwjftcz72d

2. 8 de octubre de 2026 a las 8:42 UTCresolved

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/nrbwjftcz72d

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

1. 7 de octubre de 2026 a las 14:14 UTCresolved

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/nrbwjftcz72d

2. 7 de octubre de 2026 a las 14:14 UTCinvestigating

   Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/nrbwjftcz72d

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