Monitoring-Dashboard

✓ Mehrere URLs / Dienste regelmäßig prüfen.
✓ Ausfall erkennen und sofort per Telegram melden.
✓ Wiederherstellung erkennen und melden.
✓ Nur bei Statusänderung melden – kein Spam bei jedem Prüfzyklus.
✓ Täglichen Kurzbericht um 08:00 Uhr senden.

✗ Kein grafisches Dashboard im Browser.
✗ Keine Langzeit-Statistiken oder Verfügbarkeitsgraphen.
✗ Kein Monitoring von CPU, RAM oder Festplatte (das würde Agenten auf den Zielrechnern erfordern).
✗ Keine SMS oder E-Mail – nur Telegram.

Das zentrale Problem beim Monitoring ist das Gedächtnis: Wie weiß der Workflow ob sich der Status gegenüber dem letzten Lauf verändert hat?

Lösung: Eine JSON-Datei auf dem lokalen Dateisystem (oder in n8n Static Data) speichert nach jedem Lauf den letzten bekannten Status jedes Dienstes. Beim nächsten Lauf wird dieser Status geladen und mit dem aktuellen verglichen. Nur bei Abweichung wird eine Nachricht gesendet.

Für sinnvolles Monitoring muss n8n rund um die Uhr laufen – Docker auf einem Heimserver oder NAS ist ideal. Die Desktop-App scheidet aus, da sie nur läuft solange der PC eingeschaltet ist.
→ n8n installieren

Identisch zum EV-Ladesäulen-Finder – denselben Bot und dieselbe Chat-ID verwenden.
→ Telegram-Bot einrichten

Vor dem Aufbau festlegen, was überwacht werden soll. Für den Einstieg empfehlen sich 3–5 Dienste:

Node: Schedule Trigger
Name: „Alle 5 Minuten"

Trigger interval: Minutes
Minutes between triggers: 5

Node: HTTP Request
Name: z.B. „Prüfe: lessat.net"
Method: GET
URL: https://www.lessat.net

Options:
Timeout: 10000 (10 Sekunden)
Ignore SSL Issues: Aus (SSL-Fehler sollen als Ausfall gewertet werden)
Response Format: String (der HTML-Body wird nicht weiterverarbeitet, nur der Statuscode zählt)

On Error: Continue (using error output)
Wichtig: Damit der Workflow bei einem Timeout oder Verbindungsfehler nicht abbricht, sondern den Fehler als Datenpunkt weitergibt.

Alle HTTP Request Nodes werden direkt an den Trigger-Node angehängt – nicht hintereinander. n8n führt sie dann parallel aus, was den gesamten Prüfzyklus auf maximal 10 Sekunden (Timeout) begrenzt, unabhängig von der Anzahl der Dienste.

Node: Code
Name: „Status auswerten"
Language: JavaScript

// Zu überwachende Dienste (Konfiguration)
const dienste = [
    { name: 'lessat.net',    url: 'https://www.lessat.net',        erwartet: 200 },
    { name: 'NAS',           url: 'http://192.168.x.y:5000',      erwartet: 200 },
    { name: 'Fritzbox',      url: 'http://192.168.x.1',            erwartet: 200 },
    { name: 'n8n',           url: 'http://localhost:5678/healthz',  erwartet: 200 },
];

const jetzt = new Date().toLocaleTimeString('de-DE', {
    hour: '2-digit', minute: '2-digit', timeZone: 'Europe/Berlin'
});

const ergebnisse = $input.all().map((item, i) => {
    const dienst = dienste[i] ?? { name: `Dienst ${i+1}`, erwartet: 200 };
    const statusCode = item.json.statusCode ?? item.json.$response?.statusCode ?? 0;
    const antwortzeit = item.json.$response?.responseTime ?? null;
    const fehler = item.json.message ?? null;

    const ok = !fehler && statusCode === dienst.erwartet;

    return {
        name:        dienst.name,
        url:         dienst.url,
        ok,
        statusCode,
        antwortzeit,
        fehler,
        zeitpunkt:   jetzt,
    };
});

return [{ json: { ergebnisse, zeitpunkt: jetzt } }];

Node: Code
Name: „Änderungen erkennen"

const fs = require('fs');
const statusDatei = '/home/node/.n8n/monitoring-status.json';

// Letzten Status laden
let letzterStatus = {};
try {
    letzterStatus = JSON.parse(fs.readFileSync(statusDatei, 'utf8'));
} catch(e) {
    // Erste Ausführung – kein gespeicherter Status
}

