Website-Uptime-Monitoring schickt in festen Abständen eine Anfrage an Ihre Website und prüft die Antwort. Ist die Antwort falsch, zu langsam oder bleibt sie aus, bekommen Sie einen Alarm. Das klingt einfach, und das ist es auch. Der Wert steckt in den Details: wie oft geprüft wird, was als Fehler zählt, wie ein Fehler bestätigt wird und wie schnell die richtige Person davon erfährt.
Uptimecheck führt HTTP(S)-, Ping- und Port-Checks jede Minute oder alle 2, 5, 10, 15 oder 30 Minuten oder stündlich aus. Jeder Check erfasst Statuscode und Antwortzeit, sodass Sie sowohl Ausfälle als auch langsame Phasen sehen. Wenn Sie zuerst die Grundlagen möchten, lesen Sie was Uptime-Monitoring ist und warum es wichtig ist.
Check-Typen
HTTP(S): eine URL per GET, POST oder einer anderen Methode abrufen, eigene Header und einen eigenen Body senden und den Statuscode, ein Keyword oder JSON-Felder in der Antwort prüfen.Ping: bestätigen, dass ein Host im Netzwerk antwortet, mit der Round-Trip-Zeit.Port: prüfen, ob ein Dienst wie ein Mailserver oder ein Datenbank-Listener Verbindungen annimmt.
Für Abläufe über mehrere Seiten, etwa Login oder Checkout, nutzen Sie das Flow-Monitoring.
Warum jede Minute prüfen – und doppelt
Ausfallzeit kostet Geld, Minute für Minute. Wenn Ihr Checkout um 03:12 Uhr mit 503 antwortet und es niemand bemerkt, bis das erste Support-Ticket eintrifft, haben Sie Stunden statt Minuten verloren. Unser Leitfaden zu den Kosten von Website-Ausfällen rechnet es durch.
Uptimecheck prüft aus Stockholm, London und New York und bestätigt jeden Fehler von einem zweiten Standort aus, bevor ein Vorfall eröffnet wird. Das reduziert Fehlalarme durch eine einzelne verlorene Anfrage oder einen kurzen Netzwerk-Schluckauf, während ein echter Ausfall Sie trotzdem innerhalb von ein bis zwei Minuten erreicht. Unser Leitfaden zum Reduzieren von Fehlalarmen erklärt, warum das wichtig ist.
Vom fehlgeschlagenen Check zur Behebung
03:12: Der Check auf northwind.shop/checkout liefert 503.03:12: Auch der zweite Check schlägt fehl. Ein Vorfall wird eröffnet, mit der fehlerhaften Antwort und einem Screenshot dessen, was Besucher gesehen haben.03:13: Die Entwicklerin in Rufbereitschaft bekommt eine Push-Benachrichtigung aufs Handy, und der Team-Kanal erhält die Details in Slack.03:19: Die Checks sind wieder erfolgreich. Eine Entwarnung mit der gesamten Ausfallzeit geht raus.
Alarme gehen per E-Mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, Webhooks und Push-Benachrichtigungen aufs Handy raus – in jedem Tarif. Unter Alarme und Benachrichtigungen finden Sie Routing und Eskalation, unter Incident-Management, was nach dem Alarm passiert. Kombinieren Sie das Monitoring mit einer Statusseite, damit Ihre Kunden wissen, was los ist, ohne ein Ticket zu eröffnen.
Antwortzeiten, aufgeteilt in Phasen
Jeder HTTP-Check speichert seine Antwortzeit, aufgeteilt in DNS, Verbindungsaufbau, TLS, Server und Download. Eine langsame Server-Phase deutet auf Ihre Anwendung hin, langsames DNS oder TLS auf die Infrastruktur. Diagramme zeigen Median, 95. Perzentil und Durchschnitt, sodass sich langsame Ausreißer nicht hinter einem guten Durchschnitt verstecken. Mehr zur Antwortzeit von Websites.
Legen Sie ein Limit fest, etwa 2.000 ms, und Sie erhalten einen Langsam-Alarm, wenn drei Checks in Folge langsamer sind, und einen weiteren, sobald die Website wieder schneller wird. Langsame Phasen zählen nicht als Ausfallzeit.
Die Seite des Monitors listet seine letzten Checks. Drei oder mehr gleiche Checks in Folge werden zu einer Zeile zusammengefasst, etwa „OK · 200 × 18“ mit der Spanne der Antwortzeiten, und lassen sich aufklappen, um jeden einzelnen Check zu zeigen. Ein Fehler wird nie in eine Reihe erfolgreicher Checks eingeklappt, und der zweite Check, der einen Fehler bestätigt, behält seine eigene Zeile. Wurde ein nicht pausierter Monitor seit dem Doppelten seines Intervalls nicht geprüft, zeigt die Seite „No recent data“ mit dem Zeitpunkt des letzten Checks – so geht ein alter Status nie als aktueller durch.
Prüfen, ob die Seite wirklich funktioniert
Eine Seite kann mit 200 antworten und trotzdem kaputt sein: eine leere Produktliste, eine Fehlermeldung, eine Wartungsseite. Fügen Sie Antwortprüfungen hinzu, die alle bestehen müssen:
Erwarteter Status: Codes oder Bereiche, etwa 200-299 oder 200,301.Keyword: Text, den die Seite enthalten muss oder nicht enthalten darf, etwa „In den Warenkorb“.JSON und Header: für APIs etwa ein Feld wie $.status gleich ok oder ein Header, der vorhanden sein muss.
HTTPS-Monitore lesen außerdem das Zertifikat aus und erinnern Sie, bevor es abläuft. Siehe SSL-Monitoring.
Ihren ersten Monitor einrichten
URL eingeben, Check-Typ wählen, festlegen, was als gültige Antwort zählt, und die Alarmkanäle auswählen. „Test request“ zeigt die Antwort, bevor Sie speichern, und der erste Check läuft sofort. Die meisten Teams starten mit drei Monitoren: der Startseite, der wichtigsten Conversion-Seite (Checkout, Registrierung oder Login) und dem wichtigsten API-Endpunkt. Sie wechseln von UptimeRobot, Better Stack, Pingdom oder StatusCake? Importieren Sie Ihre Monitore samt Einstellungen und sehen Sie jeden einzelnen, bevor etwas angelegt wird.
Was als Ausfall zählt
Ein Check schlägt fehl, wenn die Anfrage in ein Timeout läuft, die Verbindung abgelehnt wird, das Zertifikat ungültig ist, der Statuscode nicht dem erwarteten entspricht oder eine Antwortprüfung nicht besteht. Uptime ist der Anteil der Zeit ohne bestätigten Ausfall, und Wartungsfenster werden nicht angerechnet. Berichte zeigen die Uptime je Monitor für jeden beliebigen Zeitraum im Vergleich zu Ihrem SLA-Ziel, mit CSV-Export.
Tarife ab 9 € pro Monat bei jährlicher Abrechnung oder 12 € bei monatlicher Abrechnung, zzgl. MwSt., mit Checks jede Minute in jedem kostenpflichtigen Tarif – oder kostenlos für 5 Monitore, die alle 5 Minuten geprüft werden. Vergleichen Sie Monitore, Statusseiten und Verlauf (1, 2 oder 3 Jahre) auf der Preisseite, sehen Sie sich die Live-Demo ohne Registrierung an oder starten Sie eine 14-tägige kostenlose Testphase ohne Kreditkarte.