fix(public): close out the Web Analytics beacon 404 finding on current main and live - #212
Conversation
…t main and live The Cloudflare Web Analytics beacon 404 finding (the site's only analytics, dogfood 455ee8966b) is closed against current main and live as of 2026-08-14. The auto-injection that produced the broken /cdn-cgi/rum 404 is no longer active, so nothing 404s on any page load (measured in real Chromium). The underlying analytics is still absent because the zone-level ingestion endpoint is unprovisioned and the only known site token is revoked, but no code in this repo can restore it — that requires Cloudflare dashboard access or a Web Analytics API token, neither of which is available to this worktree. This commit adds: 1. docs/evidence/web-analytics-beacon-404-reverify-2026-08-14.md: a fresh re-verify receipt (real-browser measurement, direct endpoint probes, repo state, API-scope check) against the current main head (5ded55e) and the live zone on 2026-08-14. The receipt establishes that the symptom no longer occurs and that the restoration cannot be done from this repo. 2. scripts/check-site.mjs: a 'Cloudflare Web Analytics beacon' guard parallel to the existing apple-touch-icon and favicon guards. It asserts every served HTML page carries 0 <script data-cf-beacon> tags and 0 <script src*='beacon.min.js'> references, and that the worker's CSP still keeps both cloudflareinsights substrings (so the manual JS-snippet path keeps working when dashboard access is restored). Tested by injecting the broken 2026-08-09 snippet into index.html — the guard fails with a clear pointer to the re-verify doc. Sanity check for the CSP substrings: tested by stripping them from the worker, the guard fails as expected. The 2026-08-09 diagnosis and 2026-08-11 re-verify are the record of the original failure and its mechanism; this commit is the 2026-08-14 re-verify on the current origin/main head plus the regression net that survives in CI.
… (2026-08-15) Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Warning Review limit reached
Next review available in: 33 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (3)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
1 participant
Closes the dogfood finding "Cloudflare Web Analytics beacon 404s on every load of the live homepage — the site's only analytics" (455ee8966b).
What this PR does
The failure mode the item describes — a beacon POST 404ing on every load — no longer occurs on the deployed site: the zone's automatic Web Analytics injection is inactive, so the served HTML carries no beacon and no analytics request is made (verified in real Chromium across all 8 served pages on 2026-08-14 and re-verified 2026-08-15). The underlying analytics is absent rather than broken: the zone's same-origin
/cdn-cgi/rumendpoint remains unprovisioned and the old site token is revoked — both zone/dashboard-level state this repo cannot change (the deploy token is refused by the Web Analytics API).This PR adds:
docs/evidence/web-analytics-beacon-404-reverify-2026-08-14.md— a fresh re-verify receipt against current main and live: real-browser measurement, direct endpoint probes, repo state, API-scope check, and closeout. The dashboard remediation steps to restore analytics are recorded in the original diagnosis (docs/evidence/web-analytics-beacon-404-2026-08-09.md, PR diagnose Cloudflare Web Analytics beacon 404 on live homepage (cannot be fixed in code — dashboard remediation required) #45).scripts/check-site.mjs— a "Cloudflare Web Analytics beacon" CI guard: every served HTML page must carry 0data-cf-beacontags and 0beacon.min.jsreferences (so the broken snippet cannot silently return), while the worker CSP must keep permitting both cloudflareinsights hosts so the manual JS-snippet flow keeps working when dashboard access is restored. Negative-tested: injecting the broken 2026-08-09 snippet fails the guard with clear errors.Verification
POST https://tinystudio.io/cdn-cgi/rum?→ Cloudflare generic HTML 404 (endpoint unprovisioned; edge answers before the Worker).POST https://cloudflareinsights.com/cdn-cgi/rum?with old token → 404 (token revoked)./user/tokens/verify→ active, but/rum/site_info/list→Authentication error(no Web Analytics permission — restoration cannot be done from this repo).npm test: all green (121 tests, 0 failures), including the new guard.