Historial de interrupciones de Harness

1. 19 de octubre de 2026 a las 7:46 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 19 de octubre de 2026 a las 8:02 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 19 de octubre de 2026 a las 8:04 UTCmonitoring

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

4. 19 de octubre de 2026 a las 8:21 UTCresolved

   Este incidente ha sido resuelto.

5. 23 de octubre de 2026 a las 18:21 UTCpostmortem

   ## **Summary** El 19 de octubre de 2026, entre aproximadamente 12:10 AM y 12:55 AM PDT, los clientes de Prod4 experimentaron errores e indisponibilidad intermitente de los servicios de Harness Pipelines. Las ejecuciones de oleoductos pesados condujeron a un fuerte aumento en la CPU y el uso de memoria en el servicio de oleoductos, y durante un corto período todos los casos de servicio no estaban disponibles. La ingeniería de daños escalaba el servicio tanto vertical como horizontalmente, que restauraba el servicio. Una solución para el comportamiento subyacente está siendo lanzado hacia fuera. ## ## Root Cause ## El 19 de octubre, un elevado número de ejecuciones simultáneas con gráficos de ejecución muy grandes condujeron a un fuerte aumento de los recursos de grupos. El servicio almacena y recupera este gráfico de ejecución completa para fines de visualización y progresando aún más los oleoductos a los próximos estados. Nuestros auto-scalaers en Prod4 tardaron más de lo habitual en escalar recursos debido a un fuerte aumento en la CPU y la memoria. Como parte de la solución, la actualización del gráfico de ejecución ahora procesará los cambios del gráfico incrementalmente en lugar del gráfico completo. Se está rodando de una manera gradual y se lanzará completamente a la mayor brevedad. ### **Impact** * Usuarios afectados: Clientes en Prod4. * Síntoma: indisponibilidad de la funcionalidad del oleoducto en la plataforma Harness. * Datos: No hay pérdida de datos. * Medida de trabajo sugerida: Ninguno requerido por los clientes. La ingeniería de daños resolvió la cuestión. * Duración del impacto: Aproximadamente 20 minutos de falta total y rendimiento degradado durante 25 minutos. Harness siguió monitoreando después de la recuperación y confirmó la estabilidad de la plataforma con los clientes. *Remediación* **Inmediatamente* La ingeniería de daños escala el servicio de tuberías verticalmente \(más recursos por instancia\) y horizontalmente \(más instancias\), y elimina las instancias en un estado poco saludable. El número de instancias se estabilizó y se restauró el servicio normal. El sistema se mantendrá escalado hasta que la solución esté completamente enrollada. ** Temas de acción y fijación permanentes** Para evitar que estos problemas vuelvan a suceder, Harness es 1. Tuning the auto heal/scaling process so that impact is mimimal to none. 2. Optimizar el flujo gráfico de ejecución para que los gráficos grandes puedan procesarse más rápido.

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

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

   Actualmente estamos investigando esta cuestión.

2. 15 de octubre de 2026 a las 10:10 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 15 de octubre de 2026 a las 10:27 UTCresolved

   Este incidente ha sido resuelto.

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

1. 15 de octubre de 2026 a las 8:04 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 15 de octubre de 2026 a las 8:05 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 15 de octubre de 2026 a las 8:09 UTCmonitoring

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

4. 15 de octubre de 2026 a las 8:15 UTCresolved

   Este incidente ha sido resuelto.

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

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

   Actualmente estamos investigando esta cuestión.

2. 13 de octubre de 2026 a las 1:07 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

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

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

4. 13 de octubre de 2026 a las 4:29 UTCresolved

   Este incidente ha sido resuelto.

5. 23 de octubre de 2026 a las 3:16 UTCpostmortem

   . .

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

1. 12 de octubre de 2026 a las 15:25 UTCinvestigating

   Actualmente estamos experimentando errores HTTP 429 (limitación de valores) cuando Harness Cloud construye acceso a Maven Central, que puede afectar la ejecución de la construcción. Nuestro equipo está trabajando activamente con Sonatype para resolver el problema lo antes posible. Proporcionaremos más actualizaciones a medida que avancemos.

2. 12 de octubre de 2026 a las 19:31 UTCresolved

   Este incidente ha sido resuelto.

3. 23 de octubre de 2026 a las 3:06 UTCpostmortem

   tldr: \(Había una tasa breve límite por maven central\) Más detalles a seguir

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

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

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

2. 8 de octubre de 2026 a las 10:53 UTCresolved

   Este incidente ha sido resuelto.

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

1. 6 de octubre de 2026 a las 21:46 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 6 de octubre de 2026 a las 21:47 UTCinvestigating

   Seguimos investigando esta cuestión.

3. 6 de octubre de 2026 a las 22:03 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

4. 6 de octubre de 2026 a las 22:30 UTCmonitoring

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

5. 6 de octubre de 2026 a las 22:30 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados. Tenemos confirmación de esto arreglando el problema.

