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
1.9 KiB
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.