Files
SlpSoftware/aidlc-docs/features/react-frontend/operations/monitoring/monitoring-setup.md
T

3.9 KiB

Monitoring Setup Instructions

Concrete setup steps for the approaches chosen in monitoring-plan.md: Logging and Dashboards (no Alerting).

Logging

What to log

  • Uncaught JavaScript errors / exceptions (the app already has an ErrorBoundary component from Code Generation — this is the natural hook point).
  • Broken/failed navigation (e.g. an unexpected router error).
  • No user PII, form input, or sensitive data should ever be logged — this is a public marketing site, but keep this discipline regardless.

Destination — open decision

The destination was not finalized (original Question 3 = C). Two supported options, either of which can be adopted later without further design work:

Option 1: Browser console only (default today)

  • No code changes needed — errors already surface via console.error inside the existing ErrorBoundary.
  • Zero cost, but not centrally visible; only useful for manual debugging (e.g. via a user's screenshot or a support request).

Option 2: External error-tracking service (e.g. Sentry free tier)

  • When decided, add @sentry/react as a dependency, initialize it once in the app entry point (e.g. src/main.tsx) with the project DSN, and report caught errors from the ErrorBoundary's componentDidCatch/onError hook to Sentry in addition to the console.
  • Store the DSN as a Gitea Actions variable (or a build-time .env value, since it's not a secret — Sentry DSNs are safe to expose client-side) and inject it via Vite's import.meta.env.
  • Free tier limits (error volume, retention) are typically sufficient for a low-traffic marketing site.

Log level strategy: only errors are logged (no verbose/info-level client logging) — this is a static site with no meaningful "business events" beyond page views, which are covered by analytics (see Dashboards below), not logging.

Dashboards

Website analytics

Pick one (all have generous free tiers suitable for a small marketing site):

Option Notes
Plausible / Umami Privacy-friendly, lightweight, no cookie banner typically required; self-hosted or low-cost hosted tier
Google Analytics (GA4) / Search Console Free, widely known, but heavier script and involves third-party data sharing (cookie/consent implications)

Setup (once a tool is picked):

  1. Create an account/site entry with the chosen provider and obtain the tracking snippet or <script> tag.
  2. Add the snippet to index.html (or load it conditionally in src/main.tsx) — this is a documentation/config task, not something the current codebase needs restructuring for.
  3. Key metrics to surface: unique visitors, page views per route (Home, Packages, etc. — see frontend-components.md), and referral sources.

Uptime dashboard

Pick one:

Option Notes
UptimeRobot Free tier: up to 50 monitors, 5-minute check interval, optional e-mail notification on downtime (opportunistic, not a designed alerting feature per monitoring-plan.md)
Better Uptime Free tier available; similar capability, nicer public status page option

Setup (once a tool is picked):

  1. Register the production URL (once hosting is finalized — see operations/deployment/deployment-plan.md "Open Item") as an HTTP(S) monitor, checking for a 200 response.
  2. Optional: publish a public status page if desired for transparency to visitors.
  3. Key metric to surface: uptime percentage / current status.

Summary Table

Concern Approach Status
Client-side errors Logging (console today; Sentry free tier optional later) Destination open item
Visitor/usage insight Analytics dashboard (Plausible/Umami/GA4) Tool selection open item
Site reachability Uptime dashboard (UptimeRobot/Better Uptime) Tool selection + production URL open item
Alerting Out of scope Not configured
Shared infrastructure reuse Out of scope None exists yet