Warum API-Monitoring anders ist#

Deine Website kann "up" sein, während deine API kaputt ist. Nutzer sehen eine Homepage, die einwandfrei lädt, aber die App-Funktionalität, von der sie abhängen, ist komplett unbrauchbar.

Beispiel: Deine Checkout-Seite lädt (Website ist up ✅), aber die Payment-API fällt aus (Website ist kaputt ❌). Kunden können keine Käufe abschließen. Der Umsatz stoppt.

API-Monitoring erkennt diese unsichtbaren Ausfälle.

Was API-Monitoring braucht#

Payment-Gateways (Stripe, PayPal, Square)
Authentifizierungs-Endpoints (Login/Logout)
Daten-APIs (Produktlisten, Nutzerdaten)
Webhooks (eingehende Daten von Drittanbietern)
Such-Endpoints
Media-Upload-APIs

HTTP-Statuscodes in APIs#

APIs nutzen HTTP-Statuscodes anders als Websites:

Website:

200 OK: Seite lädt
500 Server Error: Website ist kaputt

API:

200 OK: Anfrage erfolgreich
400 Bad Request: Client hat falsche Daten gesendet
401 Unauthorized: Authentifizierung fehlgeschlagen
403 Forbidden: Berechtigung verweigert
404 Not Found: Endpoint existiert nicht
429 Too Many Requests: Rate-Limit erreicht
500+ Server Error: Backend kaputt

Wichtiger Unterschied: Eine API kann 200 OK zurückgeben und trotzdem einen Fehler im JSON-Body haben.

Beispiel:

{
  "status": 200,
  "success": false,
  "error": "Payment processing failed"
}

HTTP sagt "OK", aber die API ist tatsächlich fehlgeschlagen. Einfaches Uptime-Monitoring übersieht das.

API-Monitoring einrichten#

Schritt 1: Kritische API-Endpoints identifizieren#

Liste jeden API-Endpoint auf, der für dein Business kritisch ist:

/api/auth/login (Nutzer können sich nicht einloggen, wenn das fehlschlägt)
/api/payments/create (Nutzer können nicht zur Kasse gehen)
/api/users/profile (App stürzt ab, wenn das fehlschlägt)
/webhooks/stripe (Zahlungen werden nicht erfasst, wenn das fehlschlägt)

Schritt 2: Response-Validierung festlegen#

Entscheide für jeden Endpoint, was "up" bedeutet:

Basis-Check (HTTP-Status):

Endpoint gibt 200 oder 201 zurück = OK

Mittlerer Check (Status + Antwortzeit):

Endpoint gibt 200 zurück UND antwortet in < 1 Sekunde

Erweiterter Check (Status + Body-Inhalt):

Endpoint gibt 200 zurück UND der Response-Body enthält die erwarteten Daten

Schritt 3: Monitoring-Tool konfigurieren#

In Nova Uptime:

Domain hinzufügen: https://api.yourdomain.com
Für jeden kritischen Endpoint einen separaten Monitor anlegen:
- /api/auth/login
- /api/payments/create
- usw.
Response-Body-Validierung konfigurieren, falls verfügbar
Alert-Schwellen setzen (2 aufeinanderfolgende Fehlschläge vor dem Alert)

Erweitert: Response-Body-Validierung#

Manche Endpoints erfordern ein bestimmtes Response-Format.

Beispiel: Endpoint zur Zahlungserstellung

Erwartete Antwort:

{
  "success": true,
  "payment_id": "pay_12345",
  "amount": 99.99
}

Monitoring-Setup:

Prüfe, ob die Antwort "success": true enthält
Wenn nicht, ist der Endpoint "kaputt", auch wenn der HTTP-Status 200 ist

Der Email Health Checker von Nova Uptime validiert Response-Bodies — dasselbe Prinzip gilt fürs API-Monitoring.

Authentifizierungs-Tokens im API-Monitoring#

Die meisten APIs erfordern Authentifizierung. So überwachst du sie:

Option 1: Test-API-Key erstellen

Generiere einen dedizierten Test-API-Key fürs Monitoring
Nutze diesen Key in allen Monitoring-Anfragen
Dieser Key hat nur Lese-Berechtigungen (kann keine Daten ändern)
Verwende diesen Key im Monitoring-Tool

Option 2: Öffentlicher Endpoint

Manche APIs haben unauthentifizierte Endpoints (Health-Check, Status)
Überwache stattdessen diese
Beispiel: GET /api/health (öffentlich, keine Auth nötig)

Webhook-Monitoring#

Webhooks sind kniffliger. Sie sind eingehend (du empfängst sie, statt sie zu senden).

Überwache den Endpoint, der die Webhooks empfängt:

Beispiel: Stripe sendet POST an https://yourdomain.com/webhooks/stripe

So überwachst du:

