Healthchecks auf dem Synology NAS installieren: Cronjobs und Backups überwachen

Dein Backup-Cronjob läuft jeden Nacht um 2 Uhr – oder zumindest sollte er das. Uptime-Monitoring wie Uptime Kuma prüft, ob ein Dienst antwortet, aber es bemerkt nicht, wenn ein Backup-Skript lautlos fehlschlägt oder schlicht nie gestartet wird. Genau hier setzt Healthchecks an: Das Open-Source-Projekt arbeitet nach dem Dead-Man-Switch-Prinzip. Jeder überwachte Job sendet nach erfolgreichem Lauf einen HTTP-Ping – bleibt dieser Ping aus, schlägt Healthchecks Alarm. Für KMUs und ambitionierte Selfhoster, die Backup-, Wartungs- und Sync-Skripte auf dem Synology NAS zuverlässig überwachen wollen, ist das die fehlende Ergänzung zum klassischen Uptime-Monitoring.

Voraussetzungen

1. Synology NAS mit DSM 7.2 oder höher (x86_64 oder ARM64)
2. Container Manager aus dem Paket-Zentrum installiert
3. SSH-Zugang zum NAS (für SECRET_KEY-Generierung und docker compose exec) – Schritt für Schritt: SSH auf dem Synology NAS aktivieren und verbinden
4. Domain oder Synology DDNS-Subdomain (z. B. healthchecks.meinname.synology.me) für den Reverse-Proxy-Zugang
5. SMTP-Zugangsdaten – empfohlen: Gmail App-Passwort oder eigener Mailserver
6. Ca. 300 MB freier RAM und ca. 500 MB freier Speicher auf /volume1

Eckdaten auf einen Blick

Schritt 1: Ordner anlegen

Öffne die File Station im DSM und navigiere zu docker. Erstelle dort einen Unterordner healthchecks, und darin zwei weitere Ordner: data und db. Achte auf Kleinschreibung. Alternativ kannst du die Ordner per SSH anlegen – die ausführliche Erklärung zu Docker-Ordnern und Berechtigungen auf Synology findest du in der Anleitung Docker-Ordner und Berechtigungen auf dem Synology NAS.

# Per SSH (optional):
mkdir -p /volume1/docker/healthchecks/data
mkdir -p /volume1/docker/healthchecks/db

Verifizieren: In der File Station existieren die Pfade docker/healthchecks/data und docker/healthchecks/db. Beide Ordner sind leer.

Schritt 2: SECRET_KEY generieren

Der SECRET_KEY sichert alle HTTP-Sessions. Er darf niemals leer bleiben oder ein Standardwert sein. Verbinde dich per SSH mit dem NAS und führe einen der folgenden Befehle aus:

openssl rand -hex 32
# Alternativ, falls openssl nicht verfügbar:
python3 -c "import secrets; print(secrets.token_hex(32))"

Die Ausgabe ist eine 64-stellige Hexadezimalzeichenkette. Kopiere diesen Wert – du trägst ihn im nächsten Schritt in die compose.yaml ein.

Verifizieren: Die Ausgabe hat genau 64 Zeichen. Prüfen mit: openssl rand -hex 32 | wc -c (Ergebnis: 65, weil der Zeilenumbruch mitgezählt wird – der eigentliche Schlüssel hat 64 Zeichen).

Schritt 3: compose.yaml erstellen

Erstelle im Container Manager ein neues Projekt namens healthchecks und gib folgenden Inhalt als compose.yaml ein. Ersetze alle GROSSGESCHRIEBENEN Platzhalter durch deine echten Werte. Wie du ein Compose-Projekt im Container Manager anlegst, erklärt die Grund-Anleitung Container Manager auf dem Synology NAS: Docker-Compose-Projekt anlegen.

