ChangesHarnessAPI Login failures
Harness: Critical incident: API Login failures
Summary
Summary pending. The diff below shows exactly what changed.
Incident page: the full timeline of updates
What changed
Struck in red is what Harness removed; blue is what they added. Muted text is unchanged context.
Before: not present
After: API Login failures
Before: not present
After: critical
Before: not present
After: postmortem
Before: not present
After: 2026-09-15 17:22 UTC
Before: not present
After: 2026-09-15 17:43 UTC
Before: not present
After: Platform, Prod 1 - Platform, Prod 2 - Platform, Prod 3 - Platform, Prod 4 - Platform
Before: not present
After: We are currently investigating this issue.
Before: not present
After: The issue has been identified and a fix is being implemented.
Before: not present
After: A fix has been implemented and we are monitoring the results.
Before: not present
After: This incident has been resolved.
Before: not present
After: # 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. |
First version of this incident archived by Rewindex. View the live incident (opens in new tab).
History of this incident
Tuesday, September 15
1 incident change
- CriticalCritical incident
API Login failuresthis change