๐ ๐ ๐๐ฟ๐ผ๐ป ๐๐ผ๐ฏ ๐๐ฎ๐ถ๐น๐ฒ๐ฑ ๐ฆ๐ถ๐น๐ฒ๐ป๐๐น๐ ๐ผ๐ป ๐๐น๐ผ๐๐ฑ๐ณ๐น๐ฎ๐ฟ๐ฒ
The build passed. The deploy was green. But data stopped updating. No alerts. No crashes. I found out three days later.
I used a Cloudflare Worker. It pulled data from an API and sent it to Postgres. It worked for weeks. Then it stopped.
The logs showed one error. Too many subrequests by single Worker invocation.
A subrequest is any outbound fetch. Cloudflare's free plan allows 50 per invocation. Once you hit 50, every fetch fails.
I spent an hour tuning batch sizes. I moved from 25 to 15 items. Then to 10. It still failed.
The batching was not the problem. A new metadata feature made one fetch per item. 100 items meant 100 subrequests. I hit the limit before database writes started.
I optimized the part looking expensive. The real cost was a quiet loop in a different file.
When you hit a limit, count the resource. Do not optimize what looks heavy.
Three ways to fix this:
- Reduce subrequests. Remove calls you do not need.
- Move fetching to a CI runner. Tools like GitHub Actions have no subrequest cap.
- Pay for the plan. The $5 plan increases the limit to 10,000.
I removed the unnecessary calls.
Two lessons:
- Serverless platforms have outbound caps. Know your limit before you add a fetch loop.
- Do not optimize based on feel. Count the resource.
The most dangerous loop is the one you do not notice.