API-Monitoring heißt, in regelmäßigen Abständen echte Anfragen an Ihre API zu senden und zu prüfen, ob die Antworten stimmen, nicht nur, ob der Server überhaupt geantwortet hat. Eine API, die 200 OK mit einer leeren Liste, einer Fehlermeldung im Body oder nach zehn Sekunden zurückgibt, ist für die Apps, die von ihr abhängen, kaputt, obwohl ein einfacher Check grün wäre. Diese Checkliste zeigt, was Sie einstellen sollten, damit Ihre API-Monitore echte Probleme erkennen.
1. Die Endpunkte auswählen
Überwachen Sie nicht alles. Überwachen Sie, worauf sich Nutzer und Integrationen verlassen:
Health- oder Status-Endpunkt, sofern er Abhängigkeiten wie die Datenbank prüft. Ein Health-Endpunkt, der nur „ok“ zurückgibt, ohne etwas zu prüfen, sagt wenig aus.
Authentifizierung: der Endpunkt, der Tokens ausstellt oder Sessions validiert. Fällt er aus, fällt alles aus.
Zentrale Lese-Endpunkte: die, die Ihre App auf jedem Screen aufruft, etwa um Bestellungen aufzulisten oder ein Profil abzurufen.
Kritische Schreibpfade: Checkout, Registrierung oder Webhook-Empfänger, überwacht mit Testdaten. Ein Ablauf-Monitor führt eine solche Folge von API-Aufrufen Schritt für Schritt aus, übergibt Werte wie ein Token oder eine Bestell-ID von einem Schritt an den nächsten und hält Secrets verschlossen.
APIs von Drittanbietern, von denen Sie abhängen, etwa Zahlungs- oder Versanddienstleister, damit Sie wissen, wann das Problem nicht bei Ihnen liegt. Das Drittanbieter-Monitoring von Uptimecheck verfolgt die Statusseiten von 31 Diensten wie Klarna, Shopify und Cloudflare oder jede auf Statuspage gehostete Seite.
2. Die Anfrage festlegen: Methode, Header und Body
Ein Check sollte wie eine echte Client-Anfrage aussehen:
Methode: GET für Lesezugriffe, POST, PUT oder PATCH für Endpunkte, die sie brauchen.
Header: Accept: application/json, ein Content-Type für Anfragen mit Body und alle eigenen Header, die Ihre API verlangt, etwa einen Versions-Header.
Body: eine kleine, gültige Payload für POST-Anfragen, zum Beispiel eine Suchanfrage.
Wählen Sie Anfragen, die sich gefahrlos jede Minute wiederholen lassen. Meiden Sie Endpunkte, die echte Bestellungen anlegen, E-Mails versenden oder Karten belasten, es sei denn, Sie nutzen ein eigenes Testkonto.
3. Die Authentifizierung regeln
Die meisten APIs brauchen Zugangsdaten. Die Optionen:
Basic Auth für einfach geschützte Endpunkte.
API-Schlüssel oder Bearer-Token in einem Header, zum Beispiel Authorization: Bearer <token>.
Legen Sie ein eigenes Monitoring-Konto oder Token mit reinen Leserechten an. Das begrenzt den Schaden, falls das Token in falsche Hände gerät, und hält den Monitoring-Traffic in Ihren Logs getrennt. Denken Sie daran, dass Tokens ablaufen. Ein langlebiges Token mit Leserechten für das Monitoring vermeidet Fehlalarme, wenn ein kurzlebiges Token abläuft.
4. Den Statuscode prüfen
Legen Sie fest, welche Statuscodes Erfolg bedeuten. Meist sind das je nach Endpunkt 200, 201 oder 204. Seien Sie bei Weiterleitungen vorsichtig: Eine API, die plötzlich auf eine Login-Seite weiterleitet, liefert einen 3xx und dann ein 200 mit HTML. Für jede App, die JSON erwartet, ist das ein Ausfall.
5. Den Inhalt der Antwort prüfen
Hier greifen die meisten API-Checks zu kurz. Prüfen Sie, ob die Antwort etwas enthält, das nur eine funktionierende API zurückgeben würde:
Ein Feld, das immer vorhanden sein sollte, etwa „status“:“ok“ oder „id“.
Einen bekannten Wert aus den Testdaten.
Das Fehlen von Fehlertext wie „error“.
Mit Uptimecheck legen Sie für jeden API-Monitor die erwarteten Statuscodes, ein Keyword und JSON-Prüfungen fest, zum Beispiel dass $.status gleich ok ist oder dass ein Header vorhanden ist, zusammen mit Methode, Headern (einschließlich Basic Auth oder Bearer-Token) und Body.
6. Schwellenwerte für die Antwortzeit setzen
Bei APIs ist langsam das neue down. Mobile Apps laufen in Timeouts, Integrationen versuchen es erneut und erzeugen so noch mehr Last. Erfassen Sie bei jedem Check die Antwortzeit und setzen Sie einen Schwellenwert, der sich am Normalwert orientiert:
Ermitteln Sie anhand der Antwortzeiten einer Woche den Ausgangswert.
Setzen Sie die Alarmschwelle deutlich über die normale Schwankung, zum Beispiel beim Zwei- bis Dreifachen der üblichen Antwortzeit.
Alarmieren Sie bei anhaltender Langsamkeit, nicht bei einzelnen Ausreißern. Eine langsame Anfrage ist Rauschen, eine ganze Reihe davon ist ein Problem.
In Uptimecheck legen Sie pro Monitor ein Limit für langsame Antworten fest. Sie erhalten einen Alarm, wenn drei Checks in Folge langsamer sind, und eine weitere Meldung, sobald es wieder schneller wird.
Checks aus mehr als einer Region zeigen, ob die Langsamkeit global ist oder auf einen Netzwerkpfad beschränkt. Uptimecheck prüft aus Stockholm, London und New York und teilt jede Antwortzeit in DNS, Verbindungsaufbau, TLS, Server und Download auf, sodass Sie sehen, wann die Langsamkeit beginnt und wo die Zeit verloren geht.
7. Die ganze Kette überwachen
Eine API fällt selten allein aus. Legen Sie Monitore für alles an, wovon sie abhängt:
SSL-Zertifikate auf dem Hostnamen der API. Ein abgelaufenes Zertifikat legt alle Clients auf einmal lahm.
DNS-Einträge der API-Domain.
Server-Ressourcen wie CPU, Arbeitsspeicher und Festplatte auf den API-Servern.
Geplante Jobs, die Daten aktuell halten, mit Heartbeats.
8. Alarme an die richtigen Personen leiten
API-Alarme gehören meist zu den Entwicklern, die den Dienst verantworten. Senden Sie sie in den Chat-Kanal des Teams und bei Produktionsausfällen in der Nacht zusätzlich an einen Kanal, der ein Telefon erreicht. Nutzen Sie Webhooks, um Alarme in Ihre eigenen Incident-Tools einzuspeisen. Siehe Benachrichtigungen.
9. Die Einrichtung der Monitore automatisieren
Wenn Sie häufig neue Dienste deployen, legen Sie Monitore als Teil des Deployments an. Die REST API von Uptimecheck (Professional und Business) deckt Monitore, Wartungsfenster und Status-Updates ab und ist unter app.uptimecheck.com/docs/api dokumentiert. So wird das Monitoring Teil Ihrer Pipeline statt ein manueller Schritt hinterher. Ein MCP-Server ermöglicht KI-Assistenten dasselbe mit einem API-Schlüssel.
10. API-Nutzer informieren, was los ist
Wenn andere Teams oder Kunden auf Ihrer API aufbauen, geben Sie ihnen eine Statusseite mit einer Komponente für die API. So suchen sie während Ihres Ausfalls nicht den Fehler im eigenen Code.
Häufige Fehler beim API-Monitoring
Nur den Health-Endpunkt prüfen. Health-Endpunkte sind oft grün, während echte Endpunkte scheitern, weil eine Abhängigkeit ausgefallen ist.
Produktive Zugangsdaten eines echten Nutzers verwenden. Ändert dieser Nutzer sein Passwort oder verlässt er das Unternehmen, bricht das Monitoring. Nutzen Sie ein eigenes Konto.
Den Body ignorieren. Eine HTML-Fehlerseite mit Status 200 besteht einen Check, der nur den Status prüft.
Bei jeder langsamen Antwort alarmieren. Einzelne Ausreißer erzeugen Rauschen und gewöhnen das Team daran, Alarme zu ignorieren.
Abhängigkeiten vergessen. Die API läuft, aber das Zertifikat ist abgelaufen oder der DNS-Eintrag hat sich geändert.
Die Checkliste
Endpunkte auswählen: Health, Auth, zentrale Lesezugriffe, kritische Schreibzugriffe, wichtige Drittanbieter-APIs.
Methode, Header und Body für jeden Check festlegen.
Ein eigenes Token mit Leserechten oder Basic-Auth-Zugangsdaten verwenden.
Die erwarteten Statuscodes festlegen.
Den Inhalt prüfen: ein Feld oder Wert, den nur eine funktionierende API liefert.
Die Antwortzeit erfassen und bei anhaltender Langsamkeit alarmieren.
Aus mehr als einer Region prüfen.
SSL, DNS, Server und geplante Jobs hinter der API überwachen.
Alarme an das verantwortliche Team leiten, mit einem telefontauglichen Kanal für die Produktion.
Monitore beim Deployment über die API anlegen.
Fazit
Ein 200 OK ist der Anfang eines API-Checks, nicht das Ende. Senden Sie realistische Anfragen, prüfen Sie den Inhalt, behalten Sie die Antwortzeit im Blick und decken Sie die Kette hinter der API ab.
API-Monitoring mit eigenen Methoden, Headern, Bodys, JSON-Prüfungen und Alarmen bei langsamen Antworten ist in jedem Uptimecheck-Tarif enthalten. Testen Sie es 14 Tage kostenlos, ohne Kreditkarte.