Historial de interrupciones de Harness

1. September 8, 2026 at 9:52 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. September 8, 2026 at 10:53 PM UTCinvestigating

   Seguimos investigando el problema.

3. September 8, 2026 at 11:31 PM UTCinvestigating

   Seguimos investigando esta cuestión.

4. September 8, 2026 at 11:52 PM UTCidentified

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

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

1. September 5, 2026 at 9:40 AM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. September 5, 2026 at 9:40 AM UTCresolved

   Este incidente ha sido resuelto.

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

1. September 3, 2026 at 10:00 AM UTCinvestigating

   La ejecución de la tubería está atrapada en Prod1. Estamos investigando el tema.

2. September 3, 2026 at 10:28 AM UTCmonitoring

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

3. September 3, 2026 at 11:40 AM UTCresolved

   Este incidente ha sido resuelto.

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

1. August 28, 2026 at 7:04 AM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 28, 2026 at 7:16 AM UTCidentified

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

3. August 28, 2026 at 7:29 AM UTCmonitoring

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

4. August 28, 2026 at 7:35 AM UTCresolved

   Este incidente ha sido resuelto.

5. September 2, 2026 at 10:15 PM UTCpostmortem

   ## Summary Entre el 27 de agosto y el 28 de agosto de 2026, los clientes experimentaron un problema donde algunos oleoductos, despliegues y recursos conexos aparecieron como no encontrados en la interfaz de usuario y API de Harness, aunque los datos subyacentes permanecían intactos. The issue occurred during a planned internal infrastructure update that affected communication between internal platform services. En consecuencia, las solicitudes que dependían de la resolución de la cuenta, la organización y el alcance de los proyectos no pudieron completarse con éxito, lo que dio lugar a que no se encontraran respuestas incorrectas a los clientes de las entidades existentes. La ingeniería identificó el problema, revolvió el cambio, y restauró el servicio normal. No se perdieron ni eliminaron datos de clientes durante el incidente. ## Root Cause El problema fue causado por un error de configuración introducido durante una actualización de enrutamiento de servicio interno prevista en Producción. Un servicio de plataforma interna responsable de resolver el contexto de cuenta, organización y proyecto no pudo validar solicitudes de otros servicios de Harness después de que se aplicara el cambio. Debido a que esa medida de validación es necesaria antes de que muchas entidades lean y puedan continuar las acciones relacionadas con el oleoducto, las solicitudes fallidas surgieron a los clientes como errores no encontrados para los recursos que continuaron existiendo normalmente. La cuestión se limitaba al entorno de producción afectado y se resolvía revertiendo el cambio y restaurando la vía de comunicación de servicios anterior. ## Impacto * Algunos clientes vieron que las tuberías, implementaciones y entidades relacionadas existentes aparecen como no se encuentran en la interfaz de usuario y API. * Algunas operaciones relacionadas con los oleoductos, como la progresión de la ejecución, los inicios con trabas webhook, la evaluación programada de los desencadenantes y la inclusión de entidades, fueron interrumpidas temporalmente. * El problema afectaba la disponibilidad y visibilidad de las entidades existentes, pero no eliminaba los datos ni modificaba las configuraciones del cliente. * No hubo acceso no autorizado, y no se observó pérdida de datos del cliente. ## Remediation * Inmediatamente* Revertí la actualización de la configuración de infraestructura y restauró la ruta de comunicación del servicio de trabajo anterior. * **Recovery validation:** Verificado que las entidades afectadas buscan, las operaciones de oleoductos y las API dependientes funcionaban normalmente después de la reversión. * *Permanente* Corregido el manejo de configuración asociado a la actualización, por lo que problemas similares no interfieren con la autenticación de servicio a servicio en futuros despliegues. ## Action Items Para evitar que estos problemas vuelvan a suceder, Harness lo hará 1. Mejorar la validación de la configuración mejorando las pruebas previas al despliegue para verificar la comunicación de servicios internos antes de cambiar el tráfico de producción. 2. Mejorar la vigilancia y alerta de fallos de autenticación interna para que los problemas puedan detectarse antes. 3. Mejorar el manejo de errores para que los fallos de dependencia sean menos propensos a aparecer a los clientes como recurso no encontrado errores.

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

1. August 26, 2026 at 8:38 AM UTCinvestigating

   Actualmente estamos investigando un problema reportado en los oleoductos IACM en los grupos de arnés Prod-1, Prod-2,Prod-4 y EU1.

2. August 26, 2026 at 8:43 AM UTCinvestigating

   Seguimos investigando esta cuestión.

3. August 26, 2026 at 9:05 AM UTCmonitoring

   Hemos revertido el cambio que causó esta cuestión en todos los grupos.

4. August 26, 2026 at 9:10 AM UTCresolved

   Este incidente ha sido resuelto.

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