6. 6 de octubre de 2026 a las 22:44 UTCresolved

   Este incidente ha sido resuelto.

7. 23 de octubre de 2026 a las 2:12 UTCpostmortem

   # 1. Resumen El 6 de octubre de 2026, los oleoductos que contenían una etapa IaCM no pudieron comenzar en Prod1 durante aproximadamente dos horas. Los usuarios afectados vieron un error cuando el oleoducto intentó crear su plan de ejecución. Las tuberías que no utilizaron una etapa IaCM continuaron funcionando normalmente a lo largo de todo. La causa subyacente fue un defecto interno de registro en el servicio que maneja la ejecución de la etapa IaCM: bajo una condición de tiempo específica y poco frecuente, el propio sistema de registro del servicio podría terminar esperando por sí mismo indefinidamente, que a su vez estancó el proceso más amplio responsable de la preparación de planes de ejecución del oleoducto. El problema fue desencadenado por una insólita gran explosión de actividad de registro de la tubería de un cliente. Resolvimos el impacto inmediato devolviendo el servicio a su versión estable anterior, y un código permanente está actualmente en pruebas. 2. Impacto * Todos los oleoductos que utilizaron una etapa IaCM en Prod1 no pudieron comenzar por aproximadamente dos horas. * Múltiples clientes en el grupo Prod1 fueron afectados. * Las tuberías que no utilizaron una etapa IaCM no fueron afectadas y continuaron funcionando normalmente. * No se perdieron datos como resultado de este incidente. * Como efecto secundario de la devolución utilizada para resolver este incidente, una solución no relacionada para un cliente \(extendiendo cuánto tiempo un cierto token de autenticación permanece válido durante los oleoductos de larga duración\) fue revertido temporalmente. Ese arreglo se reaplicó la misma noche. # 3. Causa raíz El servicio responsable de las etapas del oleoducto IaCM registra su actividad a través de una cola interna: los mensajes de registro se colocan en la cola, y un trabajador de fondo único lee continuamente y escribe los mensajes. Separadamente, ese servicio tiene un filtro que puede reescribir la gravedad de ciertos mensajes de registro de nuevo en esa misma cola. Bajo una condición específica y estrecha de tiempo, esto creó un estancamiento, si la cola sucedía estar completamente llena en el momento exacto un mensaje reescrito se estaba sometiendo a él, el trabajador responsable de liberar espacio en la cola se quedaría atascado esperando espacio para liberar, una condición que nunca podría resolver, ya que era la única cosa que podría haber liberado ese espacio. Una vez que eso sucedió, cada otra parte del servicio que necesitaba registrar cualquier cosa también se quedó atascada esperando, que encadenó en el proceso de creación de plan de oleoducto que falló por cualquier oleoducto utilizando una etapa IaCM. Resolución 4. * Rolled the service back to its last stable version, which resolved the immediate incident. 5. Medidas preventivas 1. **Optimizar el defecto subyacente**: Optimize and sinne the logging filter so that rewrite a message's gravity occurs on the thread that generated the log line, rather than being resubmitted through the same background worker's queue, eliminate the deadlock condition entirely. 2. ** Mejorar el monitoreo de la salud de logging-queue**: añadir métricas y alertar sobre esta cola interna de modo que esta clase de páginas de saturación nuestro equipo de on-call automáticamente en lugar de confiar en los informes de los clientes. 3. **Evaluar los límites y realizar pruebas de alta tensión con tuberías muy grandes**:

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

1. 16 de octubre de 2026 a las 10:41 UTCresolved

   El 7 de octubre de 2026, de 08:00 UTC a 11:00 UTC (1:30 PM a 4:30 PM IST), algunas ejecuciones de oleoductos en el grupo Prod 7 vieron fallos intermitentes en las evaluaciones de pasos de la Política (OPA).

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

1. 6 de octubre de 2026 a las 12:54 UTCmonitoring

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

2. 6 de octubre de 2026 a las 15:35 UTCresolved

   Este incidente ha sido resuelto.