const { ergebnisse, zeitpunkt } = $json;
const meldungen = [];

for (const dienst of ergebnisse) {
    const letzt = letzterStatus[dienst.name];

    // Erster Lauf: Status merken, keine Meldung
    if (letzt === undefined) {
        letzterStatus[dienst.name] = { ok: dienst.ok, seit: zeitpunkt };
        continue;
    }

    // Statuswechsel: OK → FEHLER
    if (letzt.ok && !dienst.ok) {
        meldungen.push({
            typ: 'AUSFALL',
            name: dienst.name,
            url: dienst.url,
            statusCode: dienst.statusCode,
            fehler: dienst.fehler,
            zeitpunkt,
        });
        letzterStatus[dienst.name] = { ok: false, seit: zeitpunkt };
    }

    // Statuswechsel: FEHLER → OK
    if (!letzt.ok && dienst.ok) {
        const ausfallSeit = letzt.seit ?? '?';
        meldungen.push({
            typ: 'WIEDERHERGESTELLT',
            name: dienst.name,
            url: dienst.url,
            ausfallSeit,
            zeitpunkt,
        });
        letzterStatus[dienst.name] = { ok: true, seit: zeitpunkt };
    }
}

// Aktualisierten Status speichern
fs.writeFileSync(statusDatei, JSON.stringify(letzterStatus, null, 2));

return [{ json: { meldungen, hatMeldungen: meldungen.length > 0 } }];

Node: IF
Name: „Meldungen vorhanden?"

Value 1 (Expression): {{ $json.hatMeldungen }}
Operation: Equal
Value 2: true

Der false-Ausgang bleibt unverbunden – der Workflow endet still ohne Telegram-Nachricht.

Node: Code
Name: „Alarm formatieren"

const nachrichten = [];

for (const m of $json.meldungen) {
    let text = '';

    if (m.typ === 'AUSFALL') {
        text = [
            `🔴 *AUSFALL erkannt* – ${m.zeitpunkt} Uhr`,
            ``,
            `Dienst: ${m.name}`,
            `URL: ${m.url}`,
            `Status: ${m.statusCode || 'kein HTTP-Status'}`,
            m.fehler ? `Fehler: ${m.fehler}` : null,
            ``,
            `Bitte prüfen.`,
        ].filter(Boolean).join('\n');
    }

    if (m.typ === 'WIEDERHERGESTELLT') {
        text = [
            `🟢 *WIEDERHERGESTELLT* – ${m.zeitpunkt} Uhr`,
            ``,
            `Dienst: ${m.name}`,
            `Ausfall seit: ${m.ausfallSeit} Uhr`,
        ].join('\n');
    }

    nachrichten.push({ json: { text } });
}

return nachrichten;

Node: Telegram
Name: „Alarm senden"

Credential: Telegram Bot Token
Operation: Send Message
Chat ID: eigene Chat-ID
Text (Expression): {{ $json.text }}
Parse Mode: Markdown

Node 1: Schedule Trigger – täglich 08:00 Uhr

Node 2: Code – gespeicherten Status laden

const fs = require('fs');
const statusDatei = '/home/node/.n8n/monitoring-status.json';

let status = {};
try {
    status = JSON.parse(fs.readFileSync(statusDatei, 'utf8'));
} catch(e) {
    status = {};
}

const jetzt = new Date().toLocaleDateString('de-DE', {
    weekday: 'long', day: '2-digit', month: '2-digit', year: 'numeric',
    timeZone: 'Europe/Berlin'
});

const zeilen = Object.entries(status).map(([name, s]) => {
    const symbol = s.ok ? '✅' : '🔴';
    return `${symbol} ${name}`;
});

const text = [
    `📊 *Monitoring-Report* – ${jetzt}`,
    ``,
    ...zeilen,
    ``,
    zeilen.every(z => z.startsWith('✅'))
        ? '_Alle Dienste erreichbar._'
        : '_⚠️ Mindestens ein Dienst hat Probleme._',
].join('\n');

return [{ json: { text } }];

Identische Konfiguration wie in Schritt 5 – Chat-ID und Token aus demselben Credential.

⬇️ workflow-pruefzyklus.json

⬇️ workflow-tagesreport.json

1. Dienste-Liste im Code Node „Status auswerten" auf eigene URLs anpassen.
2. Pfad zur Statusdatei anpassen (/home/node/.n8n/monitoring-status.json funktioniert für Docker-Instanzen; für Desktop-App einen anderen Pfad wählen).
3. Telegram Credential hinterlegen und Chat-ID eintragen.
4. Workflow A aktivieren – nach dem ersten Durchlauf existiert die Statusdatei und Vergleiche funktionieren.
5. Workflow B separat aktivieren.