1. August 24, 2026 at 12:57 AM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 24, 2026 at 1:01 AM UTCinvestigating

   Actualmente estamos investigando informes de que la interfaz de usuario de Gestión de Característica " Experimentación (FME) no está cargando. Los clientes que intentan acceder a la consola FME pueden encontrar errores o páginas sin respuesta. No se cree que la evaluación de la bandera característica y el tráfico SDK se vean afectados. Pronto se hará una nueva actualización.

3. August 24, 2026 at 1:08 AM UTCmonitoring

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

4. August 24, 2026 at 1:12 AM UTCresolved

   Este incidente ha sido resuelto.

5. August 27, 2026 at 11:36 PM UTCpostmortem

   ## Summary * A partir de **23:42 UTC** el 23 de agosto de 2026, varios clientes de FME informaron de fallos cargando la ITU FME. * FME UI Artifacts served from the CDN expired due to a retention policy, causing FME UI to fail to load. * Cualquier solicitud de bandera cambia a través de la API, la entrega de cambios y el oleoducto de datos continuó trabajando sin interrupción. ## Root Cause * La UI FME es servida por un CDN. Los artefactos de la UI fueron desalojados debido a una política de retención, causando que la UI no se cargara para todos los usuarios. ## Impacto * El FME UI no pudo cargar para todos los usuarios en todos los entornos de producción. ### ¿Qué no fue impactado? * Función SDK y evaluación de la bandera de tiempo de ejecución * Admin API llamadas * Datos de configuración de la bandera cliente * No se produjo pérdida de datos ## Remediation * FME UI fue restaurado en el CDN a través de un despliegue * Recuperación confirmada en todos los entornos de producción antes de cerrar el incidente. ## Action Items * Mejorar la política de retención de activos para que la versión actual no esté sujeta a desalojo.

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

1. August 20, 2026 at 3:37 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 20, 2026 at 4:05 PM UTCinvestigating

   La lentitud podría causar cualquiera de los síntomas siguientes: - Las tuberías no comienzan - Delays in execution - Se cancelan las tuberías debido a los plazos

3. August 20, 2026 at 4:22 PM UTCinvestigating

   Nuestro proveedor de nube está enfrentando un incidente activo y estamos siguiendo.

4. August 20, 2026 at 4:32 PM UTCinvestigating

   Seguimos investigando esta cuestión.

5. August 20, 2026 at 4:50 PM UTCidentified

   Nuestro proveedor de nube ha confirmado un incidente en curso que impacta a múltiples regiones. Los oleoductos no han experimentado fallos como resultado, aunque algunos usuarios pueden seguir experimentando lentitud. Estamos monitoreando la situación de cerca y proporcionaremos actualizaciones a medida que se disponga de más información.

6. August 20, 2026 at 5:17 PM UTCmonitoring

   Estamos observando mejores retrasos en todo el tablero después de la solución implementada por nuestro proveedor de nube. Seguimos vigilando de cerca la situación y proporcionaremos nuevas actualizaciones según lo justificado. Hemos observado algunas ejecuciones atascadas para CI para un par de clientes, que estamos investigando

7. August 20, 2026 at 7:23 PM UTCresolved

   Este incidente ha sido resuelto.

8. August 26, 2026 at 4:57 AM UTCpostmortem

   # Resumen El 20 de agosto de 2026, a partir de aproximadamente las 15.00 horas, la plataforma Harness experimentó una degradación generalizada del rendimiento en todos los entornos de producción. Las ejecuciones de tuberías que normalmente terminan en unos dos minutos tardaron de siete a diez minutos. Continuous Delivery, Continuous Integration, orquestation and Feature Management & Experimentation fueron todos afectados. Google Cloud Platform experimentó un incidente multiproducto en la región us-west1 que afecta a Bigtable, Compute Engine, Google Kubernetes Engine, y la infraestructura de producción de disco persistente I/O. La Harness se ejecuta en discos persistentes en esa región. La degradación aumentó latencia de funcionamiento de la base de datos de aproximadamente 2 ms a más de 10 ms en el percentil 95, que a su vez causó retrasos en el procesamiento de mensajes y se propagaron a cada servicio que depende del acceso oportuno a la base de datos. # Impacto Esto era una degradación, no un outage. Las tuberías continuaron ejecutando y completando con éxito en todo; eran lentas en lugar de fallar. No se perdieron datos, y no se redujo el trabajo del cliente como resultado de este incidente. # Causa real # La infraestructura de producción de daños en los entornos afectados se ejecuta en discos persistentes de Google Cloud Platform en la región nosotros-oeste1. Cuando esa capa de almacenamiento se degrada, el efecto se propaga a través de la plataforma en una cadena predecible: **Persistent-disk I/O degradation in us-west1.** Google Cloud Platform experimentó un incidente multiproducto que afecta a Bigtable, Compute Engine, Google Kubernetes Engine, y el rendimiento de disco persistente. Esto fue un fallo de infraestructura en el entorno del proveedor, fuera del control de Harness. * Acciones preventivas* Aunque Harness no puede prevenir un fallo de infraestructura de proveedores de nube. Las acciones a continuación están dirigidas a detectar uno más rápido y estar mejor posicionado para actuar en él. Silencio** Silencio... TEN Seguir pre-pruebando rutinariamente las deficiencias de la base de datos de registro cruzado selectiva, como se realiza durante este incidente, para mantener la disponibilidad de failover verificada en lugar de asumir TEN ← Evaluar la disponibilidad total de la lista multiregión para futuros escenarios en los que la latencia de la región sería inaceptable

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

