API Login failures

What to do

• Check whether you use Harness Platform, Platform, Platform, Platform. 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 21m it lasted.

  Anything that failed between 2026-09-15 17:22 UTC and 2026-09-15 17:43 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 5

1. investigatingSep 15, 2026, 5:22 PM UTC

   We are currently investigating this issue.

   provider

2. identifiedSep 15, 2026, 5:35 PM UTC

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

   provider

3. monitoringSep 15, 2026, 5:43 PM UTC

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

   provider

4. resolvedSep 15, 2026, 5:43 PM UTC

   This incident has been resolved.

   provider

5. postmortemSep 29, 2026, 12:11 AM UTC

   # Root Cause Analysis Report ## Brief API Login Failures Due to a Security Policy Misconfiguration ## 1. Executive Summary On September 11, 2026, a change to one of our network security policies was deployed with a configuration error. For approximately 6 minutes, this caused login requests to be incorrectly blocked, preventing some users from logging in. ‌ The issue was detected automatically by our monitoring systems. The problematic change was fully reverted within 5 minutes of detection, restoring normal login functionality. # 2. Impact * For approximately 6 minutes \(12:30–12:36 PM CT on September 11, 2026\), login requests matching certain URL paths were incorrectly blocked. * Any user attempting to log in during this window could have been affected * No other functionality was affected. Users already logged in prior to the window were not impacted. # 3. Root Cause As part of a planned security enhancement, our team implemented a new network security policy intended to block a small number of specific, exact URL paths. During implementation, the rule was configured with an erroneous matching condition instead of the intended exact-match condition. ‌ As a result, the policy blocked any request whose path began with those values, rather than only the exact paths intended ,  which included legitimate login requests that happened to share that prefix. This caused those login attempts to be rejected during the affected window. # 4. Resolution * The problematic policy change was identified and fully reverted within 5 minutes of the first alert. * Normal login functionality was confirmed restored immediately following the revert. # 5. Risk of Recurrence & Preventive Actions‌ | **Corrective / Preventive Action** | | --- | | Enhanced our QA validation step in the process for this class of security policy change, so the deployed configuration is checked against its intended specification before go-live. | | Enhanced automated test coverage that specifically validates exact-match versus prefix-match behavior for path-based rules, as an additional safeguard on top of the review process. |

   provider

Corrections

None so far.

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