Major incident

Harness: The Prod3 & Prod1 environment is experiencing intermittent outages. We are currently investigating the issue.

Affected: Continuous Delivery (CD) - FirstGen - EOS, Continuous Delivery (CD) - FirstGen - EOS, Continuous Delivery - Next Generation (CDNG), Continuous Delivery - Next Generation (CDNG), Cloud Cost Management (CCM), Cloud Cost Management (CCM), Continuous Error Tracking (CET), Continuous Error Tracking (CET), Chaos Engineering, Continuous Integration Enterprise(CIE) - Self Hosted Runners, Continuous Integration Enterprise(CIE) - Mac Cloud Builds, Continuous Integration Enterprise(CIE) - Self Hosted Runners, Continuous Integration Enterprise(CIE) - Mac Cloud Builds, Continuous Integration Enterprise(CIE) - Windows Cloud Builds, Continuous Integration Enterprise(CIE) - Windows Cloud Builds, Continuous Integration Enterprise(CIE) - Linux Cloud Builds, Custom Dashboards, Continuous Integration Enterprise(CIE) - Linux Cloud Builds, Feature Flags (FF), Custom Dashboards, Feature Flags (FF), Security Testing Orchestration (STO), Security Testing Orchestration (STO), Service Reliability Management (SRM), Service Reliability Management (SRM), Chaos Engineering, Internal Developer Portal (IDP), Internal Developer Portal (IDP), Infrastructure as Code Management (IaCM), Infrastructure as Code Management (IaCM), Software Supply Chain Assurance (SSCA), Software Supply Chain Assurance (SSCA), Software Engineering Insights (SEI) /AI DLC Insights, Software Engineering Insights (SEI) / AI DLC Insights, Code Repository, Code Repository, Artifact Registry, Artifact Registry, Platform, Platform, AI Test Automation, FME, Release Management

Current status of Harness: Operational — live Harness status

Timeline

1. Jul 27, 2026, 06:42 UTC
   investigating
   We are currently investigating this issue.
2. Jul 27, 2026, 06:45 UTC
   identified
   The issue has been identified and a fix is being implemented.
3. Jul 27, 2026, 06:49 UTC
   monitoring
   A fix has been implemented and we are monitoring the results.
4. Jul 27, 2026, 07:52 UTC
   investigating
   We are currently investigating this issue.
5. Jul 27, 2026, 08:13 UTC
   investigating
   We are continuing to investigate this issue.
6. Jul 27, 2026, 09:04 UTC
   identified
   The issue has been identified and a fix is being implemented.
7. Jul 27, 2026, 09:05 UTC
   identified
   We are continuing to work on a fix for this issue.
8. Jul 27, 2026, 09:07 UTC
   monitoring
   A fix has been implemented and we are monitoring the results.
9. Jul 27, 2026, 09:07 UTC
   monitoring
   We are continuing to monitor for any further issues.
10. Jul 27, 2026, 09:09 UTC
    monitoring
    We are continuing to monitor for any further issues.
11. Jul 27, 2026, 13:33 UTC
    resolved
    This incident has been resolved.
12. Aug 7, 2026, 18:15 UTC
    postmortem
    # 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 incor

Updates as published by Harness (original).