1. August 20, 2026 at 2:32 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 20, 2026 at 2:47 PM UTCidentified

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

3. August 20, 2026 at 2:56 PM UTCmonitoring

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

4. August 20, 2026 at 3:02 PM UTCresolved

   Este incidente ha sido resuelto.

5. August 23, 2026 at 9:45 PM UTCpostmortem

   #### Summary El 20 de agosto de 2026, entre 10:24 y 14:55 UTC, un subconjunto de FME escribe fracasado. Los escritos hechos de la FME UI y escritos hechos con Harness tokens \(PATs y SATs\) no fueron afectados. La evaluación de la bandera de ejecución siguió funcionando normalmente. La cuestión fue mitigada al revertir un cambio reciente de autenticación en un servicio de gobernanza compartido, y los escritos afectados devueltos a la normalidad por 14:55 UTC. Estado: [https://status.harness.io/incidents/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz) ## Root Cause Un cambio en la forma en que un servicio de gobernanza compartido autentificó las llamadas entrantes dio lugar a que algunos escritos de FME fueran rechazados. Esos escritos utilizan credenciales de servicio a servicio que el servicio de gobernanza ya no podía verificar después del cambio. FME supera un fallo de gobernanza del cliente como HTTP 499, el mismo estado utilizado cuando una política de gobernanza niega intencionalmente un cambio. Debido a que 499 es una respuesta válida y esperada en ese camino de negación, los fallos no parecían un outage en nuestras alertas, y el incidente fue identificado de informes de clientes en lugar de detección interna. ## Impacto * Un subconjunto de FME escribe que falló durante la ventana, principalmente los que se hicieron usando claves de Split API heredadas o la programación de solicitudes de cambio. * Los escritos hechos de la ITU FME no fueron impactados. * No se impactaron los escritos usando tokens de acceso a Harness \(PATs y SATs\). * La evaluación de la bandera del tiempo de ejecución continuó normalmente. * No se produjo pérdida de datos. Los escritos fallidos no se aplicaron. ## Remediation Revertir el cambio de autenticación de los servicios de gobernanza. Los escritos afectados vuelven a la normalidad inmediatamente. ### Action Items Para evitar que esas cuestiones vuelvan a suceder, * Harness devolverá un error distinto \(no 499\) cuando un escrito falla porque la gobernanza no se pudo evaluar, por lo que no se confunde con una negación de política intencional. * Agregar alerta sobre la evaluación de la gobernanza se llama a sí mismo, en lugar de depender del código de estado que se ocupa del cliente. * Ampliar el apoyo de autenticación para las evaluaciones de políticas. * Ampliar cobertura automatizada para escenarios de escritura adicionales.

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

1. August 19, 2026 at 1:22 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 19, 2026 at 2:55 PM UTCinvestigating

   Seguimos investigando esta cuestión.

3. August 19, 2026 at 3:13 PM UTCidentified

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

4. August 19, 2026 at 3:22 PM UTCmonitoring

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

5. August 19, 2026 at 3:33 PM UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

6. August 19, 2026 at 4:07 PM UTCresolved

   Este incidente ha sido resuelto.

