fix(stats): restore device-day success rate for admin and public

[riderx]

Summary (AI generated)

• Restores public /data live update success rate to device-day app_log outcomes (fail-then-set same day = success only), undoing the fix(stats): unify success rate formula across admin and public metrics #2988 raw install/(install+fail) event formula that dropped the KPI from ~68% to ~24%.
• Aligns admin dashboard success rate with that same formula: global_stats.success_rate cron now uses getDeviceDaySuccessRateCF for the completed day, and admin success/trend charts query device-day outcomes instead of raw version_usage counters.
• Leaves the 1-minute getUpdateStats health window alone (still install/fail for per-app health), so it no longer drives the marketing/admin headline KPI.

Motivation (AI generated)

#2988 was supposed to make admin match the more accurate public device-day rate. Instead it rewrote both paths onto raw event counts, which over-count retries/failures and collapsed both numbers to ~24%.

Business Impact (AI generated)

Restores a trustworthy install success rate on the public /data page and admin Updates dashboard so Capgo is not publishing a misleadingly low reliability number.

Test Plan (AI generated)

• bunx vitest run tests/public-live-update-metrics.unit.test.ts
• After deploy, confirm /private/website_stats/live_updates success_rate returns near the pre-regression ~68% device-day level
• Confirm admin Updates “Success Rate” card matches public after the next usage_success_rate global_stats shard run (or manual shard trigger)
• Confirm admin success-rate charts use device-day semantics (not raw event flood)

Generated with AI

Made with Cursor

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 20 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 124d1a8a-8969-482f-99cd-7b2c31e7db72

📥 Commits

Reviewing files that changed from the base of the PR and between 071565e and 831f836.

📒 Files selected for processing (5)

• supabase/functions/_backend/plugin_runtime/utils/cloudflare.ts
• supabase/functions/_backend/triggers/logsnag_insights.ts
• supabase/functions/_backend/utils/cloudflare.ts
• supabase/functions/_backend/utils/cron_email_stats.ts
• tests/public-live-update-metrics.unit.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 43 untouched benchmarks
⏩ 2 skipped benchmarks¹

---

_{Comparing fix/restore-device-day-success-rate (831f836) with main (0af2467)}

Footnotes

1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[cursor]

Risk: medium. Left a non-blocking comment (not approved): this changes public /data and admin success-rate KPI semantics across Cloudflare stats helpers and cron paths, which is above the low auto-approve threshold. Cursor Bugbot was not present; assigning a human reviewer for the metrics formula change.

  

_{Sent by Cursor Approval Agent: Pull Request Approver External}

[cubic-dev-ai]

All reported issues were addressed across 5 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud