This site runs a small first-party measurement beacon we built and operate ourselves — a page-view event and an engagement-time reading, posted to our own endpoint, stored in our own database. Before launch we ran a calibration pass to confirm the whole chain actually works: a real browser loads the real production page, and a real row lands in the database. It failed. Every time.
The symptom
Five fresh page loads, five real browser tabs, zero rows landed. Not an intermittent flake — a clean 5-for-5 miss. The beacon's request was going out; the server was rejecting it with a 503.
The cause
The first version of the beacon fired its page-view request synchronously, at script-parse time, with no delay and no retry. That request wasn't going out alone. On a fresh, uncached page load, the browser is opening several connections to the same origin at once — the HTML document itself, the stylesheet, the fonts, the app script, the vendor libraries — and the beacon's own POST was joining that exact burst. On the very first load of a session, before any of those connections have settled, that contention was enough to produce a real, repeatable 503 on our own endpoint.
It's a genuinely easy bug to miss, because it only shows up on a cold start — the one moment that matters most for a page-view count, and the one moment a developer testing on a warm, already-cached browser tab never reproduces by accident.
The fix
Two small changes, both on the client: the initial page-view post is now deferred fifty milliseconds via a timer, off the initial connection burst, and it gets exactly one automatic retry if the response comes back as a server error. A client-side validation rejection (a 4xx) never retries — that would just be hammering our own endpoint over a real bug in what we sent, not a transient failure.
Re-run three separate times against production, this landed a real database row on every single load, each one keyed to a session identifier generated fresh in that browser.
A false lead along the way
During the investigation we hit one run that looked like a fresh-load failure but wasn't — traced back to the testing browser profile's own stale disk cache treating a page it had already visited as a repeat load rather than a genuine cold start. That's a property of the specific browser profile doing the testing, not of the server or of how a real visitor's browser behaves on a URL it's never seen before. We noted it, because a debugging session that doesn't separate "the system is broken" from "my test harness is stale" produces exactly the kind of finding you can't trust later.
Why this is worth writing down
The bug never reached a real visitor — it was caught in the calibration pass before launch, specifically because that pass tested a cold start rather than a warm one. That's the actual argument for running a launch calibration at all: not to confirm the happy path works, which it almost always does, but to force the one condition — fresh browser, first load, no cache — that a bug like this needs in order to show itself.