diff --git a/betrieb/host-maintenance-notifications.md b/betrieb/host-maintenance-notifications.md
new file mode 100644
index 0000000..6941c82
--- /dev/null
+++ b/betrieb/host-maintenance-notifications.md
@@ -0,0 +1,55 @@
+---
+title: Host-Wartungsbenachrichtigungen
+description: Pre-Update-Mail & Matrix-Benachrichtigungen
+published: true
+date: 2026-08-13T18:04:30.981Z
+tags: 
+editor: markdown
+dateCreated: 2026-08-13T18:04:30.981Z
+---
+
+**Status**: ✅ Deployed + live getestet (2026-07-29/30, Closes Issue #24)
+**Konfiguration**: `host-config/maintenance-notify/` (nicht via Flux/GitOps deployt - läuft
+auf dem nackten Host, kein Kubernetes-Pod)
+
+## Überblick
+
+`unattended-upgrades` lief bereits aktiv auf dem Host (nur nie dokumentiert). Neu: eine
+Benachrichtigung **vor** dem täglichen Update-Lauf (`apt-daily-upgrade.timer`,
+06:00-07:00-Fenster), per E-Mail und Matrix, damit man weiß "gleich läuft ein Update" und im
+Störungsfall danach sofort den Zusammenhang sieht.
+
+Bewusst generisch gehalten (`host-config/maintenance-notify/` im Repo) - instanzspezifische
+Werte (Domain, Raum, Mail-Adressen) stecken in `/etc/maintenance-notify/config`, nicht im
+Skript. Volle Anleitung inkl. Stolpersteinen:
+[docs/deployment-guides/07-host-maintenance-notifications.md](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/src/branch/main/docs/deployment-guides/07-host-maintenance-notifications.md).
+
+## Architektur
+
+- Eigener systemd-Timer (`maintenance-notify.timer`, fest `05:00`, kein Randomize) läuft
+  **vor** dem echten Update-Fenster.
+- Skript prüft via `unattended-upgrade --dry-run -v`, ob überhaupt Pakete anstehen - wenn
+  nicht, keine Benachrichtigung (kein täglicher Alarm-Spam).
+- Zustellung nur bei anstehenden Updates: Mail via `msmtp`, Matrix via `curl` als Reply in
+  einem bestehenden Thread (`m.relates_to: m.thread`).
+- Bot-Account (`mas-cli register-user` + `issue-compatibility-token`, identisches Muster wie
+  Draupnir, siehe [Moderation-Content-Scanning](/betrieb/moderation-content-scanning)) muss dem
+  Zielraum **aktiv beitreten**, nicht nur eingeladen sein.
+
+## Stolpersteine (live gefunden)
+
+- **Port 465 kann ausgehend blockiert sein, 587 aber nicht** - bei axion1337.chat sowohl zu
+  IONOS als auch testweise zu Gmail (stiller Timeout statt Reject, typisch für eine
+  Cloud-Provider-Firewallregel). Vor Auth-Debugging erst TCP-Erreichbarkeit prüfen.
+- `msmtp`'s `passwordeval` übernimmt einen Trailing-Newline aus der Passwort-Datei wörtlich -
+  bricht die Auth. `printf %s "$(cat datei)" > datei` fixt das.
+- Mail-Domain ≠ Matrix-Domain möglich (bei axion1337: Mail unter `.de`, Matrix unter `.chat`) -
+  `MAIL_FROM` muss zur tatsächlichen Mail-Domain passen.
+- `MATRIX_HOMESERVER` ist oft eine eigene Subdomain (`matrix.axion1337.chat`), nicht die
+  Apex-Domain - vorher `.well-known/matrix/client` prüfen.
+
+## Beispiel: axion1337.chat
+
+Homeserver `matrix.axion1337.chat`, Raum "wartung" im Space "operating", Reply in
+vorhandenem Thread. Mail: `wartung@axion1337.de` über IONOS SMTP (`smtp.ionos.de:587`,
+STARTTLS) an die private Hauptadresse des Betreibers.