Skip to content

Observability

Effectively none.

What exists

  • console.log / console.error calls in AuthContext.tsx (login flow, debug logs)
  • console.error(\API ${method} request failed:`, error)inapi.ts`
  • Toasts to the user via sonner and shadcn toast

What does not exist

Capability Status
Error tracker (Sentry, Bugsnag, Rollbar)
Real User Monitoring (Sentry RUM, Datadog RUM, SpeedCurve)
Analytics (GA, Mixpanel, Amplitude, Segment)
Console-log scrubbing for production ❌ — console.log("login - extracted user:", user) ships to prod with sensitive PII
Source-map upload to an error tracker
Session replay (FullStory, LogRocket)
Web Vitals reporting
Feature flag system

Specific concerns

  1. console.log is left in production. AuthContext.tsx has lines like console.log("login - extracted user:", user) that fire on every login. PII in console (visible to anyone with devtools, but also potentially captured by any browser extension the user has installed) is a moderate exposure.
  2. Fix: a tiny logger wrapper that no-ops in production, plus a Vite build-time replacer (drop_console in esbuild config) to strip residual ones.

  3. No source-map upload. If the team eventually adds Sentry, the production minified stack traces will be unreadable without source-map upload at build time.

  4. No correlation with backend logs. The FE doesn't propagate a request id; the BE doesn't issue one. Reconstructing a user's session across FE + BE logs is impossible without both ends emitting a shared id.

  5. No usage telemetry. The team has no data on which admin features are actually used. If /prompts is unused (which is consistent with the route being hidden from the sidebar), no one knows for sure.

Minimal improvements (in cost order)

  1. Strip console.log in productionvite.config.ts:
    esbuild: { drop: ['console', 'debugger'] },
    
  2. Add web-vitals — 5-line integration to report LCP/INP/CLS to any backend endpoint.
  3. Add a feature-flag library (e.g., Statsig SDK, ~10 lines) so the team can ship dark — relevant if/when the admin tool grows.
  4. Add Sentry@sentry/react SDK with BrowserTracing + source-map upload step in CI. ~30 minutes of setup.
  5. Add an analytics SDK — only if the team will actually use the data. Otherwise it's data theatre.

Recommendations

For a 10-50 user admin tool, the cost/benefit of full observability is low. Priority should be:

  1. Strip console.log (this week)
  2. Add Sentry (next sprint) — catches the next regression before users complain
  3. Add Web Vitals (next sprint) — cheap, no downside
  4. Defer analytics until there's a concrete decision riding on usage data

The platform-wide observability gap is larger; addressing it here first is reasonable (low traffic, internal users tolerate breakage during instrumentation).