Monitoring

Statuswerk kann deine Dienste selbst prüfen: Wir rufen eine URL in festem Abstand auf und melden uns, wenn sie nicht mehr antwortet. Auf Wunsch schaltet der Check die passende Komponente deiner Statusseite gleich mit um.

Woher wir prüfen

Unsere Prüfpunkte stehen in sechs Rechenzentren in fünf Ländern Europas, bei zwei voneinander unabhängigen Anbietern:

  • Hetzner: Falkenstein und Nürnberg (Deutschland), Helsinki (Finnland)
  • UpCloud: Amsterdam (Niederlande), Warschau (Polen), Madrid (Spanien)

Jeder Check wechselt von Lauf zu Lauf zwischen ihnen. Die Bestätigung kommt immer aus einer anderen Region, und wann immer möglich vom anderen Anbieter. So löst weder eine Störung bei Hetzner oder UpCloud noch eine Leitungsstörung in einem Land allein einen Alarm aus.

Ein Fehlschlag allein ist noch kein Ausfall. Schlägt ein Lauf fehl, prüft sofort eine andere Region nach. Erst wenn auch sie scheitert, gilt der Check als nicht erreichbar und wir alarmieren. So unterscheiden wir „dein Dienst ist weg" von „eine Leitung zwischen uns und dir hat gerade ein Problem".

Wieder erreichbar ist er nach zwei erfolgreichen Läufen hintereinander. Das verhindert, dass ein wackeliger Endpunkt dir nachts zwanzig Mails schickt.

Regionen abwählen: Standardmäßig prüfen alle Regionen. Unter Regionen im Check kannst du einzelne abschalten, etwa wenn dein Dienst nur in Mitteleuropa erreichbar sein muss oder deine Firewall nur bestimmte Prüfpunkte durchlässt. Mindestens zwei müssen aktiv bleiben, sonst könnte kein Ausfall bestätigt werden. Bestätigt wird dann nur aus deinen gewählten Regionen. Wählst du zwei beim selben Anbieter, entfällt der Schutz vor dessen Netzstörungen. Solange alle Regionen aktiv sind, kommen neue automatisch dazu. Sind gerade alle deine gewählten Regionen nicht erreichbar, wartet der Check, statt von woanders zu prüfen.

Jeder Punkt im Antwortzeit-Diagramm stammt aus der Region, die gerade an der Reihe war. Weil sich die Regionen abwechseln, springt die Kurve mit der Entfernung: Madrid misst zu einem Server in Nürnberg mehr als Nürnberg selbst. Wer eine ruhigere Kurve will, wählt nahe Regionen.

Check anlegen

Unter Dashboard → Statusseiten → Monitoring → Anlegen:

  • URL — eine öffentliche http://- oder https://-Adresse auf Port 80, 443, 8080 oder 8443. Interne Adressen (z. B. 10.x.x.x, 192.168.x.x, localhost) lehnen wir ab — siehe unten.

  • Intervall — wie oft wir prüfen. Wie kurz es sein darf, hängt vom Tarif ab.

  • Methode — GET oder HEAD.

  • Erwarteter Status — standardmäßig gilt jede Antwort von 200 bis 399 als Erfolg. Weiterleitungen folgen wir (höchstens fünf).

  • Stichwort (optional) — ein Text, der in der Antwort vorkommen muss, z. B. "status":"ok". Fehlt er, gilt der Lauf als fehlgeschlagen, auch wenn der Status stimmt.

  • Timeout — wie lange wir auf eine Antwort warten, höchstens 30 Sekunden.

  • Regionen — von wo geprüft wird. Alle sind vorausgewählt, mindestens zwei müssen es bleiben (siehe oben).

  • Anmeldung (optional) — für Seiten hinter einem Passwortschutz:

    • Basic Auth mit Benutzername und Passwort, z. B. ein .htaccess/htpasswd-Schutz.
    • Bearer-Token, gesendet als Authorization: Bearer …, z. B. für einen geschützten Health-Endpunkt.

    Das geht nur mit einer https://-URL, damit die Zugangsdaten nie unverschlüsselt durchs Netz gehen. Wir speichern sie verschlüsselt und zeigen sie nach dem Speichern nicht mehr an. Lässt du das Feld beim Bearbeiten leer, bleibt das alte Passwort bzw. Token — außer du änderst Host oder Port der URL: dann musst du die Zugangsdaten neu eingeben, damit sie nie an einem Ziel landen, für das sie nicht gedacht waren. Leiten wir auf einen anderen Host oder auf http:// weiter, schicken wir die Zugangsdaten nicht mit. Leg am besten einen eigenen Zugang nur für den Check an, mit so wenig Rechten wie möglich.

Der erste Lauf startet wenige Sekunden nach dem Speichern.

Mit der Statusseite verbinden

