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

Voeg self-hosted Umami analytics + UptimeRobot uptime dashboard toe

Browse Source 
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
Sluijsens
2026-07-25 19:59:40 +02:00
co-authored by Junie
parent da2a6e03ea
commit 08b489e305
15 changed files with 405 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/react-frontend/operations/monitoring/monitoring-setup.md
+34 -23
View File
@@ -25,38 +25,49 @@ The destination was not finalized (original Question 3 = C). Two supported optio
## Dashboards
### Website analytics
Pick one (all have generous free tiers suitable for a small marketing site):
### Website analytics — decided: self-hosted Umami
**Decided**: self-hosted Umami, running via Podman on the webserver Pi (Pi Main,
`192.168.1.103:3000`), reachable for the dashboard itself via `analytics.slpsoftware.nl`
(reverse-proxied + SSL via certbot, same pattern as `test.slpsoftware.nl`). Chosen over
GA4 for privacy-friendliness (typically no cookie banner needed) and full self-hosted
control, and over a hosted Umami/Plausible plan to avoid recurring cost.
| 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) |
- Full step-by-step setup: `operations/monitoring/umami-setup.md` (Podman/compose files,
systemd auto-start, reverse proxy + SSL, website registration).
- Example config: `operations/deployment/umami/podman-compose.yml.example` +
`.env.example`; `operations/deployment/nginx/analytics-nginx.conf.example`.
- The tracking script is injected client-side by `src/components/UmamiAnalytics.tsx`,
gated on two build-time variables (`VITE_UMAMI_SCRIPT_URL`, `VITE_UMAMI_WEBSITE_ID`),
wired into `continuous_integration.yaml`'s `Build` step as Gitea repository variables,
not secrets (same pattern as `VITE_SENTRY_DSN`). It never loads during local
development (`pnpm dev`), even if those variables happen to be set, so local testing
never pollutes visitor analytics.
- Key metrics to surface: unique visitors, page views per route (Home, Packages, etc. —
see `frontend-components.md`), and referral sources.
**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 — decided: UptimeRobot
**Decided**: 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`). Chosen over Better Uptime for its long-standing free tier and
simplicity for a single low-traffic site.
### Uptime dashboard
Pick one:
**Setup**:
1. Create a free UptimeRobot account (https://uptimerobot.com).
2. Register `test.slpsoftware.nl` as an HTTP(S) monitor now (checking for a `200`
response); add the production URL once hosting is finalized (see
`operations/deployment/deployment-plan.md` "Open Item") — still an open follow-up.
3. Optional: publish a public status page if desired for transparency to visitors.
4. Key metric to surface: uptime percentage / current status.
| 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.
No application code changes are needed for UptimeRobot — it works purely by polling the
public URL from the outside, entirely independent of the site's own codebase.
## 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 |
| Visitor/usage insight | Analytics dashboard (self-hosted Umami) | Tool decided; deployment (Podman on Pi Main + `analytics.slpsoftware.nl`) is a manual follow-up, see `umami-setup.md` |
| Site reachability | Uptime dashboard (UptimeRobot) | Tool decided; account creation + production URL are manual follow-ups |
| Alerting | Out of scope | Not configured |
| Shared infrastructure reuse | Out of scope | None exists yet |