Erstelle einen Test-Webhook-Sender (manuell auslösen)
Verifiziere, dass der Endpoint ihn akzeptiert und 200 zurückgibt
Prüfe in den Logs, dass der Webhook verarbeitet wurde

Oder nutze Synthetic Monitoring:

Richte eine synthetische POST-Anfrage an den Webhook-Endpoint ein
Inklusive Test-Payload
Verifiziere, dass sie empfangen und verarbeitet wird

Monitoring der Antwortzeit#

Bei APIs geht es nicht nur um up/down. Es geht auch um Geschwindigkeit.

Langsame API = kaputte API (aus Nutzerperspektive).

Setze Schwellen für Antwortzeiten:

Authentifizierungs-Endpoint: < 200ms
Payment-Endpoint: < 500ms
Such-Endpoint: < 1000ms (komplexer)

Wenn ein Endpoint 5 Sekunden zum Antworten braucht, erleben Nutzer Timeouts und springen ab — auch wenn er "funktioniert".

Rate-Limiting beachten#

APIs nutzen oft Rate-Limits, um Missbrauch zu verhindern.

Problem: Dein Monitoring sendet jede Minute einen Check. Bei 1.000 Monitoren sind das 1.000 Requests pro Minute. Wenn deine API auf 100/Minute limitiert ist, wird das Monitoring blockiert.

Lösung:

Erstelle einen separaten API-Key fürs Monitoring (mit hohem Rate-Limit)
Oder reduziere die Check-Frequenz (alle 5 Minuten statt jede Minute)
Oder nutze einen internen /health-Endpoint, der nicht rate-limited ist

Häufige Fehler beim API-Monitoring#

Fehler 1: Produktion mit destruktiven Operationen überwachen#

Überwache nicht:

POST /api/users/delete    ← Löscht bei jedem Check Nutzer
POST /api/billing/charge  ← Belastet bei jedem Check die Karte

Überwache stattdessen lesende Operationen:

GET /api/users/{id}
GET /api/health

Fehler 2: Authentifizierung in der URL#

Mach das nicht:

GET /api/endpoint?auth_token=SECRET

Damit landen Secrets in den Logs. Nutze stattdessen Header:

Authorization: Bearer SECRET_TOKEN

Fehler 3: Webhook-Endpoints nicht testen#

Webhooks sind kritisch, werden aber oft nicht getestet. Dein Webhook-Processor könnte komplett kaputt sein, und du würdest es nie merken.

Fix: Sende regelmäßig Test-Webhooks und verifiziere, dass sie verarbeitet werden.

API-Abhängigkeiten überwachen#

Deine API hängt vielleicht von externen Services ab:

Datenbank (wenn sie down ist, ist die API down)
Message-Queue (Redis, RabbitMQ)
Cache (Memcached)
Externe APIs (Stripe, Twilio)

Überwache diese separat:

Health-Check-Endpoint der Datenbank
Status-Endpoint des Caches
Statusseite der Drittanbieter-API

Alerts für API-Fehler einrichten#

Wenn das API-Monitoring einen Fehler erkennt:

Der Alert sollte enthalten:

Welcher Endpoint fehlgeschlagen ist
Was der Fehler war (Timeout vs. 500 Error)
Wann er begann
Letzte Änderungen (falls verfügbar)

Alert-Schweregrad:

Kritisch: Payment-/Auth-API (Nutzer blockiert)
Hoch: Such-/Daten-API (Nutzer frustriert)
Mittel: Analytics/Logging (Fehler für Nutzer sichtbar)

API-Monitoring in Nova Uptime#

Nova Uptime überwacht die API-Uptime parallel zur Website-Uptime:

Füge deine API-Domain hinzu: https://api.yourdomain.com
Konfiguriere das Endpoint-Monitoring
Erhalte Alerts per E-Mail/Slack
Sieh dir Vorfallshistorie und Antwortzeiten an
Automatische Screenshots bei Ausfällen (zum Debuggen)

Plus E-Mail-Health-Monitoring — wenn deine API transaktionale E-Mails versendet, prüft Nova Uptime automatisch SPF/DKIM/DMARC im selben Dashboard.

Zusammenfassung#

Kritische API-Endpoints auflisten
Festlegen, was "up" für jeden bedeutet (Statuscode, Antwortzeit, Body-Inhalt)
Monitoring für jeden anlegen
Schwellen für Antwortzeiten setzen
Abhängigkeiten überwachen (Datenbank, Cache, Drittanbieter)
Webhooks regelmäßig testen
Bei Fehlern sofort alerten

Starte heute mit dem Monitoring deiner API: Nova Uptime API-Monitoring. Inklusive Uptime + E-Mail-Health im selben Dashboard. 🚀

Uptime-Monitoring für APIs: Endpoints und Webhooks überwachen