3. 10 de octubre de 2026 a las 1:57 UTCpostmortem

   #### Summary Clientes en el Prod 2 experimentaron fallos intermitentes de unos pocos pasos Verificar al inicio. Los pasos afectados fallaron poco después del lanzamiento con un mensaje que indica la verificación continua\(CV\) no pudo alcanzar un servicio interno de Harness. El problema se deriva de una actualización reciente de servicio que introdujo la conexión de unión para mejorar el rendimiento y la confiabilidad con un ajuste de mantenimiento incompatible con el tiempo del servicio receptor. No se perdieron ni corrompieron los datos del cliente. ## Impacto del cliente Los clientes que utilizan CV Verificar pasos en Prod-2 vieron fallas intermitentes durante la ventana del incidente. La tasa de fracaso fue baja: la mayoría de las ejecuciones se completaron con éxito a lo largo de la ventana. Las tuberías que no utilizaron CV Verify pasos no fueron afectadas. ## Root Cause Una actualización reciente del servicio CV introdujo la conexión a un componente de plataforma interna, con una duración continua más larga que el tiempo ocioso de ese componente. Conexiones lo suficientemente largas fueron cerradas silenciosamente por el servidor; el servicio CV no detectó esto y no tenía lógica de reingreso para tales fallas, lo que los hacía superficiales directamente como fallas de paso Verify. El problema era intermitente porque sólo afectaba a las conexiones que resultaban ser lo suficientemente ociosas para expirar. ### Mitigation La duración de mantenimiento de la conexión se redujo a caer dentro del tiempo ocioso del servicio receptor. Los fracasos descendieron a casi cero inmediatamente, y no se han observado nuevas fallas de este tipo en ningún entorno de producción. ## Next Steps Para evitar la recurrencia, Harness: * **Manejo de conexión de archivo:** En sintonía la reiniciación automática por defecto en las fallas de conexión, por lo que los errores de conexión se manejan de forma transparente. * **Agregue la resiliencia al inicio del paso:** Introducir reingreso con retroceso para la llamada de servicio interno en el inicio del paso Verify, por lo que las fallas transitorias aisladas no son superficiales como fallas inmediatas. * **Mejor alerta:** Mejora de la vigilancia de las tasas de error de conexión interna.

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

1. 6 de octubre de 2026 a las 11:58 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 6 de octubre de 2026 a las 11:59 UTCinvestigating

   Seguimos investigando esta cuestión.

3. 6 de octubre de 2026 a las 12:24 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

4. 6 de octubre de 2026 a las 16:21 UTCresolved

   Este incidente ha sido resuelto.

5. 9 de octubre de 2026 a las 18:48 UTCpostmortem

   ## Summary El ** Martes, 6 de octubre de 2026**, los oleoductos IaCM que utilizan el plugin **OpenTofu** en **Prod1** fallaron intermitentemente para una cuenta de producciónAfectados se ejecutan secretos inyectados con éxito, luego pasos posteriores se dieron tiempo o falló la autenticación. El mismo oleoducto a menudo tuvo éxito en la reingresación, sin ningún cambio de configuración. Típicas ejecuciones fallidas corrieron durante unos 90 minutos. Otros módulos de Harness no fueron ampliamente afectados. No tenemos reporte de pérdida de datos del cliente. Las tuberías que terminaron dentro de la vida token no fueron afectadas por este defecto. ## Root Cause Las etapas IaCM minaron fichas de autenticación que caducaron después de una hora. Los cheques de política más tarde en un largo plazo rechazaron el token, por lo que el paso se fijó o falló la autenticación. Esa vida de una hora fue arreglada. Corrientes de unos 90 minutos cruzaron la marca de una hora, por lo que los fallos aparecieron en tuberías más largas y a menudo se despejaron en una retracción más corta. Un conjunto separado de errores del plan en la misma cuenta vino de la configuración credencial en el espacio de trabajo del cliente y está fuera de este incidente. ## Impacto * **Área productora:** Las tuberías IaCM usando los plugins IaCM hablando con OPA sdk. * ** Experiencia del cliente:** timeouts intermitentes y fallas de autenticación después de la inyección secreta, en carreras más de una hora. * **Environment:** Prod1, una cuenta de producción * **Data:** No se informó de pérdida de datos. ## Remediation * Inmediatamente* Inauguró una página de estado para la cuenta de Prod1 afectada, y envió un cambio de administrador de IaCM provisional para una clase de los fallos observados mientras se construyó el plugin. * *Permanente* Solicite un hotfix plugin OpenTofu para que la expiración de token sea configurable. En producción la vida se crió a alrededor de 6 horas, por lo que un largo oleoducto no sobrevivió el token. El hotfix fue validado en QA y desplegado en Prod1. Nos disculpamos por la interrupción causada. Por favor contacte a su contacto de soporte de Harness si tiene alguna pregunta más.

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

1. 5 de octubre de 2026 a las 22:01 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 5 de octubre de 2026 a las 23:50 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 6 de octubre de 2026 a las 0:26 UTCmonitoring

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

4. 6 de octubre de 2026 a las 0:26 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

5. 6 de octubre de 2026 a las 0:39 UTCresolved

   Verificó los problemas de SSO resueltos y resueltos.

