SlpSoftware/aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md

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) are logged. Decided: Sentry free tier (in addition to the browser console) — see the follow-up in audit.md and the implementation in monitoring-setup.md.

Dashboards

A combination of:

• Website analytics: decided — self-hosted Umami (Podman on the webserver Pi, see operations/monitoring/umami-setup.md), chosen over GA4/hosted Plausible for privacy-friendliness and no recurring cost.
• Uptime dashboard: decided — UptimeRobot, chosen over Better Uptime for its established free tier.

(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 — Resolved and verified: Sentry free tier, wired into ErrorBoundary/main.tsx (see monitoring-setup.md), including tracing, environment/release tags, and a tunnel to bypass ad-blocker blocking. The user confirmed errors, logs, and metrics are received correctly, both locally and on the test environment. The Gitea Actions variable VITE_SENTRY_DSN still needs to be created by the user with a real Sentry project DSN for the test/production build; until then that build simply skips Sentry initialization and only console-logging is active (local development already has its own DSN via .env.local).
2. Pick concrete analytics + uptime tools — Resolved: self-hosted Umami + UptimeRobot (see monitoring-setup.md and umami-setup.md). Remaining manual follow-ups: actually deploying the Umami containers on the Pi, registering DNS/SSL for analytics.slpsoftware.nl, creating the UptimeRobot monitor, and setting the VITE_UMAMI_SCRIPT_URL/VITE_UMAMI_WEBSITE_ID_TEST (and, once production is set up, VITE_UMAMI_WEBSITE_ID_PRODUCTION) Gitea repository variables.

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.