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

Uptime-Monitoring wie Uptime Kuma prüft, ob ein Dienst antwortet. Es bemerkt nicht, wenn Ihr nächtliches Backup-Skript lautlos fehlschlägt oder nie startet. Healthchecks arbeitet nach dem Dead-Man-Switch-Prinzip: Jeder überwachte Job sendet nach erfolgreichem Lauf einen HTTP-Ping, bleibt der Ping aus, meldet Healthchecks einen Alarm. Diese Anleitung richtet Healthchecks auf dem Synology NAS ein und bindet ein Backup-Skript an.

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

Öffnen Sie die File Station und wechseln Sie in den Ordner docker. Legen Sie dort healthchecks an und darin die Ordner data und db (Kleinschreibung beachten). Details zu Docker-Ordnern und Berechtigungen stehen 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 weder leer noch ein Beispielwert sein. Verbinden Sie sich per SSH mit dem NAS und führen Sie einen der folgenden Befehle aus:

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

Kopieren Sie die Ausgabe für die compose.yaml.

Verifizieren: Die Ausgabe hat genau 64 Zeichen. Prüfen mit: openssl rand -hex 32 | wc -c (Ergebnis: 65, der Zeilenumbruch zählt mit).

Schritt 3: compose.yaml erstellen

Legen Sie im Container Manager unter Projekt → Erstellen das Projekt healthchecks mit dem Pfad /volume1/docker/healthchecks an und fügen Sie folgenden Inhalt als compose.yaml ein. Ersetzen Sie alle GROSSGESCHRIEBENEN Platzhalter. Grundlagen zu Projekten erklärt die 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_USER: hcuser
      POSTGRES_PASSWORD: SICHERES_DB_PASSWORT
    volumes:
      - /volume1/docker/healthchecks/db:/var/lib/postgresql/data

  healthchecks:
    image: healthchecks/healthchecks:v5.0.1
    container_name: healthchecks
    restart: unless-stopped
    depends_on:
      - healthchecks-db
    ports:
      - "127.0.0.1:8080:8000"   # nur lokal, Zugriff über den DSM-Reverse-Proxy
    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: IHR_64_ZEICHEN_SCHLUESSEL
      ALLOWED_HOSTS: localhost,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)
      GUNICORN_WORKERS: "2"

Wichtige Hinweise zu den Werten:

1. Image-Tag: Das feste Tag v5.0.1 (Stand 24.10.2026) statt :latest verhindert ungeplante Updates mit Breaking Changes.
2. GUNICORN_WORKERS: Ab v5.0 läuft im Image gunicorn statt uWSGI. Die Variable legt die Zahl der Worker fest; zwei reichen auf einem NAS. Fehlt sie, übernimmt das Startskript /opt/healthchecks/run.sh den alten Wert aus UWSGI_PROCESSES, ohne beide Variablen startet es vier Worker.
3. postgres:16 ist das Image aus der offiziellen Compose-Datei des Projekts. Ab v4.4 (Django 6.1) braucht Healthchecks mindestens PostgreSQL 15.
4. POSTGRES_USER muss zu DB_USER passen. Ohne diese Zeile legt PostgreSQL nur den Benutzer postgres an und Healthchecks kann sich nicht anmelden.
5. Port: Die Bindung an 127.0.0.1 hält die unverschlüsselte HTTP-Oberfläche aus dem LAN heraus, erreichbar ist sie nur über den Reverse Proxy aus Schritt 6.
6. ALLOWED_HOSTS: Tragen Sie localhost (für Pings vom NAS selbst) und die Subdomain ein. Fehlt ein Hostname, antwortet Django mit HTTP 400.
7. Gmail-SMTP: Das normale Kontopasswort wird abgelehnt. Sie benötigen ein Google-App-Passwort (Google-Konto → Sicherheit → 2-Schritt-Verifizierung → App-Passwörter).
8. EMAIL_USE_TLS und EMAIL_USE_SSL dürfen nicht beide auf True stehen. 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

Starten Sie das Projekt im Container Manager. Healthchecks führt beim Start die Datenbankmigrationen automatisch aus. Verfolgen Sie den Start per SSH:

docker logs -f healthchecks

Warten Sie auf Zeilen wie diese:

[INFO] Starting gunicorn 26.2.0
[INFO] Listening at: http://0.0.0.0:8000
[INFO] Booting worker with pid: ...
[INFO] Booting worker with pid: ...