6. 9 de octubre de 2026 a las 16:17 UTCpostmortem

   ## Okta Application SP-Initiated SSO Login Failures # Resumen Entre el 5 de octubre de 2026, 18:18 UTC y el 6 de octubre de 2026, 00:26 UTC, algunos clientes de Harness no pudieron iniciar sesión en el servidor de Harness Hosted MCP a través de SAML Single Sign-On \(SSO\). La autenticación principal del usuario de Harness Portal siguió siendo plenamente operacional. Los usuarios afectados vieron errores de inicio de sesión o fueron redirigidos a una página SSO inválida en lugar de completar el registro. El problema fue causado por cambios en la actualización de la versión del servicio de identidad Harness HarnessID. Lo arreglamos con una serie de hotfixes, y SSO login fue completamente restaurado para todos los clientes afectados. # Impacto Los usuarios que firman a Harness MCP a través de SAML SSO no pudieron completar la autentificación. Las sesiones existentes de MCP que dependían de SSO no podían ser refrescadas, por lo que algunos usuarios tenían que firmar de nuevo y no podían. No-SSO logins a Hosted MCP trabajó durante la mayoría del incidente. No se perdieron ni expusieron datos de clientes. Los clientes que utilizan su propia configuración genérica de aplicaciones SAML 2.0 en Okta no se vieron afectados. # Root Cause El 29 de septiembre de 2026, se publicó una versión actualizada de la aplicación Harness a la Red de Integración Okta. La actualización agregó soporte para registrar URLs de respuesta múltiple \(ACS\), para que los clientes que ejecutan Harness en varias regiones o entornos puedan configurar más de una URL de llamada. Harness incluye un valor AssertionConsumerServiceURL en la solicitud de autenticación SAML que envía a Okta. Antes de esta actualización, Okta no validó ese valor para instancias de aplicación sin nuevas URLs ACS configuradas y en su lugar devolvió la afirmación SAML a la URL ACS predeterminada de la aplicación. Después de la actualización, esta validación se hizo activa en todas las instancias de aplicación existentes, incluyendo aquellas donde el cliente nunca había configurado una URL adicional de ACS. Debido a que el valor solicitado no estaba presente en la lista registrada de la instancia, Okta devolvió un error HTTP 400. La aplicación actualizada pasó por la revista OIN estándar de Okta, que incluye la verificación atrasada de compatibilidad con las instalaciones existentes de la integración publicada. Este cambio en el comportamiento de validación de instancias sin URLs ACS adicionales configuradas no se aplicó durante esa revisión, por lo que llegó a los clientes en el momento de la liberación. Remediación ** Respuesta inmediata** Se publicaron dos rondas de trabajo en la página de estado: registrarse desde la ficha Harness en Okta \(IdP-iniciated login\), que no fue afectado, o registrar la URL de Okta SSO de la aplicación en el campo de URLs ACS adicionales de la aplicación Harness Okta. Harness contrató a cada cliente afectado directamente y validó su registro. **Resolución** Enrollar la aplicación de nuevo a la versión anterior se evitó deliberadamente, ya que eso sólo aplazaría la misma perturbación a la próxima versión. Cada cliente afectado fue desbloqueado a través del registro de URL de ACS, y estamos trabajando con Okta para hacer la validación de URL de ACS otra vez condicional, de modo que las instancias sin URLs ACS adicionales configuradas se comportan exactamente como lo hicieron antes, y no se requiere ninguna acción del cliente. # Action Items Para evitar que esas cuestiones vuelvan a suceder, Harness tomará los siguientes elementos de acción 1. Trabajar con Okta para restaurar validación de URL ACS condicional, por lo que las instancias sin URLs ACS adicionales configuradas se comportan exactamente como antes y no se requiere ninguna acción del cliente. 2. Publicar una guía de configuración dedicada para la aplicación Harness OIN en la documentación de Harness, incluyendo respuesta \(ACS\) requisitos de URL. 3. Agregue un paso independiente de verificación previa a la liberación de las configuraciones de clientes existentes para cualquier actualización futura de la aplicación Okta publicada, junto con la propia revisión de Okta. 4. Migrar la autenticación del usuario a Harness ID, que elimina la dependencia de este comportamiento de validación completamente.

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

1. 29 de septiembre de 2026 a las 20:31 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 29 de septiembre de 2026 a las 20:31 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 29 de septiembre de 2026 a las 20:57 UTCidentified

   Identificamos un problema que sólo se aplica a la entrada iniciada por SP a través de la aplicación Harness Okta publicada. Después de una actualización reciente de esa aplicación, esos intentos de inicio de sesión devolvieron un error HTTP 400 cuando la URL SSO configurada faltaba de URLs ACS adicionales. Las configuraciones generales SAML 2.0 en Okta no están afectadas. Soluciones inmediatas: Use IDP-initiated login. Iniciar la sesión de la ficha de aplicación Harness en Okta. O Añade tu URL de Harness SSO a URLs adicionales de ACS en la aplicación Harness Okta publicada.

4. 2 de octubre de 2026 a las 0:33 UTCresolved

   Este incidente ha sido resuelto.

