The Silent 'Success' Bug That Hid Two Weeks of Missing Data

For two weeks, our own analytics dashboard sat almost flat — and every signal we checked told us it was working. The function returned true. No errors, no alerts, nothing red anywhere. It was still broken the entire time. If any part of your business runs on a dashboard, an automated report, or a "confirmation" from a piece of software, this is the failure mode worth losing sleep over: not the crash that pages someone at 3am, but the silent success that never actually happened.

What went wrong, in plain terms

We built a small analytics path for our product SOLAI: a beacon that fires when someone leaves a page, carrying a JSON event to our tracking endpoint. The browser has a built-in tool for exactly this, navigator.sendBeacon, and it returned true every time we called it — the browser's way of saying "got it, I'll send this even after the page closes."

True is not the same as delivered. It means the browser accepted the data into its own queue. It says nothing about whether that data ever left the machine, survived the network, or was accepted by our server. In our case it wasn't — for two straight weeks — because our JSON payload tripped a browser security check (CORS) that sendBeacon has no way to negotiate. The browser queued it, tried to send it, the security check failed silently, and the only feedback we had — that boolean — had already told us everything was fine.

Why this should matter to you, not just to engineers

You almost certainly don't run sendBeacon. But you almost certainly rely on the same shape of trust: a form that says "submitted," a payment gateway that says "confirmed," a CRM sync that says "complete," a marketing dashboard that stays quiet because nothing looks wrong. Every one of those is a system telling you true without you ever checking whether true meant what you assumed.

The lesson we took from two lost weeks of data: a quiet dashboard and a broken dashboard look identical from where you're sitting. The only way to tell them apart is to check against the underlying system occasionally — not just trust the green tick.

How we actually caught it

We didn't catch it from an alert — there wasn't one. We caught it because the chart had been flat for a fortnight and that finally felt wrong enough to check by hand. Watching the real network traffic, not the boolean, showed the request was going out but never turning into a counted event on our dashboard. That gap — between "the browser tried" and "the number moved" — is where the truth had been hiding the whole time.

The fix

Two options, both sound, used depending on the moment:

Option A. Send the data as plain text instead of JSON. This is a "simple" request type the browser doesn't need to security-check first, so it goes straight through. We parse it as JSON on our own server exactly as before — the fix costs nothing on the receiving end.

Option B. Use a different browser tool, fetch with keepalive, that supports the full security check and gives us a real, checkable response instead of a fire-and-forget guess.

What we do now — and what you can borrow

• Never trust a "success" signal you can't independently verify. Treat it as a hint, not proof.
• Verify at the source, not at the messenger. Our dashboard now counts from a server-side log, not from anything the browser claims to have sent.
• Spot-check the systems you depend on. Pick one number, on one dashboard or report you rely on, and confirm it against the system underneath it. Two weeks of silence taught us that's the only real audit there is.

The two weeks of missing data were entirely our own fault, not a browser bug — we trusted a boolean instead of checking the wire. If you want to know exactly what we check now before we trust any dashboard number, reply to this post and ask — we'll walk you through the one question that would have caught this two weeks sooner.