Verifizieren: Beide Container laufen (grüner Status im Container Manager). Die Meldung Listening at: http://0.0.0.0:8000 und zwei Zeilen Booting worker sind in den Logs sichtbar. Per SSH liefert curl -sI http://localhost:8080/accounts/login/ den Status HTTP/1.1 200 OK.

Schritt 5: Superuser anlegen

Legen Sie per SSH das Administratorkonto an:

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

Der Befehl fragt E-Mail-Adresse und Passwort ab. Vergeben Sie ein starkes Passwort. REGISTRATION_OPEN=False gilt bereits seit dem Start, ein Neustart ist nicht nötig.

Verifizieren: Der Befehl endet mit Superuser created successfully. Die Anmeldung testen Sie nach Schritt 6 über HTTPS.

Schritt 6: Reverse Proxy und HTTPS einrichten

Öffnen Sie Systemsteuerung → Anmeldeportal → Erweitert → Reverse Proxy und legen Sie eine Regel an:

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

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

Für den Nginx Proxy Manager siehe Nginx Proxy Manager auf der Synology mit Container Manager einrichten.

Verifizieren: Öffnen Sie https://healthchecks.meinname.synology.me. Das Zertifikat ist gültig, die Anmeldeseite erscheint, und die Anmeldung mit dem Superuser zeigt die leere Check-Übersicht.

Schritt 7: Ersten Check anlegen und Ping testen

Klicken Sie im Dashboard auf + Add Check. Vergeben Sie einen Namen (z. B. „NAS Backup täglich“), wählen Sie den Zeitplan (z. B. Cron-Ausdruck 0 2 * * * für täglich 02:00 Uhr) und eine Grace-Period von etwa 30 Minuten, damit kurze Verzögerungen keinen Alarm auslösen. Cron-Ausdrücke erklärt die Anleitung Cron und crontab richtig nutzen – die Grundlagen.

Nach dem Speichern zeigt Healthchecks die Ping-URL. Testen Sie per SSH, ob der Ping ankommt:

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

Blockiert Ihr Router DNS-Rebinding, schlägt der Ping auf die externe URL vom NAS aus fehl. Nutzen Sie dann die lokale URL:

curl -fsS -m 10 http://localhost:8080/ping/IHRE-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ängen Sie den curl-Ping mit && ans Ende Ihres Backup-Skripts. Der Ping geht nur bei erfolgreichem Lauf raus; bleibt er aus, alarmiert Healthchecks nach der Grace-Period. Backup-Skripte für Datenbanken 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/IHRE-UUID \
     > /dev/null

Alternativ senden Sie den Exit-Code mit. 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/IHRE-UUID/$? \
  > /dev/null

Verifizieren: Führen Sie das Skript manuell aus. Der Check zeigt danach einen aktuellen letzten Ping und bleibt „Up“. Für den Fehlerfall rufen Sie curl -fsS http://localhost:8080/ping/IHRE-UUID/fail auf: Der Status wechselt sofort auf „Down“, und eine Alarm-E-Mail trifft ein.

Schritt 9: Benachrichtigungskanal einrichten