5. 7 de octubre de 2026 a las 18:30 UTCpostmortem

   # 1. Resumen A partir del 29 de septiembre de 2026, los clientes que ingresan a Harness a través de la aplicación Harness publicada en la Red de Integración Okta \(OIN\) no pudieron completar el login SSO iniciado por SP. Los usuarios afectados recibieron un error HTTP 400 de Okta en lugar de ser firmados. El problema fue introducido por un cambio en cómo Okta validó la URL de respuesta solicitada \(ACS\) para las instalaciones existentes de la aplicación Harness publicada. Workarounds were published within an hour of the first report, and every affected customer was unblocked. 2. Impacto * El impacto se limitó a los clientes usando la aplicación Harness publicada de la Red de Integración Okta para la entrada iniciada por SP \(iniciando el inicio de sesión de Harness\). Esos intentos devolvieron un error HTTP 400 de Okta. * Acceso iniciado por IdP, iniciado desde la baldosa de Harness en Okta, continuó trabajando a lo largo de todo. * Los clientes que utilizan su propia configuración genérica de aplicaciones SAML 2.0 en Okta no se vieron afectados. * No se perdieron ni expusieron datos de clientes. # 3. Causa raíz El 29 de septiembre de 2026, se publicó una versión actualizada de la aplicación Harness a la Red de Integración Okta. La actualización agregó soporte para registrar URLs de respuesta múltiple \(ACS\), para que los clientes que ejecutan Harness en varias regiones o entornos puedan configurar más de una URL de llamada. Harness incluye un valor AssertionConsumerServiceURL en la solicitud de autenticación SAML que envía a Okta. Antes de esta actualización, Okta no validó ese valor para instancias de aplicación que no tenían URLs ACS adicionales configuradas, y simplemente devolvió la afirmación SAML a la URL ACS predeterminada de la aplicación. Después de la actualización, esta validación se hizo activa en todos los casos existentes de la aplicación, incluyendo aquellos donde el cliente nunca había configurado una URL adicional de ACS. Debido a que el valor solicitado no estaba presente en la lista registrada de la instancia, Okta rechazó la solicitud de autenticación con un error HTTP 400. La aplicación actualizada pasó por la revisión editorial OIN estándar de Okta, que incluye la verificación de compatibilidad atrasada contra las instalaciones existentes de una integración publicada. Este cambio en el comportamiento de validación de instancias sin URLs ACS adicionales configuradas no se aplicó durante esa revisión, por lo que llegó a los clientes al lanzamiento. 4. Remediación ** Respuesta inmediata** Dos rondas de trabajo se publicaron en la página de estado: registrarse desde la ficha Harness en Okta \(IdP-iniciated login\), que no fue afectado; o registrar la URL de Okta SSO de la aplicación en el campo de URLs ACS adicionales de la aplicación Harness Okta. Asistencia comprometida con cada cliente afectado directamente y validó el registro con ellos. **Resolución** Enrollar la aplicación de nuevo a la versión anterior se evitó deliberadamente, ya que eso sólo aplazaría la misma perturbación a la próxima versión. Cada cliente afectado fue desbloqueado a través del registro de URL de ACS, y estamos trabajando con Okta para hacer la validación de URL de ACS otra vez condicional, de modo que las instancias sin URLs adicionales de ACS configuradas se comportan exactamente como lo hicieron antes y no se requiere ninguna acción del cliente. # 5. Temas de acción Para evitar que estos problemas vuelvan a suceder, estamos trabajando en Silencio **Acción Tema** Silencio... Silencio Trabajar con Okta para restaurar validación de URL ACS condicional, por lo que las instancias sin URLs ACS adicionales configuradas se comportan exactamente como antes y no se requiere ninguna acción del cliente. Silencio ← Publicar una guía de configuración dedicada para la aplicación Harness OIN en la documentación de Harness, incluyendo respuesta \(ACS\) requisitos de URL. Silencio Añadir un paso de verificación independiente antes de la liberación de las configuraciones de clientes existentes para cualquier actualización futura de la aplicación de Okta publicada, junto con la propia revisión de Okta. TEN Migrar autenticación del usuario a Harness ID, que elimina la dependencia de este comportamiento de validación completamente. Silencio

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

1. 29 de septiembre de 2026 a las 18:45 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 29 de septiembre de 2026 a las 21:55 UTCmonitoring

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

3. 29 de septiembre de 2026 a las 22:01 UTCresolved

   Este incidente ha sido resuelto.

4. 2 de octubre de 2026 a las 22:40 UTCpostmortem

   #### Summary Entre aproximadamente **11:37 AM y 3:01 PM PDT \(18:37–22:01 UTC\) el 29 de septiembre de 2026**, los clientes que utilizan los corredores de nube de Linux autoapropiados de Harness CI en **prod1/prod2 \(us-west1\)** experimentaron fallos intermitentes de redes durante la ejecución del oleoducto, principalmente Git/network timeouts al buscar código fuente. *Causa real* Esto se debió principalmente a la saturación de nuestro NAT, que se vio exacerbada por una capacidad de computación temporal de proveedores de cloud, evitando que se proporcionara un nuevo VM allí. ## Impacto * Los clientes que ejecutan Linux CI autoanfitriona construyen en nosotros-oeste1 sierra ** fallos de construcción/pipeline intermitentes**, no un outage completo. * Errores observados de cara al cliente incluyeron cronologías de captura de Git, por ejemplo `Failed to connect to github.com port 443: Connection timed out` **Remediación** * **Inmediato:** Carga de ARM reequilibrada de construcción-VM desde la ruta saturada hacia el centro1 \(partialmente limitada por la capacidad central1\); reinicia las puertas de Cloud NAT afectadas, que estabilizaron la red de tuberías. ** Temas de acción** 1. Asegurar la puerta de entrada/capacidad IP adicional \(En progreso\) 2. Mejorar la detección y alerta de saturación NAT antes del impacto del cliente. 3. Evaluar las contingencias de la capacidad de registro cruzado para que la escasez de cálculo de una sola región no bloquee la mitigación de las deficiencias.

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

