Release Incident Playbook

CORS policy blocks frontend: symptoms, cause, and the test that catches it

A CORS change blocks the production frontend from calling its own API.

CORS policy blocks frontend is documented by 3 accepted public reports from 3 organisations, 3 of them published in the last 5 years.

  • Likelihood: medium (3 public reports in 5 years)
  • Impact: medium (3 of 3 reports: availability)

3 public reports · verified 2026-10-21

Symptoms

User-visible

  • Users opening the application saw errors after a backend deployment changed the CORS headers.[1]
  • The core application was marked as a major outage from 12:23 PM to 1:57 PM UTC.[1]
  • Workspaces reached through a custom domain could not log in because of a CORS error.[2]
  • Login through the default hosted subdomain still worked while custom domains failed.[2]
  • The UI failed to render and was inaccessible to all customers.[3]

Monitoring-visible

  • API requests still worked and data ingestion continued while the browser UI failed.[3]
  • A non-urgent support case 139 minutes after the release was the first signal.[2]
  • Broader impact became clear only with the first urgent support case at 23:41 CDT.[2]

Root causes

  1. stage: code A backend deployment changed the CORS headers, so the frontend could no longer communicate with the API.[1]
  2. stage: third-party An upgraded third-party JavaScript component began sending a baggage header that the cross-origin allowed headers policy did not list, so browsers rejected the UI's API requests.[3]
  3. stage: release-process A production release shipped a CORS error on custom-domain login because pre-release login testing did not cover custom domains. Build validation testing did not catch the CORS error either.[2]

Public examples

  1. [1]TrustPoint, 2026-05-06. A TrustPoint backend deployment changed CORS headers, which stopped the frontend from communicating with the API until the CORS configuration was corrected and redeployed. primary Website is down
  2. [2]Stoplight, 2023-06-09. A Stoplight production release caused a CORS error that blocked login for workspaces accessed through custom domains, and a release rollback resolved it. primary Login issue for workspaces using custom domains - Use *.stoplight.io domain for workspace login
  3. [3]ChartHop, 2022-11-09. An upgraded third-party JavaScript component began sending a baggage header that ChartHop's cross-origin allowed headers policy did not accept, so browsers rejected API requests from the UI. primary UI failing to load

Test classes that catch it

Test classStageLimitationBasis
End-to-end testspre-deployAn end-to-end login that runs only through the default subdomain passes, because the CORS error hit only workspaces reached through custom domains.cited in [2]
Security testspre-deployA CORS policy check validates the server's allowed origins and headers but not a new request header, such as baggage, that an upgraded browser component starts to send.by design analysis
Synthetic monitoringpost-deployAn API-level synthetic check passes because direct API requests kept working; only a browser-based check sends the cross-origin request that fails.by design analysis

Risk

  • Likelihood: medium (3 public reports in 5 years)
  • Impact: medium (3 of 3 reports: availability)
Counts behind the grades
Accepted public reports3
Published in the last 5 years3
Impact stated: availability3

How the grades are computed

Pre-release checklist

  • PR-01
  • PR-02
  • PR-03
  • PR-04
  • PR-05
  • PR-06
  • PR-07

First 30 minutes

  • FM-01
  • FM-02
  • FM-03
  • FM-04
  • FM-05
  • FM-06
  • FM-07
  • FM-08

Download the checklist

What catches this: catalogue entries

Listed because their own documentation or site names end-to-end tests, security tests, synthetic monitoring on the verification date. Alphabetical. Not a recommendation.

Tools whose documentation names these test classes

Providers whose site names these test classes

Only on this page

In report [2], the CORS error reached production with a release at 14:22 CDT. The first sign was a non-urgent support case at 16:41 CDT, 139 minutes later. Broader impact became clear only with the first urgent support case at 23:41 CDT, more than 9 hours after the release. Stack and log monitoring did not catch it. Login through the default subdomain still worked, so only workspaces on custom domains failed.

The follow-ups in report [2] name end-to-end tests: pre-release end-to-end tests for service-auth CORS operations and custom domains, plus custom domains in pre-release QA login testing. They also add production alerts for 500 responses on login URLs and revise out-of-hours incident response. The 139 minutes measure time to the first customer contact, not time to an alert. A CORS fault that affects one class of origin leaves no signal until a check sends requests from that origin.

Questions

What causes CORS policy blocks frontend?

One report traces it to a backend deployment that changed CORS headers [1] and one to a production release that broke login on custom domains [2]. A third traces it to a third-party component upgrade that started sending a baggage header the allowed headers policy did not list [3].

What are the symptoms of CORS policy blocks frontend?

The UI shows errors or fails to render, while direct API requests keep working [3]. In one report, only logins through custom domains failed [2].

Why did tests not catch CORS policy blocks frontend?

In report [2], build validation testing did not catch the CORS error, and pre-release login testing did not cover custom domains. The follow-up added pre-release end-to-end tests for service-auth CORS operations and custom domains.

Which test class catches CORS policy blocks frontend, and what does it miss?

End-to-end tests carry the cited label from report [2]; security tests and synthetic monitoring carry the by-design label. An end-to-end login through the default subdomain alone misses a fault that hits only custom domains.

How long did it take to detect CORS policy blocks frontend in the public reports?

Report [2] gives 139 minutes from the 14:22 CDT release to the first non-urgent support case. Broader impact became clear at 23:41 CDT, with the first urgent support case.

Should a team roll back or fix forward when CORS policy blocks frontend happens?

One report rolled back the release [2]. Another corrected the CORS configuration and deployed it, with the outage marked from 12:23 PM to 1:57 PM UTC [1].

Release Incident Playbook (2026). CORS policy blocks frontend: symptoms, cause, and the test that catches it, content version 1.0.0. https://releasefailures.com/incidents/cors-policy-blocks-frontend/. Accessed 2026-10-21.