Ihre Website ist offline und Sie erfahren es zuerst von Ihren Kunden? Das muss nicht sein. Mit automatisiertem Uptime Monitoring werden Sie in Sekunden benachrichtigt – nicht in Stunden. In diesem Guide zeigen wir, wie Sie professionelle Server-Überwachung mit Automatisierung verbinden.

Bevor Sie weiterlesen
Lohnt sich Automation bei Ihnen überhaupt? Machen Sie die 5-Minuten-Analyse — Score, Reifegrad und eine ehrliche Einordnung, ob dieser Weg für Ihre Situation taugt. Kostenlos, Report per Mail.
5-Min-Analyse starten →

Warum Uptime Monitoring automatisieren?

Die Kosten von Downtime:

UnternehmensgrößeKosten/Minute Downtime
Kleines E-Commerce10-50€
Mittleres SaaS100-500€
Enterprise1.000-10.000€

Reaktionszeit ist entscheidend:

  • Ohne Monitoring: 30-60 Min bis zur Erkennung
  • Mit Monitoring: 30 Sekunden bis zur Erkennung
  • Mit Automatisierung: 30 Sekunden bis zur Reaktion

Uptime Monitoring Tools im Überblick

Kostenlose Optionen

ToolChecksIntervallAPI
UptimeRobot505 Min
Freshping501 Min
Uptime KumaUnbegrenzt1 Min
Hetrix Tools151 Min

Bezahlte Optionen

ToolAb PreisBesonderheiten
Pingdom$10/MonatKlassiker, zuverlässig
Datadog$15/MonatUmfassend, Enterprise
Better Uptime$20/MonatSchöne Status Pages
Checkly$7/MonatSynthetic Monitoring

Schritt 1: Monitoring einrichten