services:
  healthchecks-db:
    image: postgres:16
    container_name: healthchecks-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: hc
      POSTGRES_PASSWORD: SICHERES_DB_PASSWORT
    volumes:
      - /volume1/docker/healthchecks/db:/var/lib/postgresql/data

  healthchecks:
    image: healthchecks/healthchecks:v4.2
    container_name: healthchecks
    restart: unless-stopped
    depends_on:
      - healthchecks-db
    ports:
      - "8080:8000"
    environment:
      # Datenbank
      DB: postgres
      DB_HOST: healthchecks-db
      DB_PORT: 5432
      DB_NAME: hc
      DB_USER: hcuser
      DB_PASSWORD: SICHERES_DB_PASSWORT
      # Kernsettings
      SECRET_KEY: DEIN_64_ZEICHEN_SCHLUESSEL
      ALLOWED_HOSTS: nas.local,healthchecks.meinname.synology.me
      SITE_ROOT: https://healthchecks.meinname.synology.me
      SITE_NAME: Healthchecks
      DEBUG: "False"
      REGISTRATION_OPEN: "False"
      # E-Mail (SMTP)
      DEFAULT_FROM_EMAIL: healthchecks@example.com
      EMAIL_HOST: smtp.gmail.com
      EMAIL_HOST_USER: mein-konto@gmail.com
      EMAIL_HOST_PASSWORD: GMAIL_APP_PASSWORT
      EMAIL_PORT: 587
      EMAIL_USE_TLS: "True"
      EMAIL_USE_SSL: "False"
      # Performance (NAS-optimiert)
      UWSGI_PROCESSES: "2"

Wichtige Hinweise zu den Werten:

1. Image-Tag: Das versionierte Tag v4.2 wird gegenüber :latest empfohlen, damit unerwartete Breaking-Change-Updates ausbleiben.
2. postgres:16 ist das vom offiziellen Healthchecks-Projekt referenzierte Image – nicht postgres:18.
3. ALLOWED_HOSTS: Trage sowohl die lokale NAS-Adresse als auch die externe Subdomain ein. Fehlt ein Hostname, antwortet Django mit HTTP 400.
4. Gmail-SMTP: Das normale Kontopasswort wird abgelehnt. Du benötigst ein Google App-Passwort (Google-Konto → Sicherheit → 2-Schritt-Verifizierung → App-Passwörter).
5. EMAIL_USE_TLS und EMAIL_USE_SSL dürfen niemals beide auf True stehen – das führt zu einem Django-Konfigurationsfehler. Für Port 587 gilt: TLS=True, SSL=False.

Verifizieren: Der Container Manager zeigt das Projekt healthchecks mit zwei Services. Die compose.yaml enthält keinen Platzhalter mehr in GROSSBUCHSTABEN.

Schritt 4: Container starten und Migrationen abwarten

Starte das Projekt im Container Manager. Healthchecks führt beim ersten Start automatisch die Django-Datenbankmigrationen durch – du musst kein manuelles migrate ausführen. Verfolge den Startvorgang per SSH:

docker logs -f healthchecks

Warte, bis du eine Zeile wie diese siehst:

spawned uWSGI master process
spawned uWSGI worker 1 (pid: ...)
spawned uWSGI worker 2 (pid: ...)

Verifizieren: Beide Container laufen (grüner Status im Container Manager). Die uWSGI-Worker-Meldung ist in den Logs sichtbar. Öffne http://NAS-IP:8080 im Browser – die Healthchecks-Anmeldeseite erscheint.

Schritt 5: Superuser anlegen

Jetzt, wo die Container laufen und die Migrationen abgeschlossen sind, legst du den Admin-Account an. Verbinde dich per SSH und führe aus:

docker exec -it healthchecks /opt/healthchecks/manage.py createsuperuser

Du wirst nach Benutzername, E-Mail-Adresse und Passwort gefragt. Wähle ein starkes Passwort. Anschließend starte den Container neu, damit REGISTRATION_OPEN=False greift:

docker restart healthchecks

Verifizieren: Öffne das Web-Interface unter http://NAS-IP:8080 und melde dich mit den Superuser-Zugangsdaten an. Das Dashboard mit der leeren Check-Übersicht erscheint.

Schritt 6: Reverse Proxy und HTTPS einrichten

