SLP_Software/SlpSoftware
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Finishes monitoring process in aidlc

Browse Source
This commit is contained in:
Sluijsens
2026-07-24 15:21:31 +02:00
parent 11250a584e
commit b8b0cd2e2c
8 changed files with 290 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md
+34
View File
@@ -0,0 +1,34 @@
# Monitoring Plan
## Context
This feature is a static marketing website (`dist/` bundle, no back-end, no database) currently deployed manually via a build artifact (see `operations/deployment/deployment-plan.md`). There is no existing monitoring/logging infrastructure in this project yet.
## Decision
Monitoring/observability is **included** for this feature (Question 1 = A / clarified further via Clarification Question 1).
Initial answers to the monitoring plan were contradictory: Question 2 selected "Logging" only (A), yet the alerting/dashboard follow-up questions (4, 5, 6) were also answered, and the answer to Question 4 (`S`) was not a valid option. A clarification round was run (`operations/plans/monitoring-setup-clarification-questions.md`) to resolve this before generating artifacts.
**Clarified answer**: **Logging + Dashboards** (Clarification Question 1 = C). Alerting is explicitly **out of scope** for this feature at this time (Clarification Question 2 = D, "not needed yet / decide later" — consistent with not choosing Alerting in Clarification Question 1).
## Chosen Approach(es)
### Logging
Client-side errors (JavaScript crashes, broken links) should be logged, but the concrete destination is not yet decided (original Question 3 = C, "not yet determined"). This is tracked as an **open action item** below rather than blocking this stage.
### Dashboards
A combination of:
- **Website analytics** (visitors, page views, basic engagement) — e.g. a simple/free tool such as Plausible, Umami, or Google Analytics/Search Console.
- **Uptime dashboard** (site reachability) — e.g. an external monitoring service such as UptimeRobot or Better Uptime.
(Original Question 6 = C, "Both (analytics + uptime dashboard)".)
## Explicitly Out of Scope
- **Alerting/notifications**: not requested. If the uptime dashboard tool supports basic notifications (e.g. UptimeRobot's own e-mail alert on downtime), that MAY be enabled opportunistically as part of dashboard setup, but no dedicated alerting channel, escalation policy, or alert-on-error-rate logic is designed or required here.
- **Reuse of existing infrastructure**: this feature does not plug into any pre-existing shared monitoring (original Question 7 = A) — there is none yet. Should a shared back-end/CMS monitoring stack be introduced later, this can be revisited.
## Open Action Items
1. **Decide logging destination**: choose between "browser console only" (no central storage, manual debugging) or a free/low-cost external error-tracking service (e.g. Sentry free tier) once this becomes a priority. Until decided, `monitoring-setup.md` documents both options so either can be adopted without re-doing this stage.
2. **Pick concrete analytics + uptime tools**: `monitoring-setup.md` lists candidate free-tier tools; final tool selection/account creation is a manual follow-up outside this workflow (no code changes required to swap providers, since neither is wired into the codebase yet beyond an optional embed snippet).
## Rationale
Given this is a simple static marketing site with no backend and no existing monitoring, the aim is lightweight, low/no-cost observability: enough to know if the site is down (uptime) and how it's being used (analytics), plus a documented (if not yet finalized) path for capturing client-side errors. Alerting was deliberately left out to avoid over-engineering a notification pipeline before there's a concrete trigger/audience for it.
aidlc-docs/features/react-frontend/operations/monitoring/monitoring-setup.md
+62
View File
@@ -0,0 +1,62 @@
# 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 |