Option A: UptimeRobot (Kostenlos)

  • Account auf uptimerobot.com erstellen
  • Monitor hinzufügen:
  • - Monitor Type: HTTP(s)

    - URL: https://ihre-website.de

    - Monitoring Interval: 5 minutes

  • Alert Contacts konfigurieren
  • Option B: Uptime Kuma (Self-Hosted)

    # Mit Docker starten
    docker run -d \
      --name uptime-kuma \
      -p 3001:3001 \
      -v uptime-kuma:/app/data \
      louislam/uptime-kuma:1

    Dann: http://localhost:3001 öffnen und Monitors einrichten.

    Selbst bauen oder bauen lassen?
    Wir implementieren diesen Workflow für Sie — fertig getestet in 1-4 Wochen. Festpreisangebot in 24h.
    Angebot anfragen →

    Schritt 2: Webhooks für Automatisierung

    Webhooks sind die Grundlage für automatisierte Reaktionen auf Monitoring-Events. Falls Sie noch nicht mit Webhooks gearbeitet haben, empfehlen wir unseren Guide zum Webhook erstellen.

    UptimeRobot Webhook

  • My Settings → Alert Contacts → Add Alert Contact
  • Type: Webhook
  • URL: Ihre n8n/Make.com Webhook-URL
  • POST Value:
  • {
      "monitorID": "*monitorID*",
      "monitorURL": "*monitorURL*",
      "monitorFriendlyName": "*monitorFriendlyName*",
      "alertType": "*alertType*",
      "alertTypeFriendlyName": "*alertTypeFriendlyName*",
      "alertDetails": "*alertDetails*",
      "alertDuration": "*alertDuration*"
    }

    Uptime Kuma Webhook

  • Settings → Notifications → Add
  • Type: Webhook
  • URL: Ihre Webhook-URL
  • Request Body:
  • {
      "monitor": "{{name}}",
      "status": "{{status}}",
      "msg": "{{msg}}",
      "url": "{{url}}"
    }

    Schritt 3: Automatisierte Reaktionen

    Workflow: Einfacher Alert

    Uptime Monitor Webhook
    (Server Down)
            ↓
        Parallel:
        ├─ Slack: #alerts Channel
        ├─ SMS: On-Call Team
        ├─ PagerDuty: Incident erstellen
        └─ Status Page: Status ändern

    n8n Implementation

    Node 1: Webhook Trigger

    // Webhook empfängt UptimeRobot Alert
    {
      "monitorID": "123456",
      "monitorURL": "https://api.ihre-app.de",
      "monitorFriendlyName": "API Server",
      "alertType": "1",  // 1 = Down, 2 = Up
      "alertTypeFriendlyName": "Down",
      "alertDetails": "Connection timeout",
      "alertDuration": "0"  // Sekunden offline
    }

    Node 2: Alert-Typ prüfen

    // Node: IF
    const isDown = $json.alertType === "1";
    const isUp = $json.alertType === "2";
    
    if (isDown) {
      return { route: 'down' };
    } else if (isUp) {
      return { route: 'up' };
    }

    Node 3: Slack Alert (Down) -- Mehr zur Einrichtung von Slack-Benachrichtigungen finden Sie in unserem Guide zum Slack Bot erstellen.

    // Node: Slack
    {
      "channel": "#alerts",
      "text": "",
      "attachments": [
        {
          "color": "danger",
          "title": "🔴 Server Down: {{ $json.monitorFriendlyName }}",
          "fields": [
            { "title": "URL", "value": "{{ $json.monitorURL }}", "short": true },
            { "title": "Grund", "value": "{{ $json.alertDetails }}", "short": true },
            { "title": "Zeit", "value": "{{ $now }}", "short": true }
          ]
        }
      ]
    }

    Node 4: Recovery Alert (Up)

    // Node: Slack
    {
      "channel": "#alerts",
      "text": "",
      "attachments": [
        {
          "color": "good",
          "title": "🟢 Server Recovered: {{ $json.monitorFriendlyName }}",
          "fields": [
            { "title": "URL", "value": "{{ $json.monitorURL }}", "short": true },
            { "title": "Downtime", "value": "{{ $json.alertDuration }} Sekunden", "short": true }
          ]
        }
      ]
    }

    Workflow: Eskalation

    Server Down Alert
            ↓
        Slack: #alerts
            ↓
        Warten: 5 Minuten
            ↓
        Noch down? ──No──→ Ende
            ↓ Yes
        SMS an On-Call
            ↓
        Warten: 10 Minuten
            ↓
        Noch down? ──No──→ Ende
            ↓ Yes
        Anruf an Team-Lead
            ↓
        PagerDuty Incident

    Implementation

    // Node: Wait + Status-Check
    
    // Schritt 1: Ersten Alert senden
    await sendSlackAlert(monitor);
    
    // Schritt 2: 5 Minuten warten
    await wait(5 * 60 * 1000);
    
    // Schritt 3: Status erneut prüfen
    const stillDown = await checkStatus(monitor.url);
    
    if (stillDown) {
      // Eskalation Stufe 2: SMS
      await sendSMS(onCallPhone, `ALERT: ${monitor.name} seit 5 Min down`);
    
      await wait(10 * 60 * 1000);
    
      const stillDown2 = await checkStatus(monitor.url);
      if (stillDown2) {
        // Eskalation Stufe 3: Anruf + PagerDuty
        await createPagerDutyIncident(monitor);
      }
    }

    Schulung oder Implementierung?
    Ob Sie es selbst lernen oder von uns umsetzen lassen wollen — wir bieten beides. Individuelle Workshops ab 2h oder fertige Lösungen.
    Optionen ansehen →

    Workflow: Automatische Diagnose

    Server Down Alert
            ↓
        Automatische Checks:
        ├─ DNS auflösbar?
        ├─ SSL-Zertifikat gültig?
        ├─ Server erreichbar (Ping)?
        ├─ HTTP Response Code?
        └─ Letzte Deployment-Zeit?
            ↓
        Diagnose-Report erstellen
            ↓
        Mit Alert versenden

    Implementation

    // Node: Code - Diagnose sammeln
    const url = new URL($json.monitorURL);
    const diagnose = {
      timestamp: new Date().toISOString(),
      monitor: $json.monitorFriendlyName,
      checks: []
    };
    
    // DNS Check
    try {
      const dns = await resolveDNS(url.hostname);
      diagnose.checks.push({ name: 'DNS', status: 'OK', value: dns });
    } catch (e) {
      diagnose.checks.push({ name: 'DNS', status: 'FAIL', error: e.message });
    }
    
    // HTTP Check
    try {
      const response = await fetch(url, { timeout: 10000 });
      diagnose.checks.push({
        name: 'HTTP',
        status: response.ok ? 'OK' : 'WARN',
        value: response.status
      });
    } catch (e) {
      diagnose.checks.push({ name: 'HTTP', status: 'FAIL', error: e.message });
    }
    
    // SSL Check
    try {
      const ssl = await checkSSL(url.hostname);
      diagnose.checks.push({
        name: 'SSL',
        status: ssl.valid ? 'OK' : 'WARN',
        value: `Expires: ${ssl.expiresIn} days`
      });
    } catch (e) {
      diagnose.checks.push({ name: 'SSL', status: 'FAIL', error: e.message });
    }
    
    return diagnose;

    Workflow: Automatischer Restart

    ⚠️ Vorsicht: Nur für nicht-kritische Services!

    Server Down Alert
            ↓
        Ist Auto-Recovery aktiv?
            ↓ Yes
        SSH zu Server:
        "systemctl restart nginx"
            ↓
        30 Sekunden warten
            ↓
        Status prüfen
            ↓
        Up? → Erfolg melden
        Down? → Manuell eskalieren

    n8n SSH Node

    // Node: SSH
    {
      "host": "server.ihre-domain.de",
      "port": 22,
      "username": "deploy",
      "privateKey": "{{ $env.SSH_PRIVATE_KEY }}",
      "command": "sudo systemctl restart nginx && sleep 5 && systemctl is-active nginx"
    }

    Workflow: Status Page Update

    Server Down Alert
            ↓
        Status Page aktualisieren:
        - Komponente: "API" → "Partial Outage"
        - Incident erstellen
            ↓
        [Bei Recovery]
            ↓
        Status Page aktualisieren:
        - Komponente: "API" → "Operational"
        - Incident als "Resolved" markieren

    Integration mit Statuspage.io

    // Node: HTTP Request
    // Statuspage.io API
    
    // Incident erstellen
    {
      "method": "POST",
      "url": "https://api.statuspage.io/v1/pages/{{ $env.STATUSPAGE_ID }}/incidents",
      "headers": {
        "Authorization": "OAuth {{ $env.STATUSPAGE_TOKEN }}"
      },
      "body": {
        "incident": {
          "name": "{{ $json.monitorFriendlyName }} - Service Disruption",
          "status": "investigating",
          "impact_override": "partial",
          "body": "We are currently investigating issues with {{ $json.monitorFriendlyName }}.",
          "component_ids": ["abc123"],
          "components": {
            "abc123": "partial_outage"
          }
        }
      }
    }

    Multi-Location Monitoring

    Prüfen Sie von verschiedenen Standorten:

    Parallel Checks:
    ├─ Frankfurt (Hetzner)
    ├─ Amsterdam (DigitalOcean)
    ├─ New York (AWS)
    └─ Singapore (GCP)
            ↓
        Mindestens 2 fehlgeschlagen?
            ↓
        Ja: Echter Ausfall → Alert
        Nein: Lokales Problem → Loggen

    Dashboard mit Grafana

    Metriken sammeln

    // Bei jedem Check: Metrik speichern
    {
      "metric": "uptime_check",
      "tags": {
        "monitor": $json.monitorFriendlyName,
        "location": "frankfurt"
      },
      "fields": {
        "response_time": 234,
        "status": 1,  // 1 = up, 0 = down
        "ssl_days_remaining": 45
      }
    }

    Grafana Dashboard

    • Uptime Prozent (letzten 30 Tage)
    • Response Time Graph
    • Incidents Timeline
    • SSL Ablauf-Warnungen

    Make.com Szenario

    Module-Aufbau

  • Webhooks → Custom Webhook (UptimeRobot)
  • Router → Down / Up / Degraded
  • Slack → Alert senden
  • Twilio → SMS bei Eskalation
  • HTTP → Status Page API
  • Google Sheets → Incident Log
  • Best Practices

    1. Check-Intervalle

    Service-TypEmpfohlenes Intervall
    Landing Page5 Minuten
    E-Commerce1 Minute
    API (SLA)30 Sekunden
    Payment Gateway30 Sekunden

    2. Alerting-Regeln

    • Keine Alerts nachts für nicht-kritische Services
    • Deduplizierung (nicht 100 Alerts für 1 Ausfall)
    • Klare Eskalationspfade

    3. Vermeidung von False Positives

    // Erst nach X fehlgeschlagenen Checks alertieren
    const failedChecks = await getRecentChecks(monitorId, 3);
    const allFailed = failedChecks.every(c => c.status === 'down');
    
    if (allFailed) {
      await sendAlert(monitor);
    }

    Kosten

    SetupKosten/Monat
    UptimeRobot (Free) + n8n20-50€
    Uptime Kuma (Self-Hosted) + n8n5-10€ (Server)
    Pingdom + Make.com30-50€
    Better Uptime20€ (All-in-One)

    Fazit

    Automatisiertes Uptime Monitoring ist essentiell:

    • Sofortige Benachrichtigung bei Ausfällen
    • Automatische Eskalation
    • Selbstheilende Systeme möglich
    • Transparenz durch Status Pages

    Weiterführende Artikel

    Nächste Schritte

  • Monitoring-Tool wählen (UptimeRobot für Start)
  • Webhook in n8n/Make.com einrichten
  • Alert-Kanal konfigurieren (Slack/SMS oder Microsoft Teams Bot)
  • Eskalation definieren
  • Status Page einrichten (optional)
  • Wir helfen Ihnen beim Aufbau einer robusten Monitoring-Infrastruktur. Automatisierung beauftragen -- lassen Sie uns gemeinsam Ihre Server-Überwachung professionell aufsetzen.