slp-modular-cms/aidlc-docs/features/slpsoftware-api/operations/plans/monitoring-setup-plan.md

Monitoring Setup Plan — slpsoftware-api

Investigation (Before Drafting Anything)

Read gitea-deployment-workflow/operations/monitoring/monitoring-instructions.md in full, then checked whether anything this feature added (the Offerings module, the D-15 cutover) needs new or changed monitoring configuration.

• Sentry alert rules (FR-19, tag-based): the six existing rules filter on the security_event Sentry tag, not on message text or endpoint. Read SlpModularCms.Core.Hosting.ServiceCollectionExtensions.AddCmsRateLimiting's shared OnRejected callback — it calls SecurityEvents.RateLimitTriggered (tag rate_limit_triggered) for any rejected policy, by name, not per-policy-hardcoded. The new offerings-public policy added in Code Generation is therefore already covered by the existing rate_limit_triggered alert rule with zero new configuration.
• Authorization denials: read SecurityAuthorizationResultHandler.cs — it's a global IAuthorizationMiddlewareResultHandler, wired once in Core, firing authorization_denied (tag) for any policy failure on any endpoint. OfferingsController's AdminOnly-protected actions are covered automatically; nothing Offerings-specific needed wiring.
• No new alertable event type: NFR-OFF-03's audit logging (OfferingsService's LogInformation calls) was deliberately kept out of SecurityEvents/Sentry (see NFR Requirements' investigation) — routine content mutations are not alertable anomalies. Nothing to add here by design.
• UptimeRobot (D-23): the six monitors (/health, /, /admin × test/production) check domains and paths, not a specific .dll. They already point at test.slpsoftware.nl/ slpsoftware.nl — the D-15 cutover changes which process answers behind those URLs, invisible to a monitor that only checks the HTTP response. No new monitor needed; the public GET /api/v1/offerings endpoint was never in scope for dedicated uptime monitoring (D-23 covers liveness/static-hosting/admin-SPA checks only, not every individual API route).
• Umami: two website entries for the admin SPA, same URLs before and after the cutover. No change.
• Gitea variables: VITE_SENTRY_DSN, VITE_UMAMI_*, SECURITY_ALLOWED_SCRIPT_ORIGINS_* all already exist and are unaffected — same Sentry project (D-19), same Umami instance, same CSP origins, none of which are tied to which project publishes the artifact.

Why No Questions, No New Configuration

Every piece of monitoring infrastructure this feature could plausibly need is already covered by gitea-deployment-workflow's existing, tag-based/domain-based design — none of it hardcodes a project name or is scoped to a specific endpoint in a way the cutover or the new module would break. This stage's output is a documented confirmation, not new setup.

Checklist

• Create operations/monitoring/monitoring-instructions.md as a feature-local pointer document recording this investigation and its "no changes needed" conclusion, so a future reader isn't left wondering whether Offerings' monitoring was simply forgotten