Skip to main content
Harness

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

Partial outage Lasted 6h 51m · started · Harness's page

Level
confirmed
Worst impact
Partial outage
Components
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
Down Index
37of 100

What to do

  • Check whether you use Harness Continuous Delivery (CD) - FirstGen - EOS, Continuous Delivery (CD) - FirstGen - EOS, Continuous Delivery - Next Generation (CDNG), Continuous Delivery - Next Generation (CDNG) and 39 more. Check your stack

    Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.
  • Confirm your retries, queues and scheduled jobs caught up after the 6h 51m it lasted.

    Anything that failed between 2026-07-27 06:42 UTC and 2026-07-27 13:33 UTC may need a replay.
  • Subscribe to Harness's feed to hear about the next one first. RSS feed

    https://down.guide/feed?provider=harness works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Harness 12

  1. investigating

    We are currently investigating this issue.

    provider

  2. identified

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

    provider

  3. monitoring

    A fix has been implemented and we are monitoring the results.

    provider

  4. investigating

    We are currently investigating this issue.

    provider

  5. investigating

    We are continuing to investigate this issue.

    provider

  6. identified

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

    provider

  7. identified

    We are continuing to work on a fix for this issue.

    provider

  8. monitoring

    A fix has been implemented and we are monitoring the results.

    provider

  9. monitoring

    We are continuing to monitor for any further issues.

    provider

  10. monitoring

    We are continuing to monitor for any further issues.

    provider

  11. resolved

    This incident has been resolved.

    provider

  12. 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 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._

    provider

Reports count in aggregate; nothing about you is shown.

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.

Questions about DWN-b74d3c895b

Is Harness still down?

No, this incident was resolved 2026-07-27 13:33 UTC. For Harness's live state, see https://down.guide/harness.

How long did it last?

6h 51m, from 2026-07-27 06:42 UTC to 2026-07-27 13:33 UTC, by the times Harness posted.

What was affected?

Harness named Continuous Delivery (CD) - FirstGen - EOS, Continuous Delivery (CD) - FirstGen - EOS, Continuous Delivery - Next Generation (CDNG), Continuous Delivery - Next Generation (CDNG) and 39 more.

What caused it?

Harness hasn't published a root cause. If it does, it shows here.

Where does this come from?

Harness's official status page, https://status.harness.io, quoted verbatim. down.guide's own probes, reports and social counts are labeled as ours.