1. 29 de septiembre de 2026 a las 14:41 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 29 de septiembre de 2026 a las 15:54 UTCmonitoring

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

3. 29 de septiembre de 2026 a las 15:57 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

4. 29 de septiembre de 2026 a las 18:49 UTCresolved

   Este incidente ha sido resuelto.

5. 2 de octubre de 2026 a las 5:37 UTCpostmortem

   **Summary** Los clientes de Prod-2 experimentaron tasas de falla elevadas en tuberías de verificación continua. Los trabajos de verificación no pudieron completar o reportar errores porque los trabajadores de recopilación de datos CV no pudieron comunicarse con el servicio de plataforma que coordina su trabajo. Esto fue causado por un inesperado pico de tráfico a uno de nuestros sistemas de backend. El servicio fue restaurado mediante la ampliación del componente de la plataforma afectada. No se produjo pérdida de datos ni corrupción. ** Impacto del cliente** Los clientes que utilizan la verificación continua en los trabajos del oleoducto de verificación Prod-2 fallan o pierden tiempo durante la ventana del incidente. Una importante fracción de los casos de trabajo de verificación que se llevaron a cabo durante este período terminó en un fracaso operacional. Las tuberías que no utilizan CV continuaron operando normalmente. *Causa real* Un gran funcionamiento automatizado de provisión creó un número significativo de trabajadores de monitoreo de CV persistentes en una ventana corta, que abrumaron un componente de plataforma compartida. El aumento repentino de las llamadas salientes simultáneas agotó las conexiones de red disponibles en cada instancia de servicio. **Mitigación** Se levantó el límite máximo de escalado para el servicio CV, permitiéndole ampliar la capacidad para satisfacer la demanda. Los fracasos se detuvieron poco después de que se terminara la escala. **Siguientes pasos** Para evitar la recurrencia, Harness: * **Aumento de la capacidad de los cuartos de baño y añadir salvaguardias de provisión:** Aumentar el límite de escalado de servicios CV para mantener la sala bajo cargas de explosión, e introducir la tasa de limitación para la provisión masiva de servicios monitoreados. * **Mejora la Resiliencia* Agregue el retroceso exponencial y el jitter para los registros de trabajadores, y utilice una piscina de conexión reutilizable para reducir la sobrecarga y evitar que los fallos transitorios se compliquen bajo alta concurrencia. * **Mejora la vigilancia y alerta:** Mejorar la alerta para las tasas de crecimiento anormales de los trabajadores por cuenta propia, por lo que se detectan y actuan condiciones similares antes.

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

1. 29 de septiembre de 2026 a las 13:12 UTCresolved

   El 28 de septiembre de 2026, observamos un problema con la copia de archivos de la Harness Filestore durante el paso de exportación, donde los archivos estaban siendo copiados como archivos nulos/vacíos. Como resultado, todos los oleoductos que utilizan las API de Filestore fueron bloqueados durante la ventana del incidente. El problema fue causado por un despliegue de banderas de características que fue revertido una vez descubierto el problema. Todas las operaciones vuelven a la normalidad.

2. 1 de octubre de 2026 a las 17:28 UTCpostmortem

   #### Summary El 28 de septiembre de 2026, algunos clientes de Prod-2 experimentaron fallos en los pasos de oleoductos de CD que leían contenido de File Store usando expresiones de oleoductos \(por ejemplo, `\). Las expresiones afectadas volvieron nulas en lugar del contenido de archivo esperado, causando pasos dependientes para fallar o comportarse incorrectamente. El problema se trazó a una actualización de plataforma que apretó los controles de autorización en las API de File Store. La actualización se reenrolló y las expresiones File Store han estado trabajando normalmente desde entonces. ## Impacto del cliente * Sólo los pasos de oleoducto en Prod-2 que leyeron contenido de File Store a través de expresiones fueron afectados. Las tuberías que no utilizan expresiones de File Store no fueron impactadas. * Expresiones afectadas resueltas a anular, causando pasos que dependen de la configuración o configuración de los archivos para fallar o producir la salida incorrecta. * No se modificó el contenido de File Store. No se expusieron archivos, secretos, credenciales o artefactos, y no se perdieron datos. ## Root Cause Como parte de una iniciativa de seguridad en curso, Harness implementó controles de autorización más estrictos en varias API de plataforma, incluyendo la API que sirve contenido de File Store. Cuando un oleoducto evalúa una expresión de File Store, un servicio interno de Harness llama a otro para recuperar el archivo. Las nuevas comprobaciones de autorización fracasaron, lo que dio lugar a que se rechazaran las solicitudes y a que las expresiones volvieran nulas. ### Mitigation Una vez que la actualización de la plataforma se identificó como la causa, se revolvió a través del entorno de producción. Las expresiones de File Store han resuelto correctamente desde la devolución. No se requiere ninguna acción del cliente. ### Preventive Measures ' Next Steps * **Audit affected APIs:** Revise todas las API en las que se aplicaron las comprobaciones de autorización más estrictas para garantizar que se contabilizan correctamente las llamadas internas de servicio a servicio. * ** Mejoramiento de la cobertura de prueba:** Mejorar las suites de prueba automatizadas para incluir la evaluación de la expresión File Store a través de las rutas de ejecución de tuberías

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

