Skip to content
CS/choppari-srinivas
← Back to blog

How a CDN Cache Broke My Next.js Production Deployment

4 min read

Problem

Only around 20% of users couldn't open the website, while the application worked perfectly for everyone else. The partial impact made the incident look like a device, browser, or regional issue rather than a deployment problem.

Investigation

The usual production checks did not reveal an obvious failure:

  • No consistent JavaScript errors
  • No API failures
  • The origin server was healthy
  • The issue occurred only for some users

Root Cause

The CDN was serving an old Next.js static-generation manifest while the HTML referenced a newer deployment.

Old CDN asset: /_next/static/.../_ssgManifest.js
New HTML:      /_next/static/<new-build-id>/...

Affected users downloaded assets from different builds. Users routed to a fresh CDN edge received the correct files, while users hitting an edge with stale content received the mismatched manifest.

Solution

  • Cleared the CDN cache to remove the stale manifest
  • Added safer cache headers for HTML and deployment manifests
  • Kept immutable, long-lived caching only for versioned static assets
  • Verified deployment assets from multiple CDN regions

Lesson

Frontend deployments behind CDNs require deliberate cache invalidation. HTML and build manifests must not outlive the versioned assets they reference, while hashed static assets can be cached aggressively.