monitoring: Betriebsüberwachung Phase 1 — GlitchTip (Server- und Browserfehler), Fehlersignale ohne Exception, /health mit Scheduler-Herzschlag, ntfy-Alarme, fehlgeschlagene Anmeldungen im Verlauf, Umami im Kundenbereich, Versionsnummer

- GlitchTip über die Sentry-SDKs; Datenschutzfilter (nur User-ID, keine
  Request-Bodys, Tokens aus URL/Query/Referer, E-Mails aus Meldungen).
  Browser-SDK erst beim ersten Fehler nachgeladen.
- ReportErrorSignals: tote interne Links (404 mit eigenem Referrer), 403/429
  für Angemeldete, 419 als gedrosselte Warnung.
- /health (Bearer-Token): DB, Cache, Queue-Rückstau, Scheduler-Herzschlag,
  Plattenplatz → 200/503; Scheduler und Plattenplatz auch im Systemstatus.
- OperationalAlert zusätzlich per ntfy (JSON-POST), unabhängig von der Mail.
- Verlauf: login_failed (Grund unbekannt/kein Passwort/falsch),
  login_lockout, two_factor_failed; IP nur als gekürzter HMAC.
- Umami: Kundenbereich mit eigenem Schalter und identify('user-<id>'),
  nie im Admin/bei Impersonation; Query-Filter auch auf den Webseiten
  (signierte Links gingen bisher an Umami).
- queue:prune-failed nach 30 Tagen.
- Versionsnummer: config('app.version') aus APP_VERSION oder Datei RELEASE
  (git describe --tags), in GlitchTip, /health, Systemstatus, artisan about.

Plan: dev/betrieb/monitoring-plan.md (Entscheidungen M1–M9).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

routes/console.php

@@ -10,6 +10,7 @@ use App\Console\Commands\CheckMailDomains;
 use App\Console\Commands\ExpireGrandfathering;
 use App\Console\Commands\FetchMailBounces;
 use App\Console\Commands\GenerateManualInvoices;
+use App\Console\Commands\MonitoringHeartbeat;
 use App\Console\Commands\PublishScheduledPressReleases;
 use App\Console\Commands\PurgeConversionEvents;
 use App\Console\Commands\PurgeExpiredPressReleaseDrafts;
@@ -232,3 +233,22 @@ Schedule::command(RefreshMarketData::class)
     ->withoutOverlapping(15)
     ->runInBackground()
     ->onFailure($alertOnFailure('market:refresh'));
+
+// ========================================
+// Betriebsüberwachung (Monitoring-Plan Phase 1)
+// ========================================
+
+// Herzschlag: Fällt der Scheduler komplett aus (Cron weg, Server hängt),
+// greift kein onFailure mehr — dann meldet /health den fehlenden Herzschlag.
+Schedule::command(MonitoringHeartbeat::class)
+    ->everyMinute()
+    ->withoutOverlapping(2)
+    ->onFailure($alertOnFailure('monitoring:heartbeat'));
+
+// Fehlgeschlagene Jobs nach 30 Tagen entfernen (täglich 03:55). Bis dahin
+// sind sie im Systemstatus sichtbar und per `queue:retry` wiederholbar.
+Schedule::command('queue:prune-failed', ['--hours=720'])
+    ->dailyAt('03:55')
+    ->withoutOverlapping(30)
+    ->runInBackground()
+    ->onFailure($alertOnFailure('queue:prune-failed'));