CSS Failed to Load on Production

2026-03-10 Duration: 3 minutes Zero users affected (probably)

Summary

The production site served unstyled HTML for approximately 3 minutes after a deploy that changed the SCSS fingerprint hash. Browsers with cached CSS received a 404 for the old filename, and the new file was not yet available on the CDN edge.

Impact

Any visitor who loaded the site during the 3-minute window saw unstyled content. The HTML was fully functional — all links, navigation, and content worked correctly. The site looked like it was from 1996. Given the blog’s traffic volume, the number of affected users is estimated at zero, but cannot be proven.

Timeline

09:14 UTC — Commit pushed with updated _variables.scss (changed border color from #e5e5e5 to #e4e4e7)
09:15 UTC — Build completed. New CSS fingerprint generated: main.a7f3b2c1.css (previous: main.d4e1f8a2.css)
09:15 UTC — Deploy succeeded. Old CSS file no longer exists at old URL
09:15 UTC — CDN cache propagation begins
09:18 UTC — CDN cache fully propagated. New CSS available on all edges
09:22 UTC — Author opened the site to verify and noticed nothing wrong (cache had already propagated)

Root Cause

Asset fingerprinting works as designed — when the CSS content changes, the filename changes, and the old file is removed. The 3-minute gap between deploy and full CDN propagation is normal GitHub Pages behavior. There is no atomic deploy mechanism for static file hosting.

Resolution

No action taken. This is how static site deployment works. The window is unavoidable without a CDN that supports atomic deploys or pre-warming.

Action Items

Confirm this is expected CDN behavior
Verify SRI hashes match the new fingerprinted filename
Document the expected propagation delay in the runbook
Accept that the site will briefly flash unstyled on CSS changes