Alternativ zum Download: Inhalt kopieren und in n8n über Workflows → Import from clipboard einfügen.

// workflow-pruefzyklus.json noch nicht vorhanden

Alternativ zum Download: Inhalt kopieren und in n8n über Workflows → Import from clipboard einfügen.

// workflow-tagesreport.json noch nicht vorhanden

Identisch zum EV-Ladesäulen-Finder – denselben Bot und dasselbe Credential wiederverwenden. Der Token ist bereits in n8n gespeichert und muss nicht neu angelegt werden.

Die Dienste-Liste enthält interne IP-Adressen (z.B. 192.168.x.y). Das ist kein Sicherheitsproblem solange der Workflow auf einem Rechner im selben Netzwerk läuft. Beim Export des Workflows darauf achten, dass interne Adressen nicht versehentlich öffentlich geteilt werden – sie geben Aufschluss über die Netzwerkstruktur.

Die Datei monitoring-status.json enthält den letzten bekannten Status aller Dienste mit Zeitstempeln. Sie liegt im n8n-Datenverzeichnis und ist von außen nicht erreichbar – kein Handlungsbedarf.

Das Konzept „nur bei Änderung melden" ist der entscheidende Unterschied zu einem nutzlosen Alarm-Spam-System. Die JSON-Statusdatei als einfaches Gedächtnis funktioniert zuverlässig und ist leicht zu debuggen – man kann sie jederzeit mit einem Texteditor öffnen und den gespeicherten Zustand prüfen. Parallele HTTP-Prüfungen halten den Zyklus kurz.

Die Option „Continue (using error output)" im HTTP Request Node ist nicht offensichtlich. Ohne sie bricht der gesamte Workflow ab, sobald ein Dienst nicht antwortet – was genau das Szenario ist, das erkannt werden soll. Mit der Option läuft der Workflow weiter und behandelt den Fehler als normalen Datenpunkt.

Versucht, die Statusdatei in n8n Static Data zu speichern statt als JSON-Datei – Static Data wird bei manchen n8n-Versionen bei einem Workflow-Update zurückgesetzt. Die Datei auf dem Dateisystem ist zuverlässiger und transparenter.

Ursache: HTTP Request Node bricht bei Fehler ab statt fortzufahren.
Lösung: Im HTTP Request Node unter „Settings" → „On Error" auf „Continue (using error output)" stellen. Das ist für jeden Prüf-Node einzeln nötig.

Ursache: Statusdatei wird nicht gefunden oder kann nicht gelesen werden.
Lösung: Pfad zur Statusdatei prüfen. Beim ersten Lauf ist das normal – ab dem zweiten Lauf wird verglichen. Prüfen ob n8n Schreibrechte im Zielverzeichnis hat.

Ursache: n8n läuft in Docker und ist vom Heimnetzwerk isoliert.
Lösung: Docker-Container mit --network host starten (Linux) oder die IP-Adresse des Docker-Hosts verwenden statt localhost oder 192.168.x.x.

Ursache: Parse Mode nicht auf Markdown gestellt.
Lösung: Im Telegram Node unter „Additional Fields" → „Parse Mode" → „Markdown" auswählen.

Nicht nur ob ein Dienst erreichbar ist, sondern auch wie schnell er antwortet. Eine Antwortzeit über 3 Sekunden kann auf Probleme hinweisen, auch wenn der Statuscode noch 200 ist. Alarm bei Überschreitung eines Schwellenwerts.

HTTPS-Zertifikate haben ein Ablaufdatum. Ein abgelaufenes Zertifikat macht eine Website für Besucher unzugänglich. n8n kann das Ablaufdatum über die Zertifikat-Informationen der HTTPS-Verbindung auslesen und rechtzeitig warnen – z.B. 14 Tage vor Ablauf.

Jeden Prüf-Zyklus in eine CSV-Datei oder Google-Tabelle schreiben – Datum, Uhrzeit, Status, Antwortzeit für jeden Dienst. Daraus lässt sich die monatliche Verfügbarkeit berechnen.

Nachts zwischen 23:00 und 07:00 Uhr keine Alarm-Nachrichten senden – Meldungen sammeln und gebündelt beim Morgenbericht ausgeben. Ein IF-Node der die aktuelle Uhrzeit prüft reicht dafür aus.