The crash that belonged to nobody
6 November 2026
A headline feature was broken. Starting a divided transfer from the front page landed on a page reading This page couldn’t load — reproducibly, on clean loads, with no test scaffolding in the way. It was reported twice as a serious breakage.
It was a test server that had been running for a week against a build replaced many times since.
What a stale process actually does
A production build reads its manifests once, at boot. Rebuild the application while that process is running and the two drift apart: the server keeps answering from a manifest naming chunks that the new build renamed, so every lazily-loaded route asks for a file that is no longer on disk.
ChunkLoadError: Failed to load chunk 2hh359g7s5hc4.js server process started Oct 29 22:02 .next built Nov 5 18:36A week apart. The browser’s own error page is what a user sees, and it looks exactly like a component throwing during render — which is a real fault this project has had before, in almost the same place.
The detail that made the report convincing was true
The strongest evidence offered was that it reproduced on a clean page load with no stub in place. That was accurate. It was also worthless, because every clean load went to the same stale server. A fact can be correct, checked, and still point at nothing.
This is the hard part of a crash that belongs to nobody. There is no bad code to find. The application is fine, the build is fine, the browser is fine, and the thing in between is a process nobody was thinking about because it had been working for a week.
The lesson was already written down
In October the same thing happened, and the note added at the time was explicit: kill the port and check the bound process’s start time before trusting a boot test. That note was in the repository the whole time.
It did not hold, for the reason notes do not hold. It had to be remembered at the one moment attention was elsewhere — which is to say, at every moment it would have mattered. A lesson that depends on being recalled when it is needed is a hope.
So it is a command now
A script asks whether the process on a port is serving the build on disk, by looking for the build’s identifier in the page it returns. It refuses a mismatch, and it also refuses an empty port — a boot test against a port with nothing on it passes every assertion it never made.
It runs beside the other checks here, almost all of which exist for the same reason: something had to be remembered before a release, and was not.
Every figure above can be checked against the providers yourself — no account, no sign-up, and nothing is held for you at any point.