Improve Sentry end-to-end performance tracing across www and vps

[guidefari]

Summary

Our Sentry performance data is useful but still missing the key pieces needed for reliable end-to-end diagnosis.

Current gaps:

• frontend and backend traces are not stitched together
• backend transaction names are too high-cardinality
• slow backend content routes do not expose enough child spans
• frontend production trace sampling is too low for investigation
• release tagging is missing
• environment naming is inconsistent across projects

We want to improve trace quality first, then reduce sampling later.

Goals

• make www -> vps requests share the same trace in Sentry
• make backend traces explorable at route/service/db level
• temporarily raise frontend tracing to match backend for investigation
• improve aggregation quality by normalizing transaction names
• improve deploy/regression visibility with release tagging

Required changes

Frontend

• Set tracesSampleRate to 1.0 in apps/www/src/runtime/index.ts
• Add tracePropagationTargets in apps/www/src/services/analytics/sentry.ts for:
  • https://vps.goosebumps.fm
  • http://127.0.0.1:3003
  • http://localhost:3003
• Keep this explicit as a temporary investigation setting, we will turn it down later
• Add release to frontend Sentry init
• Consider normalizing frontend environment naming so it aligns with backend, likely production / development

Backend

• Normalize backend transaction names so they aggregate by route, not full URL/slug
• Investigate and fix trace/span context propagation across:
  • apps/vps/src/middlewares/effect-logger.ts
  • apps/vps/src/lib/effect-hono.ts
  • apps/vps/src/db/query-timer.ts
• Ensure child spans remain attached to the request trace
• Add explicit spans for slow content/post routes, especially:
  • getPosts
  • getPostBySlug
  • getEditorialPosts
  • getEditorialPostBySlug
  • getMicroPosts
  • getMicroPostBySlug
• Add explicit spans in PostService hot paths, especially:
  • getAllEffect
  • getEditorialsEffect
  • getMicroPostsEffect
• Add release to backend Sentry init

Why

Sentry currently shows real slow paths, but traces are still missing important diagnostic detail.

Examples already observed:

• frontend /tweet pageloads are slow
• backend /content/posts/micro is slow
• these do not currently share a trace ID
• some slow backend traces only show root request spans, not useful child spans
• production frontend sampling is too sparse for investigation

Validation checklist

• Load a known frontend route that hits the backend, for example /tweet
• Confirm the frontend trace and backend request share the same trace ID
• Confirm backend transaction names are normalized by route
• Confirm backend request traces include:
  • request root span
  • route/service spans
  • db spans
• Confirm frontend production traces arrive at the new 1.0 sample rate
• Confirm releases are attached in both gbfm-frontend and gbfm-backend

Notes

• We are intentionally raising frontend tracing to 1.0 for now
• We will reduce sampling after the investigation phase
• Keep changes incremental and production-safe

[linear]

OPS-100

[guidefari]

Sentry docs for the changes in this issue

Distributed tracing / tracePropagationTargets

• Set Up Distributed Tracing — how frontend and backend traces are stitched together via sentry-trace and baggage headers
• Automatic Instrumentation — tracePropagationTargets — controls which outgoing requests carry tracing headers; required for connecting frontend spans to backend spans

Backend tracing (Bun)

• Set Up Tracing — Sentry for Bun — enabling tracesSampleRate and OTel-based span collection on the backend

Custom spans (Effect.withSpan / Sentry.startSpan)

• Custom Instrumentation — adding explicit child spans to hot paths so traces show route/service/db breakdown

Transaction name normalization

• Transaction Summary — how Sentry aggregates transactions; parameterized names (e.g. GET /content/posts/:slug) are required for meaningful p50/p95 data

Release tagging

• Releases — attaching a release to every event so regressions can be tied to specific deploys (SENTRY_RELEASE / VITE_PUBLIC_SENTRY_RELEASE)

---

Generated by Claude Code

[github-actions]

🎉 This issue has been resolved in version 2.50.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