3.9 KiB
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
ErrorBoundarycomponent 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.errorinside the existingErrorBoundary. - 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/reactas a dependency, initialize it once in the app entry point (e.g.src/main.tsx) with the project DSN, and report caught errors from theErrorBoundary'scomponentDidCatch/onErrorhook to Sentry in addition to the console. - Store the DSN as a Gitea Actions variable (or a build-time
.envvalue, since it's not a secret — Sentry DSNs are safe to expose client-side) and inject it via Vite'simport.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):
- Create an account/site entry with the chosen provider and obtain the tracking snippet or
<script>tag. - Add the snippet to
index.html(or load it conditionally insrc/main.tsx) — this is a documentation/config task, not something the current codebase needs restructuring for. - 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):
- Register the production URL (once hosting is finalized — see
operations/deployment/deployment-plan.md"Open Item") as an HTTP(S) monitor, checking for a200response. - Optional: publish a public status page if desired for transparency to visitors.
- 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 |