Uptime-Monitoring
Anfragemethode
GET oder POST. Mit POST kannst du einen Endpunkt prüfen, der nur schreibende Zugriffe akzeptiert (zum Beispiel den eigenen Health-Check eines Webhook-Empfängers).
TCP-Port-Prüfungen
Nicht alles spricht HTTP — eine Datenbank, ein Mailserver, ein Gameserver. Geben Sie statt http(s):// tcp://host:port als URL ein, und Dumza prüft, ob dieser Port eine Verbindung annimmt, statt eine HTTP-Anfrage zu senden. Methode, erwarteter Statuscode, Schlüsselwort und Antwortzeit-Schwellenwert gelten für einen TCP-Check nicht und werden im Formular ausgeblendet; Alarmierung, Incidents und alles andere funktionieren genau gleich.
Erwarteter Statuscode
Jeder Endpunkt, der einen anderen als den erwarteten Code zurückgibt, gilt als down. Das ist nicht auf 200 beschränkt — viele APIs geben bei einer gesunden Prüfung korrekterweise 201, 204 oder sogar 401/503 zurück (etwa ein Endpunkt, der ABSICHTLICH eine Authentifizierung verlangt). Stelle den Status ein, den dein Endpunkt zurückgibt, wenn er tatsächlich gesund ist.
Keyword-Prüfung
Optional kannst du einen bestimmten Text im Antwort-Body verlangen (oder verbieten) — nützlich für Endpunkte, die auch dann 200 zurückgeben, wenn intern etwas kaputt ist (zum Beispiel ein CMS, das eine generische Fehlerseite mit Status 200 ausliefert). Wähle „enthält“, um den Text zu verlangen, oder „enthält nicht“, um bei seinem Auftreten fehlzuschlagen (praktisch, um einen Wartungsmodus-Banner zu erkennen, den deine App anzeigt, während sie weiterhin 200 zurückgibt).
Antwortzeit-Schwellenwert
Lege eine maximal akzeptable Antwortzeit fest — eine Prüfung, die korrekt, aber zu langsam antwortet, wird als „degraded“ statt als „down“ markiert. Sie ist im Dashboard sichtbar und fließt in deine Uptime-Statistik ein, eröffnet aber KEINEN Vorfall und löst KEINE Benachrichtigung aus. Degraded ist ein Signal zum Beobachten, kein Grund, jemanden zu alarmieren.
Prüfintervall
Wie oft Dumza den Endpunkt prüft. Der kostenlose Tarif prüft alle 5 Minuten; bezahlte Tarife erlauben bis zu jede Minute. Ein kürzeres Intervall bedeutet schnellere Erkennung eines Ausfalls, auf Kosten von mehr Anfragen an deinen Server.
Benachrichtigungs-Timing: notifyAfter und erneute Benachrichtigungen
„Benachrichtigen nach N aufeinanderfolgenden Fehlschlägen“ bestimmt, wie viele schlechte Prüfungen in Folge einen Vorfall eröffnen (Minimum 2, um Fehlalarme durch einen einzelnen Ausreißer zu vermeiden). Unabhängig davon wiederholt „Erneut benachrichtigen alle N Minuten“ (optional, Minimum 30) die Benachrichtigung, solange der Monitor down bleibt — nützlich, falls die erste Benachrichtigung deines Teams übersehen wird.
Bedeutung der Monitor-Status
up — die letzte Prüfung war erfolgreich. down — ein Vorfall ist offen. degraded — antwortet, aber langsamer als dein Schwellenwert. pending — es wurde noch keine Prüfung durchgeführt (gerade erstellt oder pausiert). auth_error — das Login-Token eines authentifizierten Monitors wurde abgelehnt; siehe Authentifiziertes Monitoring.
Einen Monitor pausieren
Ein pausierter Monitor wird gar nicht mehr geprüft, und ein offener Vorfall dazu schließt sich automatisch — er benachrichtigt dich nicht länger für etwas, das du bewusst offline genommen hast (geplante Wartung, Außerbetriebnahme). Setze ihn jederzeit fort, um das Monitoring wieder aufzunehmen.