Family-wide /stats page on oriz.in (auto-tracked, public, all 11 sites + all repos)

decision Sat Jun 20 2026 00:00:00 GMT+0000 (Coordinated Universal Time) statsoriz-intransparencypublicauto-trackingdecisionsarchitecture

Family-wide /stats page on oriz.in

Decision

oriz.in/stats is a single, public, transparent dashboard that aggregates everything the family auto-tracks:

• Visitor stats — every site's CF Web Analytics summary (pageviews / unique visitors / top paths / top referrers), all 11 sites in one table
• Code stats — every repo's metrics: line counts (Tokei), contributor counts (GitHub Insights), commit cadence, coverage (Codecov), maintainability grade (Code Climate), open issues / PRs
• Coding time — Wakatime public dashboard data (last 7d / 30d totals, language breakdown)
• Lifestream summary — counts derived from the oriz-me JSONL by kind (git events / coding days logged / visitor day-summaries)

Built at deploy time from each upstream's API; no client-side fetches; cached at the Cloudflare edge with 1h s-maxage. A daily GH Actions cron at 02:00 IST (after the lifestream auto-event-sources crons at 01:00 IST) re-deploys oriz-in-site so the dashboard refreshes nightly without manual intervention.

User direction: "family-wide /stats on oriz.in" — locked.

Why family-wide, not per-site

• A per-site /stats per repo would duplicate 11 build pipelines for the same dashboard component.
• The interesting comparison is across the family — which site ships fastest, which has the most contributors, total LOC, cross-site engagement — and that view only exists at the apex.
• One public stats URL is also the cleanest answer to "show me what you build" — recruiters, OSS contributors, and curious readers hit a single transparent page.

Implications

• <FamilyStatsDashboard /> component lands in (forward reference — kit shim split per). Single component embedded in oriz-in-site/src/pages/stats.astro. Per the markdown-in-repo-only posture the component renders at build time from JSON props, no runtime CMS.
• Build-time data fetch runs in oriz-in-site build:
  • CF Analytics GraphQL API ? 11 site summaries (24h + 7d + 30d)
  • GitHub REST API ? per-repo /stats/contributors, /stats/commit_activity, /stats/code_frequency, repo metadata (stars / forks / open issues)
  • Tokei JSON output — consumed from each repo's CI artefact (or re-run inline if the repo is shallow-cloned at build)
  • Wakatime public summary endpoint — no auth needed for public dashboard scope
• Daily refresh cron — GH Actions schedule 0 2 * * * (02:00 IST = 20:30 UTC previous day) re-deploys oriz-in-site. Pings healthchecks.io per health-check-cron-plus-uptime.
• Caching — page emits Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400 so the CF edge serves it for free per the CF Worker quota mitigation playbook.
• API tokens — CF Analytics, GitHub, Wakatime API tokens in Doppler, GH Secrets at build time only. No tokens shipped to client.
• Auto-tracked end-to-end — the page exists because every upstream is already auto-tracked per auto-only-tracking and the forward-referenced auto-tracking-everywhere decision. No manual data entry anywhere.
• Privacy posture — every metric on the page is already public upstream (CF Web Analytics is cookie-less aggregate data, GitHub Insights is repo-public, Wakatime public dashboard is opted-in). No PII surfaces. Falls under the family-wide privacy-page /privacy addendum for /stats.

Cross-refs

• Code stats everything decision
• Lifestream auto-event sources
• Cron split decision
• CF Worker quota mitigation playbook
• Markdown-in-repo only decision
• Cloudflare Web Analytics service
• GitHub Insights service
• Tokei service
• Wakatime service
• Auto-only-tracking rule (forward ref — being added in parallel)
• Auto-tracking everywhere decision (forward ref — being added in parallel)
• Family-wide privacy page decision