1. 23 de septiembre de 2026 a las 20:17 UTCinvestigating

   Actualmente estamos investigando problemas de conectividad que afectan a clientes cuyos entornos están protegidos por firewalls de Palo Alto Networks. Estos cortafuegos están bloqueando las conexiones con las API de Harness, lo que puede resultar en: - Ejecuciones de tuberías fallidas - Incapacidad para desplegar aplicaciones - Tiempos intermitentes al acceder a las características de la plataforma Harness - Fallos de integración con herramientas de terceros - Conectividad delegada con plataforma Harness Este problema no es causado por un servicio de Harness, sino por reglas de cortafuegos en su lado de la red. Estamos aconsejando a los clientes que hagan una excepción para nuestros puntos finales de DNS.

2. 24 de septiembre de 2026 a las 8:43 UTCmonitoring

   Mitigation Disponible: Tráfico de daños bloqueado por la política de seguridad de la red Hemos identificado un problema donde algunos clientes pueden ser incapaces de acceder a Harness porque el tráfico Harness está siendo categorizado como "AI-Platform" por los controles de seguridad de la red Palo Alto y posteriormente bloqueado por la política de firewall/INET del cliente. Si usted está experimentando este problema: Póngase en contacto con el equipo de Network/Firewall/CyberSecurity de su organización y solicite que se permita el tráfico de Harness requerido a través de su política de firewall de Palo Alto. Como mitigación, los clientes pueden permitir la categoría de URL "AI-Platform" para los puntos finales requeridos de Harness, o añadir los dominios/FQDN afectados de Harness a la lista aprobada/allow de su organización, de acuerdo con sus políticas de seguridad. Una vez actualizada la política de cortafuegos, debe restablecerse el acceso a Harness. Importante: La política de cortafuegos es gestionada por el equipo de red/seguridad del cliente. Si el punto final de Harness es categorizado incorrectamente por Palo Alto, los clientes también pueden solicitar una revisión de la categoría URL de Palo Alto Networks.

3. 25 de septiembre de 2026 a las 17:10 UTCresolved

   Después de consultar con Palo Alto Networks, podemos confirmar que el 23 de septiembre de 2026, app.harness. io fue categorizado como un Servicio de Plataforma AI por el Equipo de Redes Palo Alto. Palo Alto Networks envió un aviso a los clientes en agosto sobre la reclasificación. This change may place AI Platform Service under a different policy than app.harness. io's previous ruleset categorization, Computer and Internet Info. La política aplicada depende de la configuración del cliente. Los clientes de Harness deben discutir esta categorización y las alertas con su equipo interno de red y Palo Alto Networks.

4. 13 de octubre de 2026 a las 4:50 UTCpostmortem

   .

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

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

   Actualmente estamos investigando esta cuestión.

2. 22 de septiembre de 2026 a las 17:14 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 22 de septiembre de 2026 a las 18:01 UTCmonitoring

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

4. 22 de septiembre de 2026 a las 18:38 UTCresolved

   Este incidente ha sido resuelto.