7. August 26, 2026 at 5:20 PM UTCpostmortem

   **Summary** El 19 de agosto de 2026 entre las 12:35 y las 17:29 UTC, el servicio Harness Application Security experimentó una perturbación significativa que afecta tanto a la consola de atención al cliente como al gasoducto de ingestión de datos en las regiones de SaaS Production y US1. *Causa real* El servicio de configuración interna que proporciona ajustes de tiempo de ejecución a casi todos los componentes se sobrecargaron y entró en un ciclo de reinicio repetido. Debido a que muchos servicios dependen de ella, los efectos fueron amplios: páginas de consola tales como políticas de protección, vistas a la postura, registros de actividad, inventario de API y política personalizada no se cargaron o se agotaron, y el procesamiento de aguas abajo se estancó mientras esperaba la configuración que no podía obtener. * Impacto del cliente* Silencio ** Dimensión** Silencio... Ø Consola \(UI\) Impacto Silencio Múltiples páginas no se cargaron ni programaron, incluyendo políticas de protección, páginas de eventos de postura y vistas de postura dentro de paneles y páginas de información, consultas de registro de actividades, pantallas de inventario de API, políticas personalizadas y puntos de vista y widgets de datos sensibles. Silencio El impacto de la ingestión TENENCIA El procesamiento de la telemetría de seguridad se degrada severamente y, en algunos caminos, se detiene por completo. El lag de consumo creció a través de la normalización, agrupación, detección de anomalías, generación y fases de procesamiento relacionadas. Silencio Silencio Perder datos TENIDO Un subconjunto de telemetría ingerido durante la interrupción fue eliminado permanentemente. Silencio **Mitigación** Varias atenuaciones intermedias adicionales de CPU y memoria, umbrales de control de salud relajados, reiniciar una base de datos y una piscina de conexión más grande amelioró el problema. Disabling the new feature in both affected regions restored throughput sharply and durably. El incidente fue resuelto a las 17:29 UTC. * Acciones preventivas* Las siguientes medidas se cometen y siguen internamente hasta su finalización. La característica que provocó este incidente sigue siendo desactivada y no se podrá volver a habilitar hasta que el trabajo que sigue sea completo y validado. Silencio** Silencio... Silencio tención Optimice el código ajustando parámetros tales como el desalojo de caché y la retención, evalúe la paginación basada en cursor para la recuperación de reglas a granel, ya que los recuentos de reglas crecen Silencio Añadir un índice de base de datos diseñado para el patrón de acceso a los servicios ← Remediar la recuperación del oleoducto semántica para que los consumidores vuelvan a jugar con seguridad después de la pérdida del marcador de posición en lugar de saltar atraso ← Mandate escenifica la puesta en marcha para las anulas de configuración que alteran los patrones de solicitud de aguas abajo: agrupación de bajo volumen, luego de volumen medio, luego de volumen alto TEN Add backpressure and concurrency protection to the settings service: circuit breaking, bounded queues, and timeout isolation TEN tención Enhance observabilidad por Instrumentación de métricas más detalladas

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

1. August 6, 2026 at 2:30 PM UTCinvestigating

   We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.

2. August 6, 2026 at 2:32 PM UTCinvestigating

   We are continuing to investigate this issue.

3. August 6, 2026 at 3:46 PM UTCidentified

   The issue has been identified and a fix is being implemented.

4. August 6, 2026 at 4:01 PM UTCresolved

   This incident has been resolved.

5. August 10, 2026 at 6:24 PM UTCpostmortem

   ## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.

1. August 6, 2026 at 1:50 PM UTCmonitoring

   Estamos monitoreando las tuberías en prod2. Las nuevas ejecuciones están pasando ya que estamos monitoreando continuamente los servicios.

2. August 6, 2026 at 4:58 PM UTCmonitoring

   Estamos monitoreando las tuberías en prod2. Para los clientes que todavía están viendo tuberías atascadas, le solicitamos abortar y re-trigger.

3. August 6, 2026 at 6:21 PM UTCresolved

   Este incidente ha sido resuelto.

