Read the timing before the code

Aditya JoshiForward Deployed Founding EngineerAug 8, 2026 ·

A server rejected me in 125 milliseconds. 🥶 🥶 I was harvesting public data from a handful of sources for a tool I built on Cloudflare Workers. One source, Reddit, kept blocking the reads. I already had a proper descriptive User-Agent set, so I did what everyone does first: I assumed the bug was mine. Then I looked at the timings instead of the code: → Reddit: 403, in 125 ms → Google News: 503, in 9.6 s → ArXiv: aborted at exactly my 10 s timeout → Hacker News: 200, in 2 s The 125 ms is the whole story 🤯 ! A rejection that fast is not a rate limit and it is not your headers. Nothing was measured and nothing was throttled. It is a reputation decision made before the request was even read. Reddit blocks anonymous reads from datacenter IP ranges, and Cloudflare Workers, Cloud Run and GKE all egress from exactly those ranges. Which means the move I was tempted to make, was never going to work. You cannot out-engineer an IP reputation block with a disguise. The only durable fix is to stop being anonymous: authenticate as a registered app, and you are allowed in from datacenter IPs under a published quota. The reframe I kept: → A fast reject is a policy decision. Look at auth, identity, IP reputation. → A slow reject is a load decision. Look at rate limits, backpressure, timeouts. Before you fix the code, read the timing. How long something takes to fail tells you what failed. A 125 ms no and a 9 second no are two different bugs wearing the same error message. What is a failure whose speed gave away the real cause, once you stopped blaming your own code? 🤔