Ein Check kann zu einer Komponente gehören. Dann wählst du, was bei einem Ausfall passiert:

  • Nur benachrichtigen (Standard) — du wirst alarmiert und entscheidest selbst, was du auf der Seite meldest.
  • Benachrichtigen und Komponente umschalten — die Komponente geht auf den gewählten Zustand (z. B. „Großer Ausfall") und wieder auf „Funktionsfähig", wenn der Check erreichbar ist.

Zwei Regeln dabei: Einen Zustand, den jemand von Hand gesetzt hat, überschreibt der Check nicht. Und zurück auf „Funktionsfähig" stellt er die Komponente nur, wenn sie noch auf dem Zustand steht, den er selbst gesetzt hat.

Während einer Wartung bleibt der Check still: Läuft gerade eine Wartung, die seine Komponente betrifft, zählt ein Fehlschlag nicht als Ausfall. Niemand wird alarmiert, die Komponente wird nicht umgeschaltet, und die Uptime des Checks leidet nicht. In der Übersicht steht er dann blau auf „In Wartung". Ist der Dienst nach dem Ende der Wartung immer noch nicht erreichbar, alarmiert der nächste Lauf wie gewohnt. Wird er während der Wartung wieder erreichbar, kommt die Entwarnung trotzdem. Das gilt nur für Checks mit Komponente und nur für Wartungen, die laufen und veröffentlicht sind — eine Wartung, die noch auf die zweite Freigabe wartet, zählt nicht.

Mit „Auf der Statusseite zeigen" erscheint der Check zusätzlich mit gemessener Uptime und Antwortzeit-Diagramm auf deiner Seite — auch ohne Komponente.

Wer alarmiert wird

Pro Check wählst du:

  • Workspace-Mitglieder — bei einem neuen Check sind alle vorausgewählt. Sie bekommen die Mail in ihrer Profilsprache.
  • Integrationen der Statusseite (Slack, Teams, Discord, Google Chat, Webhook).
  • Weitere E-Mail-Adressen, z. B. eine Bereitschafts-Adresse — bis zu zehn.
  • SMS-Nummern im internationalen Format (+49…) — bis zu fünf, ab dem Pro-Tarif. Alarme per SMS zählen zum SMS-Kontingent deines Workspaces.

Alarmiert wird, wenn ein Check ausfällt und wenn er wieder erreichbar ist — mit den beiden Regionen, die den Ausfall bestätigt haben, und der Fehlermeldung (z. B. HTTP 503, „Keine Antwort innerhalb der Zeitgrenze", tls: certificate has expired). Gängige Fehler stehen in Mail und Chat übersetzt da; über die API kommen sie unverändert (timeout, keyword not found), damit Skripte darauf prüfen können.

Endet ein Ausfall, weil du den Check änderst, pausierst oder löschst, bekommen alle Empfänger eine kurze Nachricht „Ausfall beendet" — per Mail und über die Integrationen (Webhook-Ereignis monitor.closed), nicht per SMS. Sie sagt nur, dass der Ausfall geschlossen ist, nicht dass der Dienst wieder erreichbar ist: ist er nach einer Änderung weiter weg, alarmiert der nächste Lauf neu.

Unsere Anfragen erkennen

Jede Anfrage trägt den User-Agent

Statuswerk-Monitor/1.0 (+https://statuswerk.eu/monitoring)

Falls eine Firewall oder ein Bot-Schutz unsere Anfragen abweist, schalte diesen User-Agent frei. Wir verwenden keine Verbindung wieder, nutzen keinen Proxy und prüfen das TLS-Zertifikat — ein abgelaufenes Zertifikat ist für uns ein Ausfall.

Was wir nicht prüfen

Damit niemand über uns in fremde Netze schauen kann, rufen wir keine internen oder reservierten Adressen auf — auch nicht, wenn ein öffentlicher Name dorthin zeigt oder eine Weiterleitung dorthin führt. Andere Ports als 80, 443, 8080 und 8443 sind gesperrt.

Ausfälle nachvollziehen

Auf der Bearbeiten-Seite eines Checks steht unter Ausfälle jeder bestätigte Ausfall: Beginn, Ende, Dauer, bestätigende Regionen und Fehler. Ein einzelner Fehlschlag, den keine zweite Region bestätigt hat, taucht dort bewusst nicht auf.

Pausieren, ändern, löschen

  • Pausieren behält den Check, führt ihn aber nicht aus. Ein offener Ausfall wird dabei beendet und eine umgeschaltete Komponente geht zurück auf „Funktionsfähig" — ein pausierter Check soll nichts rot halten.
  • URL, Methode, erwarteten Status oder Stichwort ändern startet den Check neu, mit derselben Wirkung.
  • Löschen entfernt ihn samt Ausfällen und Antwortzeiten.

Tarife

Wie viele Checks du anlegen kannst und wie kurz das Intervall sein darf, steht im Tarifvergleich. Nach einem Wechsel in einen kleineren Tarif pausieren wir die neuesten Checks, die nicht mehr hineinpassen, und heben zu kurze Intervalle an. Wechselst du wieder hoch, laufen sie von selbst weiter — Checks, die du selbst pausiert hast, bleiben pausiert.

Über die API

Alles hier geht auch per API: GET/POST /api/v1/monitors, PATCH/DELETE /api/v1/monitors/{id} und GET /api/v1/monitors/{id}/outages. Details in der API-Referenz.

Regionen wählst du mit regions, einer Liste von Codes: fsn (Falkenstein), nbg (Nürnberg), hel (Helsinki), nl-ams1 (Amsterdam), pl-waw1 (Warschau), es-mad1 (Madrid). null oder weglassen heißt alle, auch künftige. Die Antwort enthält die wirksamen regions und all_regions.

Zugangsdaten setzt du mit auth_type (none, basic, bearer), auth_username, auth_password bzw. auth_token. Passwort und Token kann man nur schreiben. Die Antwort enthält nur auth.type und auth.username.