SLP_Software/slp-modular-cms
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Wiki Activity

Completes Operations phase: Monitoring Setup and Production Readiness Validation

Browse Source 
Confirms existing tag-based Sentry alerting and domain-based UptimeRobot/
Umami monitoring already cover the Offerings module and the Api.SlpSoftware
cutover with no new configuration. Closes the SECURITY-13 audit-trail open
item and records the final production-readiness traceability, completing
the slpsoftware-api feature's AI-DLC lifecycle.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
This commit is contained in:
Sluijsens
2026-08-02 16:35:00 +02:00
co-authored by Claude Sonnet 5
parent cfb06b28b6
commit 81af6cd151
7 changed files with 223 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/slpsoftware-api/operations/monitoring/monitoring-instructions.md
+26
View File
@@ -0,0 +1,26 @@
# Monitoring Setup — slpsoftware-api
This feature does not own separate monitoring infrastructure. Per the same "extend, don't duplicate"
relationship as Deployment Setup, all monitoring for `slpsoftware.nl`/`test.slpsoftware.nl` is
already built and configured by `gitea-deployment-workflow`:
- `aidlc-docs/features/gitea-deployment-workflow/operations/monitoring/monitoring-instructions.md`
## Conclusion: No New Configuration Needed
Investigated (see `operations/plans/monitoring-setup-plan.md` for the full trace) whether the
Offerings module or the D-15 CI/CD cutover require any change to Sentry alert rules, UptimeRobot
monitors, or Umami — they do not:
| Area | Why it's already covered |
|---|---|
| Sentry alert rules (`rate_limit_triggered` tag) | `AddCmsRateLimiting`'s shared rejection handler fires this tag for **any** policy by name, including the new `offerings-public` policy — no per-policy wiring exists to update |
| Sentry alert rules (`authorization_denied` tag) | A single global `IAuthorizationMiddlewareResultHandler` in Core fires this tag for **any** policy failure on **any** endpoint, including `OfferingsController`'s `AdminOnly` actions |
| UptimeRobot (`/health`, `/`, `/admin` × test/production) | Checks domains/paths, not a specific `.dll` — the cutover changes which process answers, invisible to an HTTP-status monitor |
| Umami (admin SPA website entries) | Same URLs before and after the cutover |
| Gitea variables (`VITE_SENTRY_DSN`, `VITE_UMAMI_*`, `SECURITY_ALLOWED_SCRIPT_ORIGINS_*`) | Already set, tied to the Sentry project/Umami instance/CSP config, not to which project publishes the artifact |
`OfferingsService`'s own audit logging (`LastModifiedByUserId`, structured `LogInformation` on
create/update/delete — NFR-OFF-03) was deliberately **not** routed through `SecurityEvents`/Sentry:
it logs routine content changes, not alertable anomalies. This was a considered decision at NFR
Requirements, not a monitoring gap.