82 Split incidents · April 2026 — official updates, affected components, duration and resolution details.
Actualmente estamos investigando esta cuestión.
Este incidente ha sido resuelto.
Traducido automáticamente desde la actualización oficial del incidente.
La ejecución de la tubería está atrapada en Prod1. Estamos investigando el tema.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
## 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.
Actualmente estamos investigando un problema reportado en los oleoductos IACM en los grupos de arnés Prod-1, Prod-2,Prod-4 y EU1.
Seguimos investigando esta cuestión.
Hemos revertido el cambio que causó esta cuestión en todos los grupos.
Este incidente ha sido resuelto.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos investigando esta cuestión.
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.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
## 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.
Actualmente estamos investigando esta cuestión.
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
Nuestro proveedor de nube está enfrentando un incidente activo y estamos siguiendo.
Seguimos investigando esta cuestión.
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.
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
Este incidente ha sido resuelto.
# 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.
Actualmente estamos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
#### 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.
Actualmente estamos investigando esta cuestión.
Seguimos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Continuamos monitoreando cualquier otro problema.
Este incidente ha sido resuelto.
**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.
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.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## 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.
Estamos monitoreando las tuberías en prod2. Las nuevas ejecuciones están pasando ya que estamos monitoreando continuamente los servicios.
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.
Este incidente ha sido resuelto.
## **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.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# 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.
Actualmente estamos investigando esta cuestión.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
*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.
Actualmente estamos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
*Summary* El 31 de julio de 2026, las subidas de artefactos realizadas a través del oleoducto en el clúster de la UE1 comenzaron a fallar con un error de autenticación. Las descargas iniciadas manualmente \ (fuera de un oleoducto\) no se vieron afectadas, y la capacidad de recuperar los artefactos existentes \(descargas\) también se vio afectada — esto se aisló a la ruta de carga del oleoducto específica en un grupo. # Impact** * Las subidas de artefactos realizadas a través del oleoducto en el cluster EU1 fallaron con un error de autenticación durante aproximadamente 4 horas y 34 minutos. * Recuperar los artefactos existentes \(descargas\) no fue afectado. * No se vio afectada la carga manual de artefactos fuera de un oleoducto. * Otros grupos/regiones no se vieron afectados por esta cuestión. # Root Cause # El componente responsable de la manipulación de cargas de artefactos basados en oleoductos se distribuye como imagen de contenedor. En el cúmulo de la UE1, esta imagen se recupera de un registro interno que refleja una fuente de imagen pública; en otros cúmulos, la misma imagen se recupera directamente de la fuente pública. Un error de publicación en nuestro proceso de publicación causó que una nueva construcción de este componente se publicara utilizando una etiqueta de versión que ya estaba en uso, en lugar de ser asignada una nueva versión única. Como resultado, dos imágenes diferentes terminaron asociadas con la misma etiqueta de versión en la fuente pública. Nuestro registro interno refleja imágenes de la fuente pública a través de un proceso de replicación automatizado. Debido a cómo se activaba esa replicación, copiaba la imagen original \(aprendrina\) asociada con esa etiqueta de la versión en lugar de la correcta. Esto significaba que el clúster de la UE1 —que sale del espejo interno— terminó ejecutando una imagen diferente y defectuosa que otros cúmulos, que sacan directamente de la fuente pública y por lo tanto recibieron la imagen corregida. La imagen defectuosa contenía un problema de autenticación que causó que fallaran las cargas de tuberías. *Mitigation* * Revertí la cuenta afectada a la última versión conocida-buena del componente de carga, restaurando inmediatamente cargas de tuberías. * Publicado una versión corregida y permanente del componente para resolver el problema en todos los grupos. # **Siguientes pasos** * Fijar el paso de carga para eliminar el defecto relacionado con los contenedores subyacentes que hizo posible este modo de fallo. * Actualice nuestro oleoducto de liberación para este componente para que la publicación de una imagen nunca pueda sobreescribir una versión existente; cada publicación debe crear una versión nueva y distinta.
Traducido automáticamente desde la actualización oficial del incidente.
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.
Se ha aplicado una solución y estamos monitoreando los resultados.
Continuamos monitoreando cualquier otro problema.
Este incidente ha sido resuelto.
## 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.
Actualmente estamos investigando esta cuestión.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos investigando esta cuestión.
Seguimos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Seguimos trabajando para solucionar este problema.
Se ha aplicado una solución y estamos monitoreando los resultados.
Continuamos monitoreando cualquier otro problema.
Este incidente ha sido resuelto.
# Resumen Durante un reciente despliegue de producción, un defecto en nuestra herramienta de despliegue interno causó dos servicios críticos para funcionar con valores incorrectos de configuración de no producción en nuestro entorno de producción Esto llevó a un conjunto relacionado de cuatro síntomas distintos: comportamiento incorrecto de configuración, fallos intermitentes de acceso/acceso, un problema de acceso a la tienda de archivos que afecta a un entorno de cliente, y actualizaciones de estado de oleoducto retardadas en la interfaz de usuario. Hemos identificado y estamos implementando una solución permanente para el defecto de configuración subyacente, y ya hemos puesto en marcha cambios de recursos y capacidad que resuelven el síntoma de demora de la UI. En ningún momento durante este incidente se perdieron, corrompieron o dejaron ejecuciones de oleoductos en un estado atascado. Cuando el comportamiento de ejecución fue afectado, se limitó a demoras en la visibilidad del estado, no en el procesamiento subyacente. # Detalles del incidente ## Valores de configuración de producción incorrectos Aplicados Nuestro equipo de ingeniería confirmó un defecto en el oleoducto de implementación de Service Manager que causó la implementación de ciertos servicios de producción utilizando valores de configuración destinados a un entorno diferente, en lugar de la configuración correcta de producción. *Causa real* El servicio responsable de buscar configuración anula durante las consultas de implementación una API interna que devuelve un máximo de 1.000 resultados por solicitud. El número total de servicios en el medio ambiente aumentó recientemente más allá de ese límite. Como resultado, en la respuesta no se incluyó ningún servicio más allá de los primeros 1.000 retornados, y el oleoducto de despliegue disminuyó silenciosamente a valores de configuración predeterminados para esos servicios. Este es un defecto confirmado de paginación en la herramienta de implementación, no un problema con los valores de configuración mismos. **Resolución** Engineering ha confirmado el mecanismo y está implementando una solución permanente para eliminar esta brecha relacionada con los límites en la tubería de despliegue. ## Intermittent Login / Access Failures Durante el despliegue de Service Manager mencionado anteriormente, algunos usuarios experimentaron fallos intermitentes de acceso o acceso. En el funcionamiento normal, los casos en que se ejecutan anteriormente deberían seguir sirviendo de tráfico sin interrupción mientras se está realizando un nuevo despliegue. En este incidente, ese comportamiento de retroceso no ocurrió como se esperaba, contribuyendo a tener acceso a fallas durante la ventana de despliegue. ## Filestore Access Issue Se identificó un problema de acceso a la librería que era específico para el entorno Prod-3 y afectaba el entorno de un solo cliente. *Causa real* Esto está relacionado con una configuración de permiso de IAM / cubo de almacenamiento en Service Manager, potencialmente activada por la actividad de rollback. ## Delayed Pipeline Execution Status Updates in UI Algunos usuarios observaron que el gráfico de ejecución del oleoducto en la UI era lento para refrescarse y no reflejaba rápidamente el estado más reciente. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were locked or failed as a result of this issue. *Causa real* El gráfico de ejecución del oleoducto se basa en una secuencia de mensajes \(el log de orquestación\) para recibir actualizaciones de estado. Durante la ventana del incidente, el procesamiento del consumidor de este flujo cayó detrás de \(alto consumidor lag\), que retardó la rapidez con que las actualizaciones de estado llegaron a la interfaz de usuario. Esto se debió al hecho de que la base de datos subyacente estaba en medio de una operación de escalado prevista al mismo tiempo, y un aumento del tráfico durante esa ventana agudizó aún más el retraso. Los usuarios experimentaron esto como una lentitud aparente del oleoducto, aunque las ejecuciones subyacentes estaban funcionando normalmente. **Resolución** Hemos aumentado la capacidad de recursos para que los componentes afectados mantengan más del 50% de espacio libre hacia adelante, reduciendo la sensibilidad a picos de carga similares. Este cambio se ha aplicado y actualmente se está validando como parte del endurecimiento a más largo plazo para esta parte de la plataforma. # Impact Summary * Service Manager y License Manager corrieron con valores de configuración incorrectos en los entornos Prod-1 y Prod-3. * Algunos usuarios experimentaron fallos intermitentes de acceso o de acceso durante la ventana de despliegue afectada. * Un entorno de clientes en Prod-3 experimentó un problema de acceso a la librería. * Los usuarios de entornos afectados vieron actualizaciones de estado de ejecución de oleoductos retrasados en la interfaz de usuario; las ejecuciones de oleoductos subyacentes continuaron funcionando correctamente y no se perdieron, quedaron atrapados o corrompidos. Medidas preventivas Se han identificado las siguientes medidas correctivas y preventivas. Silencio ** Acción correctiva / preventiva** Silencio... Ø Corregir el límite de paginación en el servicio de configuración-lookup para que todos los servicios sean devueltos y evaluados, independientemente del recuento total. ← Agregar salvaguardias para que un servicio que no puede recuperar su configuración falla de forma segura \(por ejemplo, alertas y bloquea el despliegue\) en lugar de caer silenciosamente de nuevo a los defectos de no producción. Silencio tención Aumentar Postgres y mensajería-pipeline recurso headroom \(target: mayor que 50% de capacidad de repuesto\) para reducir la sensibilidad a eventos de carga y escalado simultáneos. Silencio Reconocemos el impacto que este incidente tuvo en varias áreas de la plataforma y apreciamos su paciencia mientras trabajamos a través de una resolución completa.
Traducido automáticamente desde la actualización oficial del incidente.
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.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
## Summary Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage. No customer data was lost. SEI 1.0 customers were not impacted. ## Root Cause Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident. ## Impact Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards. **Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward. ### 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 issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes: * Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure. * Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables. * Increased capacity on the affected database nodes to provide additional headroom. These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT. ## Action Items To prevent recurrence, we are implementing the following: 1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files. 2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Este incidente ha sido resuelto.
# 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.
Actualmente estamos investigando esta cuestión.
Se ha determinado la cuestión y se está aplicando una solución.
Se ha aplicado una solución y estamos monitoreando los resultados.
Continuamos monitoreando cualquier otro problema.
Este incidente ha sido resuelto.
# Resumen Entre el 19 de junio y el 17 de julio de 2026, el paso integrado de Git Clone —y cualquier paso de oleoducto utilizando el plugin de clones de dron-git— falló en ARM64 Kubernetes construir infraestructura con el error exec /usr/local/bin/clone: error de formato exec. AMD64 \(Intel/AMD\) construye, construye Windows, y el camino binario sin contenedores VM no se vio afectado. La causa raíz fue un defecto en nuestro proceso interno de publicación de imágenes que causó imágenes de ARM64 con etiquetas de drones para contener realmente binarios AMD64. Identificamos y mitigamos el tema el mismo día que fue reportado revertiendo la imagen dada por drones a la última versión conocida-buena. No se requiere ningún cambio de acción o configuración del cliente. # Root Cause El 19 de junio de 2026, una remediación de seguridad reestructuraba cómo se construye la imagen dron. AMD64 builds se actualizaron correctamente, pero el oleoducto ARM64 no construyó archivos ARM64 directamente — adaptó el archivo de construcción AMD64 a través de la sustitución de texto y lo compiló en la infraestructura ARM64. El cambio del 19 de junio alteró el archivo AMD64 de modo que la sustitución silenciosamente no-op'd en lugar de fallar, por lo que el gasoducto publicó una imagen etiquetada ARM64 cuyos binarios Git Clone y Git LFS aún se compilaron para AMD64. # Impacto * Afectado: El paso integrado de Git Clone, y cualquier paso de oleoducto utilizando el plugin de clones de drones, que se ejecuta en ARM64 Kubernetes construir infraestructura, en todas las cuentas, entre el 6 de julio y el 17 de julio de 2026. * Síntoma: Builds falló en el paso Git Clone con exec /usr/local/bin/clone: error de formato exec. * No afectado: AMD64 \(Intel/AMD\) Kubernetes y VM construye, Windows construye, el camino de ejecución sin contenedores VM, y nuestra variante de imagen endurecida. # Mitigation Revertimos la versión de imagen de dron-git utilizada en todos los servicios afectados a la última versión conocida-buena. Esto resolvió completamente las fallas de ejecución de ARM64; no se necesitaron cambios de configuración del cliente. # Next Steps Para evitar que estos problemas vuelvan a suceder. * Reconstruye el oleoducto de publicación de imágenes ARM64 para construir nuestros archivos ARM64 dedicados directamente, en lugar de adaptar los archivos de construcción AMD64. * Mejorar la validación automatizada post-publish a cada versión de la imagen: verificar la arquitectura binaria coincide con la etiqueta de la imagen, y ejecutar una prueba de humo funcional antes de que una imagen sea considerada liberable. * Ampliar la cobertura de prueba automatizada para incluir los escenarios de construcción ARM64 Kubernetes. * Retire las versiones de imagen intermedia afectadas de la circulación una vez validada la versión corregida.
Traducido automáticamente desde la actualización oficial del incidente.