Harness Status Page

Oct 8, 2026 · resolved Oct 8

This incident has been resolved.

Oct 6, 2026 · resolved Oct 6

This incident has been resolved.

Oct 6, 2026 · resolved Oct 6

## Summary On **Tuesday, 6 October 2026**, IaCM pipelines that use the **OpenTofu plugin** in **Prod1** failed intermittently for a production accountAffected runs injected secrets successfully, then later steps timed out or failed authentication. The same pipeline often succeeded on retry, with no configuration change. Typical failing executions ran for about 90 minutes. Other Harness modules were not broadly impacted. We have no report of customer data loss. Pipelines that finished inside the token lifetime were unaffected by this defect. ## Root Cause The IaCM stages minted authentication tokens that expired after one hour. Policy checks later in a long run then rejected the token, so the step timed out or failed authentication. That one-hour lifetime was fixed. Runs of about 90 minutes crossed the one-hour mark, which is why the failures showed up on longer pipelines and often cleared on a shorter retry. A separate set of plan errors in the same account came from credential setup in the customer workspace and is outside this incident. ## Impact * **Product area:** IaCM pipelines using the IaCM plugins talking to OPA sdk. * **Customer experience:** intermittent timeouts and authentication failures after secret injection, on runs longer than about one hour. * **Environment:** Prod1, one production account * **Data:** No data loss reported. ‌ ## Remediation * **Immediate:** Opened a status page for the affected Prod1 account, and shipped an interim IaCM manager change for one class of the observed failures while the plugin fix was built. * **Permanent:** Shipped an OpenTofu plugin hotfix so token expiry is configurable. In production the lifetime was raised to about 6 hours, so a long pipeline does not outlive the token. The hotfix was validated in QA and deployed to Prod1. We apologise for the disruption caused. Please reach out to your Harness support contact if you have any further questions.

Oct 6, 2026 · resolved Oct 6

### Summary Customers on Prod 2 experienced intermittent failures of a few Verify steps at startup. Affected steps failed shortly after launch with a message indicating Continuous Verification\(CV\) could not reach an internal Harness service. The issue stemmed from a recent service update that introduced connection pooling to improve performance and reliability with a keep-alive setting incompatible with the receiving service's timeout. No customer data was lost or corrupted. ### Customer Impact Customers using CV Verify steps on Prod-2 saw intermittent step failures during the incident window. The failure rate was low — the majority of executions completed successfully throughout the window. Pipelines that did not use CV Verify steps were unaffected. ### Root Cause A recent CV service update introduced connection pooling to an internal platform component, with a keep-alive duration longer than that component's idle timeout. Connections idle long enough were silently closed by the server; the CV service did not detect this and had no retry logic for such failures, causing them to surface directly as Verify step failures. The issue was intermittent because it only affected connections that happened to be idle long enough to expire. ### Mitigation The connection keep-alive duration was reduced to fall within the receiving service's idle timeout. Failures dropped to near zero immediately, and no further step failures of this type have been observed on any production environment. ### Next Steps To prevent recurrence, Harness will: * **Fix connection handling:** Tuned the default keep-alive and enabled automatic retry on connection failures so stale-connection errors are handled transparently. * **Add resilience at step startup:** Introduce retry with backoff for the internal service call at the Verify step start, so isolated transient failures do not surface as immediate step failures. * **Improve alerting:** Enhanced monitoring for internal connection error rates.

Oct 5, 2026 · resolved Oct 6

## Okta Application SP-Initiated SSO Login Failures ‌ # Summary ‌ Between October 5, 2026, 18:18 UTC and October 6, 2026, 00:26 UTC, some Harness customers were unable to sign in to the Harness Hosted MCP server via SAML Single Sign-On \(SSO\). The main Harness Portal user authentication remained fully operational. Affected users saw login errors or were redirected to an invalid SSO page instead of completing sign-in. ‌ The issue was caused by breaking changes in a version upgrade of the Harness identity service HarnessID. We fixed it with a series of hotfixes, and SSO login was fully restored for all affected customers. ‌ # Impact ‌ Users signing in to Harness MCP via SAML SSO were unable to complete authentication. Existing MCP sessions that relied on SSO could not be refreshed, so some users had to sign in again and could not. Non-SSO logins to Hosted MCP worked during most of the incident. No customer data was lost or exposed. Customers using their own generic SAML 2.0 application configuration in Okta were not affected. # Root Cause On September 29, 2026, an updated version of the Harness application was published to the Okta Integration Network. The update added support for registering multiple reply \(ACS\) URLs, so that customers running Harness across several regions or environments could configure more than one callback URL. ‌ Harness includes an AssertionConsumerServiceURL value in the SAML authentication request it sends to Okta. Before this update, Okta did not validate that value for application instances without additional ACS URLs configured and instead returned the SAML assertion to the application's default ACS URL. After the update, this validation became active across all existing application instances, including those where the customer had never configured an additional ACS URL. Because the requested value was not present in the instance's registered list, Okta returned an HTTP 400 error. ‌ The updated application went through Okta's standard OIN publishing review, which includes backward-compatibility verification against existing installations of the published integration. This change in validation behavior for instances with no additional ACS URLs configured was not surfaced during that review, so it reached customers at the time of release. # Remediation **Immediate Response** ‌ Two workarounds were published on the status page: sign in from the Harness tile in Okta \(IdP-initiated login\), which was unaffected, or register the application's Okta SSO URL in the Additional ACS URLs field of the Harness Okta application. Harness engaged each reported affected customer directly and validated their sign-in. ‌ **Resolution** ‌ Rolling the application back to the previous version was deliberately avoided, as that would only defer the same disruption to the next release. Every affected customer was instead unblocked through the ACS URL registration, and we are working with Okta to make the ACS URL validation conditional again, so that instances with no additional ACS URLs configured behave exactly as they did before, and no customer action is required. # Action Items To prevent such issues from happening again, Harness will take the following action items ‌ 1. Working with Okta to restore conditional ACS URL validation, so instances with no additional ACS URLs configured behave exactly as before and no customer action is required. 2. Publish a dedicated configuration guide for the Harness OIN application in Harness documentation, including reply \(ACS\) URL requirements. 3. Add an independent pre-release verification step against existing customer configurations for any future update to the published Okta application, alongside Okta's own review. 4. Migrate user authentication to Harness ID, which removes the dependency on this validation behavior entirely.

Is Harness down right now?

No — Harness is up. All systems operational as of Oct 12, 4:52 AM UTC.

What is Harness's current status?

Harness: All Systems Operational. Alert24 checks Harness's status page continuously and can notify you the moment it changes.

How do I get alerted when Harness goes down?

Alert24 monitors Harness and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.