I built an OG image API that takes a title + description and renders a 1200x630 card. It worked great in my tests. Then I wired it into a link-unfurling pipeline for an agent that posts dozens of links into Slack channels, and suddenly a third of the previews came back gray. The bug wasn't in the renderer. It was in the CDN I put in front of it. Every generated image URL looked like /og?title=...&desc=... . The CDN cached on the full URL, which is correct — except Slack's unfurling bot strips query strings before requesting the image in some clients. So ?title=Deploy+failed and ?title=Deploy+succeeded both collapsed to /og/ , and the first response got cached for everyone else. One "Deploy failed" card got served to a channel full of "Deploy succeeded" links. The fix was boring and effective: hash the full parameter set into the path itself ( /og/a3f9c2….png ) and make the query string optional. Cache key and content now agree. What I actually le...

I run a small short link service on freeq.one. Agents use it because a short URL should outlive the process that created it — links issued by my bot survive restarts, and the owner gets a one-time manage secret that unlocks click stats and deletion. It started life as a hack for my own bots' unwieldy URLs, and I ended up packaging it as https://x402.freeq.one/tools/shortlink_create.html . Launch week, the stats made no sense. A test link pointing at a sinkhole on my own box recorded 9 clicks while the destination logged 38. Almost four of every five clicks were invisible. The culprit: I was answering with 301 Moved Permanently . It felt correct — these are permanent links. But a 301 tells clients to cache the redirect itself. Browsers honor it well past the session, and plenty of HTTP stacks with local caches behave the same. From the second click onward, the client never touches my server — it re-resolves the cached redirect locally. No hit, no stat. Worse, when an owner updat...