Release Incident Playbook

Asset cache serves old bundle: symptoms, cause, and the test that catches it

Users receive an old JavaScript bundle with a new API and the app errors.

Asset cache serves old bundle 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 (2 of 3 reports: availability)

3 public reports · verified 2026-10-22

Symptoms

User-visible

  • After a deployment, the office list on the calendar page, the telehealth settings on the office settings page and the Cancel RX button on the patient dashboard did not appear.[3]
  • A hard refresh made the missing calendar and dashboard widgets appear.[3]
  • An agent design frontend failed to load after a deployment until the user cleared the browser cache and refreshed.[2]
  • Customers in 8 organisations hit the frontend load failure more than once, and customers in 65 organisations hit it once.[2]
  • Some users could not log in or reach a dashboard after a deploy, and a hard refresh sped up recovery on their devices.[1]

Monitoring-visible

  • Requests for frontend assets returned 404 status codes, and no existing alert fired on them.[2]
  • Customer support tickets about missing page widgets arrived, the first at 23:30 EST on 2 March 2022.[3]
  • User reports of failed logins led to an incident being opened at 20:10 UTC on 31 August 2026.[1]

Root causes

  1. stage: config A deployment changed the URLs that certain JavaScript files load from, and some new URLs lacked a cache-busting hash, so browsers ran stale cached files beside new ones.[3]
  2. stage: release-process A deployment updated the remote entry file on the server without invalidating its cache, and the stale cached copy referenced assets that no longer existed on the server.[2]
  3. stage: release-process After a deploy, a stale JavaScript chunk stayed cached at the CDN edge with a success response, so affected browsers kept loading a broken bundle.[1]

Public examples

  1. [1]Hospitable, 2026-08-31. After a Hospitable deploy, a stale JavaScript chunk cached with a success response at the CDN edge kept being served to some browsers, which loaded a broken bundle and could not complete login until the CDN was purged and frontend caching was removed. primary Some users reporting the inability to log in to the application
  2. [2]UiPath, 2026-03-25. Following a UiPath deployment, browsers kept serving a previously cached remoteEntry.js that referenced assets no longer on the server, so the Agent Builder frontend failed to load with 404 errors for customers in 73 organisations until caches expired or were cleared. primary Multiple Regions - Agents - Agent Builder might not load for some customers.
  3. [3]DrChrono, 2022-03-03. After a DrChrono deployment, some JavaScript file URLs lacked a cache-busting hash, so browsers mixed cached JavaScript files from the previous deployment with files from the current one, errors were thrown and UI widgets such as the calendar office list did not appear until a hard refresh. primary Offices not appearing on the calendar page

Test classes that catch it

Test classStageLimitationBasis
Configuration and environment testspre-deployA configuration check on the build output finds JavaScript URLs without a cache-busting hash, but it cannot see a stale chunk already held at a CDN edge with a success response.by design analysis
End-to-end testspre-deployAn end-to-end run that starts with an empty browser cache never holds the previous remote entry file, so it passes while returning browsers request assets that were removed.by design analysis
Synthetic monitoringpost-deployA scripted login from one location can receive a fresh chunk while the stale chunk is served only to some browsers through other CDN edges.by design analysis

Risk

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

How the grades are computed

Pre-release checklist

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

First 30 minutes

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

Download the checklist

What catches this: catalogue entries

Listed because their own documentation or site names configuration and environment tests, end-to-end 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

Asset cache serves old bundle starts in the release process in report [1] and report [2], not in application code. In report [2], the deploy replaced the remote entry file on the server but left the cached copy in place, and that copy pointed at assets the deploy had removed. In report [1], the deploy left a broken JavaScript chunk cached at the CDN edge with a success response. Code review and pre-merge tests read the new bundle, while the fault sat in what the deploy step did to the old one.

Report [3] reaches the same browser mix of old and new files through configuration: some changed JavaScript URLs had no cache-busting hash. The 404 responses on frontend assets in report [2] fired no existing alert, and the incident was reported by a customer. The guard for asset cache serves old bundle sits on the deploy step's cache handling and on alerting for asset 404s.

Questions

What causes asset cache serves old bundle?

In report [2], a deploy updated the remote entry file without invalidating its cache. In report [1], a stale chunk stayed cached at the CDN edge with a success response. In report [3], some changed JavaScript URLs lacked a cache-busting hash.

What are the symptoms of asset cache serves old bundle?

Calendar and dashboard widgets did not appear until a hard refresh [3]. A frontend failed to load with 404 errors on its assets [2]. Some users could not log in [1].

Why did tests not catch asset cache serves old bundle?

A test that starts with an empty browser cache never holds the previous remote entry file. The 404 errors on frontend assets in report [2] did not trigger any existing alert.

Which test class catches asset cache serves old bundle, and what does it miss?

Configuration tests, end-to-end tests and synthetic monitoring are listed, all with the by-design label. A configuration check finds un-hashed URLs but cannot see a stale chunk already cached at a CDN edge.

How long did it take to detect asset cache serves old bundle in the public reports?

No report gives a time to detect in minutes. Report [3] logged the first support ticket at 23:30 EST on 2 March 2022 and identified the issue at 11:10 the next morning.

Should a team roll back or fix forward when asset cache serves old bundle happens?

Report [3] shipped a hotfix for the un-hashed URLs, report [2] paused deploys until a cache invalidation fix was merged, and report [1] purged the CDN and removed frontend caching.

Release Incident Playbook (2026). Asset cache serves old bundle: symptoms, cause, and the test that catches it, content version 1.0.0. https://releasefailures.com/incidents/asset-cache-serves-old-bundle/. Accessed 2026-10-21.