Uptime Monitoring automatisieren: Server-Überwachung mit n8n und Make.com

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.

Warum Uptime Monitoring automatisieren?

Die Kosten von Downtime: 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

Bezahlte Optionen

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.

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": "<em>monitorID</em>",
  "monitorURL": "<em>monitorURL</em>",
  "monitorFriendlyName": "<em>monitorFriendlyName</em>",
  "alertType": "<em>alertType</em>",
  "alertTypeFriendlyName": "<em>alertTypeFriendlyName</em>",
  "alertDetails": "<em>alertDetails</em>",
  "alertDuration": "<em>alertDuration</em>"
}

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 <em> 60 </em> 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 <em> 60 </em> 1000);

  const stillDown2 = await checkStatus(monitor.url);
  if (stillDown2) {
    // Eskalation Stufe 3: Anruf + PagerDuty
    await createPagerDutyIncident(monitor);
  }
}

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

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

Fazit

Automatisiertes Uptime Monitoring ist essentiell:

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

Weiterführende Artikel

• Webhook erstellen: Der komplette Guide
• Slack Bot erstellen: Automatisierung ohne Code
• Workflow Automation: 15 Beispiele aus der Praxis

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.