5. 2 de octubre de 2026 a las 22:05 UTCpostmortem

   # Resumen El 22 de septiembre de 2026, tres de nuestras pasarelas de red en una región se volvieron insalubres y comenzaron a rechazar un pequeño porcentaje de nuevos intentos de conexión. La cuestión se resolvió completamente el mismo problema de día sin más recurrencia o impacto de seguimiento. La causa subyacente fue un amortiguador interno saturado de vigilancia del tráfico en esas pasarelas, lo que causó que sus cheques de salud respondieran demasiado lentamente y quedar marcados insalubres. # Impacto * Sólo tres instancias de puerta de entrada en una región fueron afectadas; otras regiones y otros portales en la misma región no fueron impactados. * No hubo fallos en cascada, el asunto se resolvió completamente con una sola ronda de reiniciamientos de la puerta de entrada, y no hubo problemas posteriores. # Root Cause Nuestras pasarelas de red externas ejecutan un componente interno que monitoriza el tráfico de red para la visibilidad operacional. Bajo un alto tránsito sostenido, el búfer interno de este componente se saturaba, lo que creó la retropresión lo suficientemente severa como para frenar las propias respuestas de control de salud de la puerta más allá del tiempo que nuestro balanceador de carga permite. Una vez superado ese tiempo, el balanceador de carga marcó las pasarelas afectadas insalubres y empezó a rechazar una porción de nuevas conexiones destinadas a ellas. El reenvío real del paquete siguió trabajando normalmente durante todo el incidente. Esto fue específicamente un problema de control de salud y control de amortiguación, no un fracaso de la capacidad de reenvío del núcleo de las gateways. Resolución Las tres instancias de gateway afectadas se reiniciaron manualmente, lo que despejó el amortiguador saturado de monitoreo y el comportamiento normal de comprobación de salud inmediatamente restaurado. Los rechazos a la conexión se detuvieron tan pronto como el reinicio terminó, y no se necesitaba más intervención. Medidas preventivas Silencio** Silencio... Silencio Reemplazar el actual enfoque de vigilancia del tráfico en todas las puertas con una implementación más eficiente y de baja gama que no puede saturar de esta manera, y que alerta bien antes de cualquier impacto visual del cliente. ← TEN Aplicar la sustitución automática y periódica de los casos de gateway de larga duración en un horario fijo, por lo que ningún caso puede acumular el tipo de degradación relacionada con la edad que se observa en este incidente. Silencio TEN Migrate gateway instances to network-optimized infrastructure with substantially more dedicated network capacity, better suited to sustained high-through traffic. TEN ← Mejorar la utilización del búfer de monitoreo existente mientras que el reemplazo a largo plazo se despliega. TEN Enhance alertando específicamente sobre la latencia de la respuesta de la salud de la puerta de entrada, para captar signos tempranos de degradación antes de que se vuelva visible al cliente. Silencio

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

1. 22 de septiembre de 2026 a las 14:00 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

2. 22 de septiembre de 2026 a las 14:08 UTCmonitoring

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

3. 22 de septiembre de 2026 a las 14:20 UTCresolved

   Este incidente ha sido resuelto.

4. 2 de octubre de 2026 a las 22:10 UTCpostmortem

   Igual que la causa raíz anterior.

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

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

   Actualmente estamos investigando esta cuestión.

2. 21 de septiembre de 2026 a las 17:12 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 21 de septiembre de 2026 a las 18:27 UTCmonitoring

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

4. 21 de septiembre de 2026 a las 18:33 UTCresolved

   Este incidente ha sido resuelto.

5. 29 de septiembre de 2026 a las 22:39 UTCpostmortem

   ## Summary El 21 de septiembre de 2026, los clientes en Prod 2 experimentaron degradados y luego en gran medida no disponibles paneles de despliegue durante aproximadamente tres horas. El problema fue causado por un conjunto de consultas analíticas detrás de esos tableros de datos que leían mucho más datos de lo que necesitaban, que agotaban la capacidad de la base de datos que los prestaba. Un reinicio de rodadura del servicio afectado restaurado dashboards totalmente, y la plataforma ha sido estable desde entonces. ## Impacto del cliente Las páginas de panel cargadas lentamente o programadas entre 14:48 y 18:11 UTC. Las grabaciones de ejecución y despliegue de tuberías funcionan en infraestructuras separadas y siguen funcionando normalmente. No se produjo pérdida de datos ni corrupción. ## Root Cause Las consultas del panel de control faltaban un filtro de tiempo en la columna utilizada para dividir la tabla más grande en segmentos semanales, por lo que cada consulta leyó todos los datos históricos en lugar de sólo el período solicitado. La corrección nunca fue afectada: los tableros de control devolvieron los resultados adecuados; sólo la cantidad de datos leídos para producirlos fue excesiva. A medida que el volumen de datos crecía, el costo de las lecturas excedía lo que la base de datos podía servir, y los registros de las consultas fallidas agregaban más carga, por lo que la condición no se despejó hasta que se restableció el servicio. Mitigation * Realizó un reinicio en marcha del servicio afectado, que detuvo el ciclo de reingreso y permitió a la base de datos completar su trabajo pendiente * Latencia confirmada y el uso de la conexión de la base de datos devuelto a niveles normales ## Next Steps Para evitar la recurrencia, Harness: * Agregue el filtro faltante de tiempo a las consultas afectadas del panel de control así que cada lectura sólo el período solicitado * Reemplazar los registros inmediatos con los registros consolidados, retrocesos * Mejorar la detección añadiendo alertas sobre el uso de la conexión de la base de datos y el costo de ejecución por serie

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

1. 18 de septiembre de 2026 a las 15:43 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

2. 18 de septiembre de 2026 a las 15:59 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

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