kimi.md: taeglicher Gesundheitscheck (Cronjob auf VPS) dokumentiert

kimi.md

@@ -895,3 +895,10 @@ Zustellung an axel@hocks.eu status=sent, Test-Ticket bereinigt.
 - Erledigt: sfg-postfix identisch nachgerüstet — `nichtantworten@fv-sfg.de → axel@hocks.eu` (lmdb-Virtual-Alias). Kein Loop-Verkehr in 72 h sichtbar, SMTP-EHLO von sfg-mail-api ok, Queue leer, 45 s Beobachtung ohne Bounces. Env/Netz/Restart-Policy des Containers übernommen.
 - Retry-Härtung mp-mail-api (`/opt/mp-mail/api/server.py`, nur Server): `/send` legt bei JEDEM Fehler (statt nur OSError) in die Outbox; Worker loggt VERSANDT OK / Fehlversuche / ALARM nach 10 Versuchen (sichtbar in docker logs); erfolgreiche und endgültig gescheiterte Einträge werden entfernt. **Race-Fix:** Outbox-Laden/Speichern unter Lock — zuvor rasten 2 parallele /send-Aufrufe (Registrierung sendet 2 Verwaltungs-Mails gleichzeitig) zu korruptem outbox.json mit Eintragverlust (real aufgetreten 17:38, „Extra data"). Korrupte Datei archiviert (`/data/outbox.json.corrupt-20261007`). Retry-Mechanik isoliert getestet (Fehler→Outbox→Zähler→Erfolg-Entfernung: alle Schritte bestanden); Live-Sofortversand weiterhin ok (status=sent). sfg-Mail-API hat denselben Mechanismus bereits eingebaut — dort nichts zu tun.
 
+
+## 2026-10-07 — Gesundheitscheck als Cronjob auf dem VPS
+
+- `/opt/mieterportal/mp-healthcheck.sh`, täglich 07:17 Uhr Serverzeit (`17 7 * * *` in root-crontab; Server = UTC, also 09:17 deutsche Zeit).
+- Prüft: Container laufen (mp-portal/api/db/mail/mail-api/ocr), mp-api-Health, Portal-HTTPS (200), Mailqueues mp-mail + sfg-mail (Schwellenwert 5), Diskbelegung (Schwellenwert 85%).
+- Nur bei Auffälligkeiten ALARM-Mail an axel@hocks.eu über das Mail-Relay (Token aus /opt/mp-mail/mail.env); jeder Lauf schreibt eine Zeile nach `/var/log/mp-healthcheck.log`.
+- Probelauf nach Fix ok (Queues 0, Disk 8%, Portal 200); Alarm-Pfad durch Fehlalarm beim Ersttest verifiziert (grep -c || echo lieferte „0 0", behoben mit `|| q=0` außerhalb).