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

Merge branch 'master' into feature/analytics_uptime_dashboard

Browse Source 
# Conflicts:
#	.env.example
#	aidlc-docs/features/react-frontend/aidlc-state.md
#	aidlc-docs/features/react-frontend/audit.md
#	aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md
#	aidlc-docs/features/react-frontend/operations/monitoring/monitoring-setup.md
#	aidlc-docs/features/react-frontend/operations/production-readiness-checklist.md
#	src/components/RootLayout.tsx
#	src/vite-env.d.ts
This commit is contained in:
Sluijsens
2026-07-25 20:14:16 +02:00
parent 08b489e305 48bde56ed6
commit 844a470c18
26 changed files with 619 additions and 128 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md
+2 -2
View File
@@ -13,7 +13,7 @@ Initial answers to the monitoring plan were contradictory: Question 2 selected "
## 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.
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:
@@ -27,7 +27,7 @@ A combination of:
- **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.
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` Gitea repository variables.
## Rationale