4. August 17, 2026 at 6:40 PM UTCpostmortem

   ## **Summary** El 6 de agosto de 2026 \(mañana PDT\), algunos clientes que ejecutan oleoductos en el entorno de producción Prod2 observaron ejecuciones de oleoductos que dejaron de progresar, etapas que no avanzaron y no produjeron más actualizaciones de salida o estado. El problema fue reportado por clientes afectados. Los ingenieros de daños identificaron la causa, mitigaron el impacto y las ejecuciones de oleoductos regresaron a una operación normal. La cuestión fue causada por una expresión de oleoducto autoreferencial. Un Webhook Git activaba un oleoducto que hacía referencia al contenido de la carga útil webhook, y la carga útil contenía más copias de esa misma expresión. Por lo tanto, cada ronda de resolución de expresión produjo más expresiones para resolver, duplicando la cantidad de trabajo cada vez. Esto agotó los recursos de la instancia de servicio procesando que la ejecución, y otras ejecuciones asignadas a la misma instancia no pudieron progresar mientras estaba en ese estado. ### **Impact** Durante la ventana del incidente \(aproximadamente 6:11 AM a 11:23 AM PDT el 6 de agosto de 2026\): * Las ejecuciones de oleoductos de algunos clientes en Prod2 se suspendieron a mitad de ejecución y no lograron ningún progreso adicional. * Las ejecuciones afectadas no produjeron nuevas actualizaciones de la salida o el estado del paso, y tuvieron que ser abortadas y repetidas después de la mitigación. * El comportamiento se limitó a las ejecuciones procesadas por la instancia de servicio afectada; los oleoductos manejados por otros casos siguieron ejecutando normalmente. No hubo pérdida de datos**. Definiciones de tuberías, historia de ejecución y estado almacenado no fueron afectados. La mayoría de los oleoductos en Prod2 continuaron ejecutando con éxito durante todo el incidente; el impacto principal fue que algunas ejecuciones en vuelo no pudieron completarse y debían ser repetidas una vez que se mitigó la cuestión. ## ## Root Cause ## Los oleoductos de tracción soportan expresiones que se resuelven en tiempo de ejecución, por ejemplo, una expresión que inserta el contenido de la carga útil Git webhook que provocó el oleoducto. En este caso, un mensaje de Git commit contenía el texto literal de la expresión de payload en sí, dos veces, y el oleoducto hizo referencia a esa misma expresión de payload. Debido a que el mensaje de confirmación es parte de la carga útil webhook, la resolución de la expresión insertó toda la carga útil, incluyendo las dos copias literales de la expresión llevada en el mensaje de confirmación. Esas copias insertadas recientemente fueron tratadas como expresiones que se resolverían, y cada pase insertó dos copias más completas de la carga útil. El tamaño del valor que se procesa, y el trabajo requerido para procesarlo, por lo tanto se duplicó en cada paso y creció exponencialmente en lugar de converger. La corrupción tiene una salvaguardia destinada a detener exactamente esto: la resolución de la expresión está ligada por una profundidad máxima de anidación, más allá de la cual la resolución se detiene y el oleoducto falla con un error explícito. Un defecto en esa salvaguardia significaba que el límite no se aplicaba en este caso concreto de auto-referencia, por lo que la resolución seguía sin verificar. La resolución de la expresión funciona inline en los hilos que comienzan los pasos de tubería. A medida que cada paso consumía progresivamente más memoria y CPU sin haber completado nunca, la instancia de servicio que realizaba ese trabajo dejó de progresar, y cada ejecución asignada a ese caso quedó estancada, que es lo que informaron los clientes. ## **Mitigation** Harness completó las siguientes medidas inmediatas de mitigación: * Identifica el oleoducto y el patrón de expresión responsable de la resolución de fuga. * Stopped the affected service instance so that it would take on no further work. Los casos sanos restantes se recogieron y procesaron las ejecuciones expuestas normalmente. * Confirmó que las ejecuciones de oleoductos regresaron a la normalidad y cerraron el incidente. Estas acciones restauraron el comportamiento normal de ejecución del oleoducto y resolvieron el impacto del cliente. ## **Action Items** Para reducir el riesgo de recurrencia y mejorar la detección, se están aplicando las siguientes medidas: * Arreglar el defecto en la profundidad de expresión y salvaguardia de la detección para que las expresiones auto-referenciales sean capturadas y fallen rápidamente con un error claro en lugar de consumir recursos sin límites. * Evitar que las expresiones de carga útil se resuelvan con el contenido de la carga útil del disparador, eliminando completamente el camino autoreferencial. * Incrementar la máxima expresión anidando profundidad y evaluar la detección explícita del bucle además del límite de profundidad existente. * Mejorar las pruebas automatizadas en entornos preproducción que reproducen patrones de expresión autoreferenciales y verificar que la salvaguardia los detecta y detiene. * Agregue monitoreo para este patrón en las ejecuciones de oleoductos para que se detecte proactivamente.

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

1. August 4, 2026 at 12:07 PM UTCinvestigating

   We are currently investigating this issue.

2. August 4, 2026 at 12:17 PM UTCinvestigating

   We are continuing to investigate this issue.

3. August 4, 2026 at 1:00 PM UTCinvestigating

   We have identified the issue and started to implement the fix , prod2 is restored.

4. August 4, 2026 at 1:09 PM UTCinvestigating

   We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.

5. August 4, 2026 at 1:16 PM UTCinvestigating

   We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.

6. August 4, 2026 at 3:28 PM UTCresolved

   This incident has been resolved.

7. August 6, 2026 at 5:02 PM UTCpostmortem

   # Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.

1. August 3, 2026 at 3:08 AM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 3, 2026 at 3:37 AM UTCmonitoring

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

3. August 3, 2026 at 5:53 AM UTCresolved

   Este incidente ha sido resuelto.

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

1. July 31, 2026 at 8:22 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 1, 2026 at 2:41 AM UTCidentified

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

3. August 1, 2026 at 5:45 AM UTCmonitoring

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

4. August 1, 2026 at 9:11 AM UTCresolved

   Este incidente ha sido resuelto.

