FME API write operations started returning 499 errors

What to do

• Check whether you use Split (Harness FME) FME. 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 30m it lasted.

  Anything that failed between 2026-08-20 14:32 UTC and 2026-08-20 15:02 UTC may need a replay.

• Subscribe to Split (Harness FME)'s feed to hear about the next one first. RSS feed

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

Updates from Split (Harness FME) 5

1. investigatingAug 20, 2026, 2:32 PM UTC

   We are currently investigating this issue.

   provider

2. identifiedAug 20, 2026, 2:47 PM UTC

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

   provider

3. monitoringAug 20, 2026, 2:56 PM UTC

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

   provider

4. resolvedAug 20, 2026, 3:02 PM UTC

   This incident has been resolved.

   provider

5. postmortemAug 23, 2026, 9:45 PM UTC

   ### Summary On August 20, 2026, between 10:24 and 14:55 UTC, a subset of FME writes failed. Writes made from the FME UI and writes made with Harness access tokens \(PATs and SATs\) were not affected. Runtime flag evaluation continued to work normally. The issue was mitigated by reverting a recent authentication change in a shared governance service, and affected writes returned to normal by 14:55 UTC. Status: [https://status.harness.io/incidents/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz) ### Root Cause A change in how a shared governance service authenticated inbound calls resulted in some FME writes being rejected. Those writes used service-to-service credentials that the governance service could no longer verify after the change. FME surfaces a governance failure to the client as HTTP 499, the same status used when a governance policy intentionally denies a change. Because 499 is a valid, expected response in that deny path, the failures did not look like an outage on our alerts, and the incident was identified from customer reports rather than internal detection. ### Impact * A subset of FME writes failed during the window, primarily those made using legacy Split API keys or change request scheduling. * Writes made from the FME UI were not impacted. * Writes using Harness access tokens \(PATs and SATs\) were not impacted. * Runtime flag evaluation continued normally. * No data loss occurred. Failed writes did not apply. ‌ ### Remediation Reverted the governance-service authentication change. Affected writes returned to normal immediately. ### Action Items To prevent such issues from happening again, * Harness will return a distinct error \(not 499\) when a write fails because governance could not be evaluated, so it is not confused with an intentional policy denial. * Add alerting on the governance evaluation call itself, rather than relying on the client-facing status code. * Expand authentication support for policy evaluations. * Expand automated coverage for additional write scenarios.

   provider

Corrections

None so far.

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