# 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.