5. August 21, 2026 at 4:19 AM UTCpostmortem

   *Summary* Entre el 25 de julio y el 4 de agosto de 2026, los paneles de ejecución de oleoductos y las páginas de visión general en los grupos Harness Prod 2 y Prod 3 mostraron datos que estaban entre detrás del tiempo real. Los propios pipelines continuaron construyendo, desplegando y ejecutando normalmente a lo largo de todo; la cuestión se limitó a la rapidez con que se copiaban los registros de ejecución en la base de datos que sirve para presentar informes y obtener puntos de vista. **No se perdieron datos de clientes.** Cada registro afectado se mantuvo almacenado duramente y fue reproducido en la tienda de datos analíticos una vez que se removió la limitación subyacente. Harness migraó los grupos afectados a una versión horizontalmente escalable y respaldada por la cola del componente de replicación el 1 de agosto de 2026 y completó los backfills de datos específicos para todas las cuentas afectadas. # Causa real # Harness mantiene un componente de captura de datos de cambio que reproduce continuamente los registros de ejecución de oleoductos de la tienda de datos operacional primaria en una tienda de datos de series temporales separadas optimizada para tableros de datos y consultas de presentación de informes. Los paneles leen exclusivamente desde la tienda de datos de análisis. Cuando la replicación cae detrás, los tableros dan una visión exacta pero antigua del mundo, mientras que la ejecución misma no es afectada. Esto fue causado por un aumento pronunciado y sostenido del volumen de escritura de base de datos de otro módulo de plataforma de Harness que compartía la misma ruta de replicación superó el límite máximo de rendimiento de la versión anterior de una sola posición de ese componente que todavía funciona en el Prod 2 y Prod 3. Se formó un atraso y creció. * Acciones preventivas* Harness ha completado o comprometido las siguientes acciones para prevenir tales problemas. Silencio** Silencio... TEN Fine sintonizar la repetición lag alerting para que cualquier retraso más allá de un umbral definido sea notificado TEN tención Añadir un panel de lag de replicación a la tabla de monitoreo de plataformas estándar para que la salud de los oleoductos sea visible por defecto tención Reducir la amplificación de escritura de los módulos de co-tenant a través de la limitación de tarifas por módulo o filtración de entidad en el flujo de replicación

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

1. July 31, 2026 at 1:48 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. August 1, 2026 at 2:34 AM UTCidentified

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

3. August 1, 2026 at 2:44 AM UTCmonitoring

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

4. August 1, 2026 at 11:49 PM UTCresolved

   Este incidente ha sido resuelto.

5. August 13, 2026 at 12:50 AM UTCpostmortem

   # **Summary** On July 31, 2026, artifact uploads performed through pipeline in the EU1 cluster began failing with an authentication error. Uploads initiated manually \(outside of a pipeline\) were not affected, and the ability to retrieve existing artifacts \(downloads\) was also unaffected — this was isolated to the specific pipeline upload path in one cluster. # **Impact** * Artifact uploads performed through pipeline in the EU1 cluster failed with an authentication error for approximately 4 hours and 34 minutes. * Retrieving existing artifacts \(downloads\) was not affected. * Manually uploading artifacts outside of a pipeline was not affected. * Other clusters/regions were not affected by this issue. # **Root Cause** The component responsible for handling pipeline-based artifact uploads is distributed as a container image. In the EU1 cluster, this image is retrieved from an internal registry that mirrors a public image source; in other clusters, the same image is retrieved directly from the public source. A publishing error in our release process caused a new build of this component to be published using a version label that was already in use, rather than being assigned a new, unique version. As a result, two different images ended up associated with the same version label in the public source. Our internal registry mirrors images from the public source via an automated replication process. Because of how that replication was triggered, it copied the original \(earlier\) image associated with that version label rather than the corrected one. This meant the EU1 cluster — which pulls from the internal mirror — ended up running a different, defective image than other clusters, which pull directly from the public source and therefore received the corrected image. The defective image contained an authentication issue that caused pipeline uploads to fail. # **Mitigation** * Reverted the affected account to the last known-good version of the upload component, immediately restoring pipeline uploads. * Published a corrected, permanent version of the component to resolve the issue across all clusters. # **Next steps** ‌ * Fix the upload step to remove the underlying container-related defect that made this failure mode possible. * Update our release pipeline for this component so that publishing an image can never overwrite an existing version — every publish must create a new, distinct version going forward.

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

1. July 30, 2026 at 5:59 AM UTCinvestigating

   Resumen - Nos enfrentamos intermitentemente a problemas de conectividad de red con nuestro Build VM no puede conectarse a recursos externos. Actualmente estamos investigando la cuestión.

2. July 30, 2026 at 8:07 AM UTCmonitoring

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

3. July 30, 2026 at 8:07 AM UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

4. July 31, 2026 at 3:22 AM UTCresolved

   Este incidente ha sido resuelto.