Healthchecks übernimmt kein TLS selbst – für HTTPS benötigst du einen Reverse Proxy. Im DSM gehst du zu Systemsteuerung → Anmeldeportal → Erweitert → Reverse Proxy und legst eine neue Regel an:

1. Quelle: HTTPS, Hostname healthchecks.meinname.synology.me, Port 443
2. Ziel: HTTP, Hostname localhost, Port 8080

Füge unter „Benutzerdefinierte Header“ diese beiden Header hinzu, damit Healthchecks das HTTPS-Schema korrekt erkennt und keine http://-Links in E-Mails generiert:

Falls du stattdessen den Nginx Proxy Manager nutzt, findest du die detaillierte Einrichtung in der Anleitung Nginx Proxy Manager auf der Synology mit Container Manager einrichten.

Verifizieren: Öffne https://healthchecks.meinname.synology.me im Browser. Das Schloss-Symbol erscheint, das Zertifikat ist gültig, und du erreichst die Anmeldeseite über HTTPS.

Schritt 7: Ersten Check anlegen und Ping testen

Melde dich im Healthchecks-Dashboard an und klicke auf + Add Check. Vergib einen sprechenden Namen (z. B. „NAS Backup täglich“), wähle den Schedule (z. B. täglich um 02:00 Uhr als Cron-Expression 0 2 * * *) und stelle eine Grace-Period von z. B. 30 Minuten ein – so werden kurze Verzögerungen nicht als Alarm gewertet. Eine Einführung in Cron-Expressions findest du in der Anleitung Cron und crontab richtig nutzen – die Grundlagen.

Nach dem Speichern siehst du die Ping-URL des Checks. Teste jetzt aus der SSH-Konsole des NAS, ob der Ping ankommt:

curl -fsS -m 10 --retry 5 \
  https://healthchecks.meinname.synology.me/ping/DEINE-UUID > /dev/null \
  && echo "Ping erfolgreich" || echo "Ping fehlgeschlagen"

Hinweis zum Loopback-Problem: Falls DNS-Rebinding durch deinen Router blockiert wird, schlägt der interne Ping auf die externe URL fehl. Nutze dann die direkte Container-URL:

curl -fsS -m 10 http://localhost:8080/ping/DEINE-UUID > /dev/null

Verifizieren: Die curl-Ausgabe lautet „Ping erfolgreich“. Im Healthchecks-Dashboard wechselt der Check-Status von „New“ auf „Up“ (grüner Status). Das bestätigt, dass der Ping korrekt empfangen wurde.

Schritt 8: Backup-Skript integrieren (Dead-Man-Switch)

Das Dead-Man-Switch-Prinzip in der Praxis: Hänge den curl-Ping-Befehl mit && ans Ende deines Backup-Skripts. Das && stellt sicher, dass der Ping nur bei erfolgreichem Backup-Lauf gesendet wird. Schlägt das Backup fehl, bleibt der Ping aus – und Healthchecks löst nach Ablauf der Grace-Period einen Alarm aus. Wie du solche Backup-Skripte für PostgreSQL-Datenbanken aufbaust und automatisierst, zeigt die Anleitung MySQL & PostgreSQL Backup automatisieren mit cron.

#!/bin/bash
# Beispiel: tägliches Backup mit anschließendem Healthchecks-Ping

BACKUP_SRC="/volume1/wichtige-daten"
BACKUP_DST="/volume2/backup/$(date +%Y-%m-%d)"

rsync -a --delete "$BACKUP_SRC" "$BACKUP_DST" \
  && curl -fsS -m 10 --retry 5 \
     https://healthchecks.meinname.synology.me/ping/DEINE-UUID \
     > /dev/null

Für noch mehr Transparenz kannst du auch den Exit-Code mitsenden – Healthchecks interpretiert Exit-Code 0 als Erfolg, alles andere als Fehler:

rsync -a --delete "$BACKUP_SRC" "$BACKUP_DST"
curl -fsS -m 10 \
  https://healthchecks.meinname.synology.me/ping/DEINE-UUID/$? \
  > /dev/null

