slp-modular-cms/aidlc-docs/features/gitea-deployment-workflow/operations/plans/monitoring-setup-plan.md

Monitoring Setup Plan

Context already established (not re-asked)

The observability stack and what it must cover were already decided in Requirements Analysis and built during Construction (U4) — this stage is about configuring the real external services and writing the operational documentation, not re-deciding the approach:

• Stack: Sentry (backend Sentry.AspNetCore + frontend @sentry/react), self-hosted Umami analytics, UptimeRobot uptime monitoring (D-18, D-24, requirements.md § "Monitoring and observability")
• Sentry projects: one project for the whole CMS, environment tag distinguishes test/production (D-19) — so one DSN, reused by both environments and both frontend/backend
• Sentry is optional by design: an absent DSN disables it cleanly, console logging stays active (BR-U4-08) — nothing breaks if a value is left blank temporarily
• Alertable events already exist in code: six security_event tag values are emitted today — failed_login, authorization_denied, master_api_key_rejected, admin_bypass_rejected, rate_limit_triggered, migration_failure (SecurityEvents.cs). Alert rules must filter on the security_event tag, not message text (nfr-design-patterns.md Pattern 6) — this is explicitly named as Operations — Monitoring Setup work in logical-components.md (FR-19)
• UptimeRobot scope: /health, / (public website) and /admin, per environment — 6 monitors total (D-23)
• Umami scope: reuse the existing self-hosted instance at analytics.slpsoftware.nl, add new website entries for this CMS rather than standing up a new instance (D-24/ASM-05). Both the admin SPA (via VITE_UMAMI_WEBSITE_ID_<ENV>, built by this pipeline) and the public website (via the separate website-workspace, FR-09/FR-16, out of this pipeline's scope) are measured (D-25) — this stage only configures the admin SPA's two website entries; the public website's Umami wiring belongs to whichever website workspace serves it
• Health endpoint: liveness only, no DB check, already built and already on the AvailabilityMiddleware bypass list (D-21) — nothing left to build, only to point UptimeRobot at
• Log retention deviation: accepted knowingly (DEV-01) — Sentry's ~30-day retention against the 90-day SECURITY-14 minimum. No action here beyond documenting it.

Question 1: Include Monitoring Setup?

Given U4 built all the alertable-event plumbing specifically so that Operations could wire up real alert rules and monitors on top of it, declining this stage would leave that code inert — events would be emitted into a Sentry project that doesn't exist yet, with no alert rule reading the tag, and no UptimeRobot monitor watching /health. Recommended: A.

A) Yes — configure the real services and document it (Recommended) B) No — monitoring is handled elsewhere or not needed C) Not sure — suggest an approach and I'll decide

X) Other (please describe after Answer: tag below)

Question 2: Monitoring Method

Confirms the stack already decided in Requirements Analysis — asked per the mandatory format, not because it's genuinely open.

A) Sentry + self-hosted Umami + UptimeRobot, exactly as scoped above (Recommended) B) Something else entirely — describe below

X) Other (please describe after Answer: tag below)

---

The remaining questions are the genuinely open items — real account/service facts that only you know, which nothing in Construction could decide for you.

Question 3: Sentry Project

Does a Sentry project for this CMS already exist (e.g. created ad hoc while testing U4 locally), or does this stage need to walk through creating one from scratch?

A) Already exists — I'll provide the DSN after Answer: below B) Doesn't exist yet — walk me through creating one (org, project platform picks for .NET + React, where to find the DSN afterward) C) Not yet, and I'd rather set it up myself later — document it as a TODO with exactly which Gitea secrets/variables need the DSN once it exists

X) Other (please describe after Answer: tag below)

Answer:A — DSN to be added directly to the Gitea secret/variable once shared (kept out of this doc)

Question 4: Sentry Alert Rule Thresholds

FR-19 requires alert rules for repeated auth failures and authorization violations, filtering on the security_event tag (values: failed_login, authorization_denied, master_api_key_rejected, admin_bypass_rejected, rate_limit_triggered; migration_failure is Critical-level and worth its own always-fire rule regardless of count). What threshold should the repeated-failure rules use?

A) A single reasonable default for all of them (e.g. 20 occurrences in 5 minutes) — document it as a starting point, tune later from real traffic (Recommended) B) I'll specify exact thresholds per event type — describe below C) No count threshold — alert on every occurrence of each of the six (noisier, but nothing is ever missed)

X) Other (please describe after Answer: tag below)

Question 5: UptimeRobot Account and Alert Contacts

6 monitors are needed (/health, /, /admin × test/production). Do you have an UptimeRobot account already (e.g. from the reference SlpSoftware project), and where should alerts go?

A) Existing account, reuse it — alert contact(s): describe after Answer: below (email, and/or any other channel already configured there) B) Need a new account/monitor group set up from scratch — walk me through it C) Not sure yet — document the 6 monitors' exact URLs and recommended check interval as a checklist, I'll create them myself

X) Other (please describe after Answer: tag below)

Answer:A — existing account, alert contact to be confirmed

Question 6: Umami Website Entries (Admin SPA)

Two new website entries are needed on the existing analytics.slpsoftware.nl instance — one per environment — to obtain the VITE_UMAMI_WEBSITE_ID_TEST/_PRODUCTION values the CI workflow already expects as Gitea variables (continuous_integration.yaml reads vars.VITE_UMAMI_WEBSITE_ID_TEST/ _PRODUCTION).

A) I have access to the Umami instance — I'll create the two entries and provide the website IDs after Answer: below B) Walk me through creating them (Umami's own UI/API steps) C) Not yet — document it as a TODO with the exact variable names the pipeline expects, I'll fill them in before the first real deploy

X) Other (please describe after Answer: tag below)

Answer:A — website IDs to be added directly to Gitea variables once created (kept out of this doc)