5. August 7, 2026 at 7:32 PM UTCpostmortem

   ## Summary Starting on August 4, 2026, CI runners in the us-west1 and us-central1 regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services such as GitHub and Bitbucket over outbound network gateways. ## Impact * CI runners in the affected regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services \(e.g., GitHub, Bitbucket\) over our outbound network gateways. * The issue was intermittent rather than constant — connections succeeded under normal load, and failures clustered during periods of high outbound traffic volume. * No data was lost or corrupted. This was a network-connectivity and capacity issue, not a data-integrity issue. * us-west1 and us-central1 were the affected regions; other regions were not impacted by this issue. ## Root Cause ‌ Our load balancer distributes outbound traffic across multiple NAT gateways using a hashing method based on connection details \(source/destination address and port\). For any single connection, these details stay constant for that connection's lifetime. We had a sustainted traffic surge for a few seconds which congested the gateways ‌ ## Action Items To prevent such issues from happening again Harness will, Increase outbound connection capacity on our NAT gateways by provisioning additional external network interfaces, giving each gateway a substantially larger pool of connections it can serve concurrently..

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

1. July 27, 2026 at 9:09 AM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. July 27, 2026 at 9:22 AM UTCmonitoring

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

3. July 27, 2026 at 1:33 PM UTCresolved

   Este incidente ha sido resuelto.

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

1. July 27, 2026 at 7:52 AM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. July 27, 2026 at 8:13 AM UTCinvestigating

   Seguimos investigando esta cuestión.

3. July 27, 2026 at 9:04 AM UTCidentified

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

4. July 27, 2026 at 9:05 AM UTCidentified

   Seguimos trabajando para solucionar este problema.

5. July 27, 2026 at 9:07 AM UTCmonitoring

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

6. July 27, 2026 at 9:09 AM UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

7. July 27, 2026 at 1:33 PM UTCresolved

   Este incidente ha sido resuelto.

8. August 7, 2026 at 6:15 PM UTCpostmortem

   # Summary During a recent production deployment, a defect in our internal deployment tooling caused two critical services   to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI. ‌ We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom. ‌ At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing. # Incident Details ## Incorrect Production Configuration Values Applied Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration. ‌ **Root Cause** ‌ The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves. ‌ **Resolution** ‌ Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline. ## Intermittent Login / Access Failures During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window. ## Filestore Access Issue A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment. **Root Cause** This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity.  ## Delayed Pipeline Execution Status Updates in UI Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue. **Root Cause** The pipeline execution graph relies on a message stream \(the orchestration log\) to receive status updates. During the incident window, consumer processing of this stream fell behind \(high consumer lag\), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally. **Resolution** We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform. # Impact Summary * Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments. * Some users experienced intermittent login or access failures during the affected deployment window. * One customer environment in Prod-3 experienced a filestore access issue. * Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted. # Preventive Actions The following corrective and preventive actions have been identified. ‌ | **Corrective / Preventive Action** | | --- | | Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. | | Add safeguards so that a service which cannot retrieve its configuration fails safely \(e.g. alerts and blocks the deployment\) rather than silently falling back to non-production defaults. | | Increase Postgres and messaging-pipeline resource headroom \(target: greater than 50% spare capacity\) to reduce sensitivity to concurrent load and scaling events. | ‌ _We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution._

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

1. July 22, 2026 at 2:55 PM UTCinvestigating

   Estamos investigando un problema que afecta a los paneles AIDI. Los usuarios pueden experimentar mayores tiempos de carga o fallos intermitentes al acceder a los paneles. Nuestro equipo está trabajando activamente para identificar la causa raíz y restaurar el rendimiento normal. Proporcionaremos actualizaciones a medida que se disponga de más información.

2. July 22, 2026 at 2:58 PM UTCidentified

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

3. July 22, 2026 at 3:25 PM UTCmonitoring

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

4. July 22, 2026 at 11:16 PM UTCresolved

   Este incidente ha sido resuelto.