E-Mail ist nach der SMTP-Konfiguration aktiv. Für Push-Nachrichten nutzen Sie die eingebaute ntfy-Integration: Integrations → ntfy → Add Integration, dann Topic und Server-URL Ihrer ntfy-Instanz eintragen (z. B. https://ntfy.example.com) und speichern. ntfy auf dem NAS richtet die Anleitung ein: ntfy auf dem Synology NAS installieren: Push-Benachrichtigungen für Server und Skripte.

Für einen Test klicken Sie auf der Seite Integrations neben der Integration auf Test!. So prüfen Sie die Benachrichtigungskette ohne echten Fehler.

Verifizieren: Nach dem Klick auf „Test!“ 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. Tragen Sie alle verwendeten Hostnamen kommagetrennt ein, z. B. localhost,healthchecks.meinname.synology.me, und starten Sie 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 ihn neu, bis die Datenbank bereit ist. Prüfen Sie mit docker logs healthchecks-db, ob PostgreSQL initialisiert ist. Meldet docker logs healthchecks „password authentication failed for user hcuser“, fehlt POSTGRES_USER: hcuser. Da PostgreSQL Benutzer nur beim ersten Start anlegt, leeren Sie danach den Ordner db (bei einer frischen Installation ohne Daten) und starten das Projekt neu.
3. Gmail SMTP: „535 Authentication failed“: Das normale Kontopasswort wird abgelehnt. Aktivieren Sie die Bestätigung in zwei Schritten im Google-Konto, erzeugen Sie unter „App-Passwörter“ ein App-Passwort und tragen Sie den 16-stelligen Code als EMAIL_HOST_PASSWORD ein.
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. Tragen Sie 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. Warten Sie, bis docker logs healthchecks die Zeile Listening at zeigt.
6. Interner curl-Ping schlägt fehl (DNS-Rebinding): Läuft das Skript auf demselben NAS, nutzen Sie http://localhost:8080/ping/UUID (siehe Schritt 7).
7. EMAIL_USE_TLS und EMAIL_USE_SSL beide True: 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 fragt aktiv ab, ob ein Dienst erreichbar ist. Healthchecks wartet passiv auf den Ping eines Jobs und erkennt so, wenn ein Skript nicht lief oder mit Fehler endete. Beide ergänzen sich.

Können Sie 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. Checks lassen sich in Projekten gruppieren, Projekte mit weiteren Benutzern teilen.

Wie sichern Sie die Healthchecks-Daten?

Nehmen Sie die Ordner /volume1/docker/healthchecks/db und /volume1/docker/healthchecks/data in Ihren Hyper-Backup-Auftrag auf. Ein konsistentes Datenbank-Backup im laufenden Betrieb erzeugt pg_dump:

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

Können Sie Healthchecks ohne externen SMTP betreiben?

Für erste Tests ja: Setzen Sie 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. Setzen Sie nach dem Test DEBUG=False und REGISTRATION_OPEN=False zurück.

Wie aktualisieren Sie Healthchecks auf eine neue Version?

Sichern Sie zuerst die Datenbank (pg_dump, siehe oben) und lesen Sie das CHANGELOG (v4.4 verlangt z. B. PostgreSQL 15 oder neuer). Tragen Sie dann das neue Tag in die compose.yaml ein, stoppen Sie das Projekt und wählen Sie im Container Manager Aktion → Erstellen. Migrationen laufen beim Start automatisch.

Umstieg von v4.4 auf v5.0

Version 5.0 tauscht im Docker-Image den Webserver: gunicorn ersetzt uWSGI. Laut Release Notes betrifft das vor allem Installationen mit eigener command-Zeile in der Compose-Datei; dort muss künftig /opt/healthchecks/run.sh statt uwsgi stehen. Die compose.yaml dieser Anleitung setzt keine eigene command-Zeile und braucht nur das neue Tag. Ersetzen Sie dabei UWSGI_PROCESSES durch GUNICORN_WORKERS; der alte Name funktioniert als Rückfallwert weiter. Neu ist auch das Verhalten bei Abstürzen: Stürzt einer der Hintergrundprozesse sendalerts, sendreports oder smtpd ab, beendet sich der ganze Container. Mit restart: unless-stopped startet Docker ihn danach neu. v5.0.1 ergänzt die Variablen GUNICORN_PORT für einen anderen internen Port und GUNICORN_DISABLE_LOGGING zum Abschalten des Zugriffslogs.

Der Umstieg lief am 24.10.2026 auf einem Testsystem mit genau dieser compose.yaml: Bestand mit v4.4 (uWSGI mit zwei Workern), Administrator, Check und erster Ping angelegt, dann Tag auf v5.0.1 gesetzt und das Projekt neu erstellt. Healthchecks startete gunicorn 26.2.0 mit zwei Workern aus dem alten UWSGI_PROCESSES-Wert, der Container meldete healthy und lief ohne Neustart. Check und Ping-Zähler waren erhalten, ein neuer Ping wurde mit OK und HTTP 200 angenommen, die Anmeldung des Administrators funktionierte, ein falscher API-Schlüssel bekam HTTP 401. Eine Neuinstallation mit GUNICORN_WORKERS: "2" startete ebenfalls zwei Worker, und die Anmeldeseite antwortete mit HTTP 200. Sichern Sie vor dem Umstieg die Datenbank wie oben beschrieben.

Welche Ping-URL-Varianten gibt es?

Neben dem Erfolgs-Ping gibt es:

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. Als Compose-Projekt auf dem Synology NAS ist der Dienst in rund 35 Minuten betriebsbereit, jedes Backup-Skript überwachen Sie mit einer curl-Zeile. Damit fällt ein ausbleibendes Backup auf, bevor Sie es für eine Wiederherstellung brauchen.

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 Sie mit Healthchecks überwachen
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.