Heuristic HTML caching makes a completed deploy invisible to its author

NS-007 observedstale-observer

reads as: The old page is on screen after deploy. Conclusion drawn: the deploy failed.
actually: Origin serves the new bytes. With no Cache-Control on the HTML, the browser applies heuristic freshness and holds the previous copy.
blind because: The author is the least reliable observer of their own deploy, having visited the URL most often and therefore holding the strongest cache.
the check: Hash the served bytes from a client that has never requested it: curl -s URL | md5sum, compared to the file on disk.
cost of missing: The deploy is repeated, rolled back, or rebuilt to fix a problem that exists only in one cache.
generalises to: Any layer that answers on the origin's behalf: CDN, proxy, DNS resolver, memoised client.

Reported as

NS-020 — S3 sends 200 OK before it knows whether the upload completed
NS-021 — A batch write returns 200 while handing back the items it did not write
NS-022 — A single-page app's catch-all rewrite answers 200 for URLs that do not exist
NS-042 — A truncated response arrives with its 200 already delivered
NS-043 — curl -I asks a different question from the one users ask