Post-mortem: twelve days shipping a broken deploy without knowing
From June 29 to July 11 this site did not deploy once, while I was convinced it did. The full story of Cloudflare's 3 MB limit, how I found it, how I fixed it, and the three lessons I am keeping.
This site runs on a Cloudflare Worker, on the free plan. That plan has a rule I knew from reading the docs and had never stopped to respect: the worker's code cannot exceed 3 MB compressed. On June 29 I added a token-counting page using a library that weighs 3.6 MB. The worker crossed the limit and every deploy started failing. I did not find out until July 11.
How a failure hides for twelve days. Easily: I deployed by hand, the command returned a long error ending in an unreadable code, and the site stayed online — serving the June 28 version. Since the home page loaded and I tested almost everything locally, it all looked fine. I published articles, polished pages and fixed a form for nearly two weeks, and none of it reached production. A broken site did not look broken: it looked stale, which is far worse, because nothing warns you.
How it surfaced. While fixing the contact form, I wanted to confirm in production that the change had shipped. It had not. That time I read the whole error, top to bottom, and the second-to-last line said it plainly: the compressed script weighed 3.25 MB and the maximum was 3. It was not a form bug: it was every deploy, for twelve days.
The diagnosis. With the worker's size broken down, the culprit was obvious: the token-counting library was entering the server bundle whole, even though it only ever ran in the browser. And as a bonus I found another one just like it: the 3D library animating the background scenes was also sitting in the server doing nothing. The fix was splitting each page in two files — a server one that imports nothing heavy, and a client one that loads only in the browser — and the worker dropped from 3.25 to 1.68 MB. Half its weight was doing nothing.
Lesson 1: a deploy that can fail silently, will. Deploys are now done by a robot on every push, and a failure shows up red on GitHub instead of depending on me reading a terminal. Since this week there is also a test suite that browses the freshly built site before any deploy is allowed: if something basic breaks, the deploy is never attempted.
Lesson 2: measure anything that has a limit. The worker's size has a hard cap, so it is now checked on every build and shown on the project's page. Anything with a hard limit and silent growth — a bundle, a quota, a disk — eventually collides; the only question is whether you notice before the limit does.
Lesson 3: read errors to the end. The information was there from day one, in the second-to-last line of an error I skipped because it was long and because "the site worked". Thirty seconds of attention would have saved me twelve days. Of everything this failure taught me, this is the lesson I am finding hardest to truly learn.