Verifizieren: Führe das Skript manuell aus. Im Dashboard zeigt der Check nach dem Lauf „Last ping: a few seconds ago“ und bleibt auf Status „Up“. Teste den Fehlerfall: Entferne testweise den Ping und warte die Grace-Period ab – der Status wechselt auf „Late“, dann auf „Down“, und eine Alarm-E-Mail trifft ein.

Schritt 9: Benachrichtigungskanal einrichten

Healthchecks bietet über 25 Integrationen. E-Mail ist nach der SMTP-Konfiguration bereits aktiv. Für Push-Benachrichtigungen empfiehlt sich ntfy: Im Dashboard unter Integrations → Webhook trägst du die Webhook-URL deiner ntfy-Instanz ein (z. B. https://ntfy.sh/mein-topic), wählst HTTP-Methode POST und speicherst. Wenn du ntfy noch nicht auf dem Synology NAS eingerichtet hast, hilft die Anleitung ntfy auf dem Synology NAS installieren: Push-Benachrichtigungen für Server und Skripte.

Für einen schnellen Alarm-Test klicke im Dashboard auf den Check-Namen und dann auf Send Test Alert – so prüfst du, ob die Benachrichtigungskette lückenlos funktioniert, ohne auf einen echten Fehler warten zu müssen.

Verifizieren: Nach dem Klick auf „Send Test Alert“ trifft innerhalb weniger Sekunden eine Test-E-Mail (und/oder eine ntfy-Push-Meldung) ein. Der Betreff enthält den Check-Namen und den Status.

Troubleshooting / Typische Fehler

1. HTTP 400 „Bad Request“ beim Öffnen des Web-Interface: Der aufgerufene Hostname fehlt in ALLOWED_HOSTS. Füge alle verwendeten Hostnamen und IPs kommagetrennt ein, z. B. localhost,nas.local,healthchecks.meinname.synology.me, und starte den Container neu.
2. Container startet sofort neu (Restart-Loop): Der Healthchecks-Container kann nicht mit der Datenbank verbinden, weil der PostgreSQL-Container noch nicht bereit ist. Mit restart: unless-stopped startet Docker den Container automatisch neu, bis die DB verfügbar ist. Prüfe mit docker logs healthchecks-db, ob PostgreSQL vollständig initialisiert ist.
3. Gmail SMTP: „535 Authentication failed“: Das normale Gmail-Kontopasswort wird für SMTP-Anmeldungen blockiert. Voraussetzung: 2-Faktor-Authentifizierung im Google-Konto aktivieren, dann unter „App-Passwörter“ ein neues App-Passwort für „Mail“ generieren und diesen 16-stelligen Code als EMAIL_HOST_PASSWORD eintragen.
4. Links in E-Mails beginnen mit http:// statt https://: Die Reverse-Proxy-Header X-Forwarded-Proto: https und X-Real-IP: $remote_addr fehlen. Trage sie im DSM Reverse Proxy unter „Benutzerdefinierte Header“ nach.
5. createsuperuser schlägt mit Verbindungsfehler fehl: Der Befehl wurde ausgeführt, bevor der Container vollständig gestartet war. Warte, bis docker logs healthchecks die uWSGI-Worker-Meldung zeigt, und führe den Befehl erst danach aus.
6. Interner curl-Ping schlägt fehl (DNS-Rebinding): Der Router blockiert DNS-Rebinding auf die externe Subdomain. Nutze http://localhost:8080/ping/UUID im Backup-Skript, wenn das Skript auf demselben NAS läuft.
7. EMAIL_USE_TLS und EMAIL_USE_SSL beide True: Das führt zu einem Django-Konfigurationsfehler beim Start. Für Port 587: EMAIL_USE_TLS=True und EMAIL_USE_SSL=False. Für Port 465: genau umgekehrt.

Häufige Fragen

Was ist der Unterschied zwischen Healthchecks und Uptime Kuma?

Uptime Kuma überwacht, ob ein Dienst oder eine URL erreichbar ist (aktive Abfrage von außen). Healthchecks überwacht, ob ein Job gelaufen ist – also ob ein Prozess selbst einen Ping sendet. Beide Ansätze ergänzen sich: Uptime Kuma erkennt, wenn der NAS-Webserver nicht antwortet; Healthchecks erkennt, wenn das Backup-Skript nicht ausgeführt wurde oder mit einem Fehler endete.

Kann ich mehrere Checks für verschiedene Skripte anlegen?

Ja, beliebig viele. Jeder Check hat eine eigene UUID-basierte Ping-URL, einen eigenen Schedule und eine eigene Grace-Period. Du kannst Checks in Projekten gruppieren und mehrere Benutzer hinzufügen – praktisch, wenn mehrere Admins benachrichtigt werden sollen.

Wie sichere ich die Healthchecks-Daten?

Schließe die Ordner /volume1/docker/healthchecks/db und /volume1/docker/healthchecks/data in deinen Synology Hyper Backup-Plan ein. Für ein konsistentes Datenbank-Backup ohne Container-Stopp empfiehlt sich pg_dump:

docker exec healthchecks-db pg_dump -U hcuser hc > healthchecks_backup.sql

Kann ich Healthchecks ohne externen SMTP betreiben?

Für erste Tests ja: Setze DEBUG=True und REGISTRATION_OPEN=True, dann schreibt Django E-Mails in die Container-Logs statt sie zu versenden. Für den Produktivbetrieb ist SMTP Pflicht, da Aktivierungs-E-Mails und Alarme per E-Mail versendet werden. Setze nach dem Test unbedingt DEBUG=False und REGISTRATION_OPEN=False zurück.

Wie aktualisiere ich Healthchecks auf eine neue Version?

Passe das Image-Tag in der compose.yaml auf die neue Version an (z. B. healthchecks/healthchecks:v4.3), speichere die Datei und klicke im Container Manager auf „Aktualisieren“. Healthchecks führt beim nächsten Start automatisch ausstehende Datenbankmigrationen durch. Mache vorher ein Backup der Datenbank.

Welche Ping-URL-Varianten gibt es?

Neben dem einfachen Success-Ping gibt es weitere Varianten für präziseres Monitoring:

1. /ping/UUID – Erfolgreicher Abschluss
2. /ping/UUID/start – Job gestartet (Healthchecks erkennt so auch hängende Jobs)
3. /ping/UUID/fail – Expliziter Fehler
4. /ping/UUID/$? – Exit-Code mitsenden (0 = Erfolg, alles andere = Fehler)

Fazit

Healthchecks schließt eine typische Monitoring-Lücke, die Uptime-Tools offen lassen: den stillen Cronjob-Ausfall. Mit dem Compose-Projekt auf dem Synology NAS ist der Dienst in rund 35 Minuten betriebsbereit, und jedes Backup-Skript lässt sich mit einer einzigen curl-Zeile überwachen. Der Dead-Man-Switch ist kein Nice-to-have – er ist das letzte Netz, das auffängt, wenn ein Backup-Job aus welchem Grund auch immer ausbleibt. Wer seine Backup-Strategie ernst nimmt, sollte Healthchecks als festen Bestandteil des Monitoring-Stacks betrachten.

Weiterführende Anleitungen und Quellen

1. Cron und crontab richtig nutzen – die Grundlagen – Cron-Expressions und Scheduling auf Linux verstehen
2. MySQL & PostgreSQL Backup automatisieren mit cron: mysqldump, pg_dump, Rotation und rclone-Cloud-Sync – Backup-Skripte, die du mit Healthchecks überwachen kannst
3. ntfy auf dem Synology NAS installieren: Push-Benachrichtigungen für Server und Skripte – Healthchecks-Alarme als Push-Meldung aufs Smartphone
4. Checkmk auf dem Synology NAS installieren: professionelles IT-Monitoring – umfassendes IT-Monitoring als Ergänzung zum Cronjob-Monitoring
5. Nginx Proxy Manager auf der Synology mit Container Manager einrichten: Reverse Proxy und SSL – HTTPS-Termination für Healthchecks

Offizielle Dokumentation und Quellen: Healthchecks.io – Running with Docker, GitHub: healthchecks/healthchecks, Docker Hub: healthchecks/healthchecks Tags.