5. August 10, 2026 at 6:17 PM UTCpostmortem

   ## Summary Los clientes del Prod1, Prod2, y los grupos Prod3 experimentaron fallos de carga intermitente de widgets y tiempos de carga aumentados al acceder a los paneles AIDI 2.0 el 22 de julio de 2026. No todos los widgets se vieron afectados simultáneamente el problema se manifestó como fallas esporádicas en lugar de un outage completo. No se perdieron datos de clientes. Los clientes SEI 1.0 no fueron afectados. ## Root Cause Con el tiempo, un proceso rutinario de mantenimiento de bases de datos no funcionó en ciertas tablas de nuestra base de datos de análisis, causando que esas tablas acumularan un gran volumen de metadatos internos utilizados para rastrear los registros eliminados. Cuando la base de datos planificaba consultas contra estas tablas, cargaba todos estos metadatos acumulados en memoria, haciendo que el uso de memoria en los nodos afectados aumentara repetidamente. Estos picos repetidos desencadenaron un mecanismo de seguridad automático que reinicia un nodo cuando detecta una presión excesiva de memoria, y los nodos afectados comenzaron a reiniciar en un bucle como resultado. Esto causó el desempeño intermitente y degradado de la consulta en los paneles AIDI 2.0 durante el período del incidente. ## Impacto Los clientes de Prod1, Prod2, y Prod3 clusters pueden haber experimentado fallos de carga intermitente de widget o mayor tiempo de carga en paneles AIDI 2.0. **Duración:** 22 de julio de 2026, 07:58 PDT – 16:16 PDT \(~8 horas 18 minutos\), con fallos de widget intermitente; el sistema fue reiniciado y bajo monitoreo activo desde 08:25 PDT en adelante. ### ¿Qué no fue impactado? * Ingestión y procesamiento de datos * Clientes SEI 1.0 * Integración y flujos de metadatos No se perdieron datos de clientes. ## Remediation Al identificar el problema, los nodos de base de datos afectados se reiniciaron a las 08:25 PDT, que restablecieron la estabilidad inicial. Seguimos monitoreando el sistema de cerca, y cuando la degradación intermitente aún se observaba después, aplicamos varias correcciones adicionales: * Ajustes ajustados de configuración de bases de datos para limitar la cantidad de memoria utilizada para el procesamiento de metadatos acumulados, y ajustes de planificación de consultas ajustados para reducir la presión de memoria. * Trabajos de limpieza para reducir el atraso de metadatos acumulados en las tablas afectadas. * Aumento de la capacidad de los nodos de la base de datos afectados para proporcionar un espacio adicional. Estos cambios estabilizaron progresivamente el sistema, y el incidente se resolvió completamente en 16:16 PDT. ## Action Items Para evitar la recurrencia, estamos implementando lo siguiente: 1. Hemos mejorado el backend que incluye mejoras subyacentes que manejan los picos de memoria causados por archivos borrados excesivos. 2. Hemos implementado trabajos de compactación automatizada para tablas recién introducidas para evitar que la acumulación de archivos borrados avance.

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

1. July 17, 2026 at 5:16 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. July 17, 2026 at 5:34 PM UTCidentified

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

3. July 17, 2026 at 6:12 PM UTCmonitoring

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

4. July 17, 2026 at 9:56 PM UTCresolved

   Este incidente ha sido resuelto.

5. August 4, 2026 at 2:48 AM UTCpostmortem

   # Resumen El 17 de julio de 2026, tras un despliegue de códigos de rutina, los clientes de versiones anteriores de delegado \(858xxx y abajo\) comenzaron a experimentar retrasos en las obras de CI en Harness Cloud utilizando nuestra capacidad global de construcción. Las construcciones afectadas experimentaron una pausa inesperada de hasta 8 minutos aproximadamente en la etapa "esperando la infraestructura" antes de continuar, en lugar de proceder dentro de la subsegunda hora prevista. La lentitud total de la construcción era intermitente. # Impacto * Todas las construcciones de la CI fueron potencialmente sujetas a demoras; el impacto fue más pronunciado para construir sobre la infraestructura hospeda de Harness Cloud utilizando la característica de construcción global. * Los edificios afectados experimentaron una pausa inexplicable de hasta unos 8 minutos antes de continuar, seguido de un "comienzo frío" más lento ya que no se disponía de una ranura de cálculo pre-reservido, esto se presenta a los usuarios como construcciones lentas en lugar de crear fallas. * Las cuentas que se ejecutan en versiones de delegado más recientes \(858xx y arriba\) no fueron impactadas. * No builds falló abiertamente como resultado directo de esta cuestión, y no se perdieron datos. # Root Cause La causa raíz fue un cambio de código interno que rompió inadvertidamente cómo un registro específico de construcción fue leído de nuevo desde nuestra base de datos una vez construidos que ya habían sido consultados bajo la versión anterior del código encontrado la versión recién desplegada. Resolvimos el impacto inmediato al limpiar los registros afectados y revertir el cambio de código subyacente, y estamos implementando varias salvaguardias para evitar que esta clase de problema vuelva a ocurrir. # Next Steps Evaluamos el riesgo de una recurrencia similar tan baja como las siguientes acciones están siendo tomadas. El camino de código específico que causó este incidente ya ha sido revertido, y estamos implementando salvaguardias estructurales para que esta clase general de problema no pueda repetirse, independientemente de dónde en la base de código podría ocurrir de otra manera. Silencio ** Acción correctiva / preventiva** Silencio... Silencio Añadir identificadores explícitos y estables a todas las clases de datos internas que se almacenan en nuestra base de datos, de modo que las reorganizaciones de código interno futuras no pueden romper la capacidad del sistema para leer los registros almacenados previamente. Silencio Ø Introducción de retroceso y pruebas de compatibilidad atrasada en nuestro entorno de preproducción, específicamente diseñado para capturar esta clase de problema antes de que llegue a la producción. Silencio

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