UPTIMESHIELD führt in festen Intervallen Prüfungen aus und speichert das Ergebnis. Die Verfügbarkeit ist der Anteil erfolgreicher Prüfungen an allen Prüfungen ohne Wartungszeit – eine messwertbasierte Erfolgsquote, keine sekundengenaue Aufzeichnung.
1. Ablauf einer Prüfung
- Zielprüfung: Bei Web-Monitoren wird die URL normalisiert und validiert (nur http/https, Ports 80, 443, 8080, 8443, keine Zugangsdaten in der URL). TCP-Monitore dürfen nur die Ports 21, 22, 25, 53, 80, 110, 143, 443, 465, 587, 993, 995, 8080, 8443 prüfen.
- DNS-Auflösung: Alle aufgelösten IP-Adressen müssen öffentlich sein. Interne, lokale und reservierte Bereiche sowie die Sperrliste werden abgelehnt.
- Anfrage: Je nach Monitortyp HTTP-Anfrage (GET oder HEAD), Zertifikatsprüfung, DNS-Abfrage oder TCP-Verbindung mit Zeitlimit von 10 Sekunden. Die Verbindung wird an die geprüfte IP gebunden.
- Weiterleitungen: Bis zu 5 Stationen, sofern das Folgen von Weiterleitungen aktiv ist. Jede Station wird erneut vollständig validiert.
- Bewertung: Erfolg, wenn der Statuscode in der Liste der akzeptierten Codes liegt. Zusätzlich gilt je Typ: Keyword (Text muss enthalten sein oder darf nicht enthalten sein, gelesen werden die ersten 256 KB), API/JSON (JSON-Pfad mit Operator), SSL (strikte Prüfung inklusive Kette und Hostname), DNS (erwarteter Wert optional), TCP (Verbindung kommt zustande), Heartbeat (Ping trifft rechtzeitig ein).
- Wiederholung: Schlägt die Prüfung fehl, folgt sofort eine zweite. Nur wenn auch sie fehlschlägt, wird ein Fehlschlag gespeichert.
Die einzelnen Monitortypen beschreibt die Seite Monitortypen.
2. Statusmodell
| Status | Bedeutung |
|---|---|
| Online | Letzte Prüfung erfolgreich, Antwortzeit unter der Schwelle, Zertifikat nicht kurz vor Ablauf. |
| Beeinträchtigt | Erreichbar, aber langsam (2000 ms als Standardschwelle, einstellbar) oder das Zertifikat läuft bald ab. |
| Wird geprüft | Ausfallverdacht: Es gab einen Fehlschlag, die Bestätigung steht aus. |
| Störung | 2 aufeinanderfolgende Fehlschläge (Standard, einstellbar): Störung bestätigt, Ereignis eröffnet, Benachrichtigung ausgelöst. |
| Wartung | Ein Wartungsfenster ist aktiv: kein Alarm, die Zeit zählt nicht in die Uptime. |
| Pausiert | Der Monitor wurde angehalten und prüft nicht. |
| Unbekannt | Noch keine verlässliche Messung vorhanden, etwa bei einem Heartbeat-Monitor ohne ersten Ping. |
Ein fehlgeschlagener Prüfversuch beweist noch keinen tatsächlichen Ausfall. Als Beginn einer Störung gilt der Zeitpunkt der ersten fehlgeschlagenen Prüfung der bestätigenden Serie; das Ende ist die erste erfolgreiche Folgeprüfung. Die Dauer ist daher eine Schätzung mit der Genauigkeit des Prüfintervalls.
Ein Langsam-Alarm wird nach 3 aufeinanderfolgenden langsamen Prüfungen ausgelöst. Erinnerungen bei andauernder Störung sind wählbar (nie, 15, 30, 60 Minuten, 3, 12 oder 24 Stunden). Ruhezeiten pro Konto pausieren Erinnerungen und Langsam-Alarme; Ausfall und Wiederherstellung werden immer gesendet.
3. Mehrere Standorte und Mehrheitsentscheid
Sind mehrere Standorte für einen Monitor aktiv, gilt eine Störung nur, wenn mehr als die Hälfte der erreichbaren Standorte den Fehler bestätigt. Die Ergebnisse je Standort stehen im Prüfprotokoll. Je Monitor wählbar sind in Solo bis zu 3, in Max bis zu 6 Standorte, sofern eingerichtet.
Wichtig: Ohne zusätzlich eingerichtete Standorte misst nur der Hauptstandort. Der Mehrheitsentscheid greift dann nicht.
4. Berechnung der Verfügbarkeit
Uptime (%) = erfolgreiche Prüfungen ÷ alle Prüfungen (ohne Wartungszeit) × 100
Berechnet wird für 24 Stunden, 7, 30, 90 und 365 Tage. Zeiträume bis einschließlich 7 Tage stammen aus den Rohdaten, längere Zeiträume aus der Tagesverdichtung (Uptime in Prozent und durchschnittliche Antwortzeit je Tag, 400 Tage aufbewahrt). Zeiträume, in denen der Monitor noch nicht bestand, werden als „unvollständig“ gekennzeichnet. Wartungszeiten zählen nicht mit. Die Zahl ist eine Stichprobenquote und nicht identisch mit der tatsächlichen Verfügbarkeit in jeder Sekunde. Rechenbeispiel: Website-Verfügbarkeit berechnen.
5. Antwortzeit
Die Antwortzeit ist die Gesamtdauer der Anfrage inklusive aller Weiterleitungen. Teilwerte (DNS, Verbindung, TLS, TTFB) werden angezeigt, soweit messbar. Ausgewertet werden Median, p95, Durchschnitt, Minimum und Maximum; die Statistiken basieren ausschließlich auf erfolgreichen Prüfungen. Ein Vergleich zur Vorperiode und eine Monatsübersicht über 12 Monate stehen im Dashboard und in den Berichten bereit. Einordnung: Antwortzeit interpretieren.
6. Grenzen der Messwerte
- Auflösung = Intervall: Ausfälle, die kürzer sind als das Prüfintervall, können zwischen zwei Prüfungen unentdeckt bleiben.
- HTTP-Antwortzeit ist keine Browser-Ladezeit: Rendering, JavaScript, Bilder und Schriften sind nicht enthalten.
- Mehrere Standorte nur, wenn eingerichtet: Ohne Zusatzstandorte misst nur der Hauptstandort und sieht keine regionalen Probleme.
- Heartbeat hängt vom Ping-Sender ab: Bleibt der Ping aus, kann das am Skript, am Server des Absenders oder am Netz liegen, nicht nur am Cronjob selbst.
- Bot-Schutz: Firewalls oder CDNs des Ziels können Fehler auslösen, die Besucher nicht sehen.
- Keine Anmeldung: Geschützte Bereiche hinter Logins werden nur geprüft, soweit sich dies über eigene Header oder eine API abbilden lässt.
Weitere Hintergründe: Grenzen automatischer Website-Prüfungen.
7. Datenhaltung
Rohdaten je Prüfung werden je Tarif 30 Tage (Solo), 180 Tage (Pro) bzw. 365 Tage (Max) aufbewahrt, danach gelöscht. Tagesverdichtete Statistiken bleiben 400 Tage erhalten, das Benachrichtigungsprotokoll 90 Tage. Details in der Datenschutzerklärung. Wie der Prüf-Worker selbst läuft, zeigt der Systemstatus.