Files
slp-modular-cms/aidlc-docs/features/slpsoftware-api/operations/monitoring/monitoring-instructions.md
T
SluijsensandClaude Sonnet 5 81af6cd151 Completes Operations phase: Monitoring Setup and Production Readiness Validation
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
2026-08-02 16:35:00 +02:00

1.9 KiB
Raw Blame History

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.