Ein Uptime-Check fragt aktiv nach: Ein Monitoring-Dienst sendet nach Zeitplan eine Anfrage an Ihre Website oder API und alarmiert Sie, wenn die Antwort falsch ist oder ausbleibt. Ein Heartbeat funktioniert umgekehrt: Ihr Job oder Dienst sendet bei jedem Lauf eine Anfrage an den Monitoring-Dienst, und der Alarm wird ausgelöst, wenn diese Anfrage nicht eintrifft. Nutzen Sie Uptime-Checks für alles, was Menschen über das Netzwerk erreichen, und Heartbeats für Aufgaben, die nach Zeitplan laufen oder keine öffentliche Adresse haben. Die meisten Setups brauchen beides.
Die beiden werden leicht verwechselt, weil am Ende jeweils „Alarm, wenn etwas nicht stimmt“ steht. Sie erkennen aber unterschiedliche Fehler, und wer das eine nutzt, wo das andere nötig wäre, hat einen blinden Fleck, der erst auffällt, wenn etwas kaputtgeht.
So funktioniert ein Uptime-Check
Der Monitoring-Dienst ist der Client. Jede Minute oder in dem Intervall, das Sie wählen, ruft er eine URL ab, pingt einen Host an oder öffnet einen Port und bewertet die Antwort: den Statuscode, die Antwortzeit, ein Keyword auf der Seite, das Zertifikat. Schlägt der Check fehl und bestätigt ein zweiter Check den Fehler, erhalten Sie einen Alarm. Das ist eine Form von synthetischem Monitoring: Ein Roboter tut, was ein Besucher tun würde.
Das erkennt er: eine Website oder API, die ausgefallen oder langsam ist, mit Fehlern antwortet, falsche Inhalte zeigt oder durch ein abgelaufenes Zertifikat oder eine DNS-Änderung nicht funktioniert. Also alles, worauf ein Besucher stoßen würde.
Das übersieht er: alles, was nicht auf Anfragen antwortet. Ein Backup, das nicht gelaufen ist, ein Queue-Worker, der hängt, ein Import, der um 02:00 Uhr fehlgeschlagen ist. Die Website bleibt erreichbar, also besteht jeder Check.
So funktioniert ein Heartbeat
Ihr Job ist der Client. Sie teilen dem Monitoring-Dienst mit, wann der Job laufen soll, und der Job ruft nach Abschluss eine eindeutige Ping-URL auf. Kommt der Ping später als die von Ihnen gewählte Karenzzeit, erhalten Sie einen Alarm. Dahinter steckt das Prinzip des Totmannschalters: Stille ist das Signal. Deshalb heißt Heartbeat-Monitoring auch Push-Monitoring oder Dead-Man’s-Switch-Monitoring.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
Das erkennt er: Jobs, die nicht gestartet sind, vor dem Ende abgestürzt sind, nach dem falschen Zeitplan liefen oder, mit einem Start-Ping, viel zu lange gelaufen sind. Mit einem Exit-Code im Ping erkennt er auch Jobs, die gelaufen und fehlgeschlagen sind.
Das übersieht er: ob überhaupt jemand Ihren Dienst erreichen kann. Ein Job auf einem Server kann munter pingen, während die Website auf demselben Server jedem Besucher mit 502 antwortet.
Im direkten Vergleich
Uptime-CheckHeartbeatWer sendet die AnfrageDer Monitoring-DienstIhr Job oder DienstAlarm, wenndie Antwort falsch oder langsam ist oder ausbleibtder Ping zu spät kommt oder einen Fehler meldetBraucht eine öffentliche AdresseJaNein, nur ausgehendes HTTPSEinrichtungEine URL, ein Host oder ein PortEin Zeitplan, eine Karenzzeit und eine Anfrage im JobSiehtWas Besucher und API-Clients erlebenOb Hintergrundaufgaben gelaufen sind und wie sie geendet habenBlind fürAufgaben, die nicht auf Anfragen antwortenOb jemand den Dienst erreichen kann
Wann ein Uptime-Check sinnvoll ist
Ihre Startseite und die Seiten, mit denen Sie Geld verdienen: Checkout, Registrierung, Login.
Öffentliche APIs und Webhook-Empfänger, mit Prüfung des Statuscodes und des zurückgelieferten JSON.
Ein Health-Check-Endpunkt, der bei jeder Anfrage die Datenbank und andere Abhängigkeiten testet.
Dienste auf anderen Ports, etwa ein Mailserver, mit einem Port-Check.
Die Faustregel: Wenn ein Mensch oder ein anderes System etwas aufruft, prüfen Sie es von außen, genau so wie diese.
Wann ein Heartbeat sinnvoll ist
Cron-Jobs: Datenbank- und Datei-Backups, nächtliche Importe und Exporte, Berichtserstellung, Abrechnungsläufe.
Geplante Aufgaben in anderer Form: eine Windows-Aufgabe in der Aufgabenplanung, ein Kubernetes-CronJob, ein zeitgesteuerter GitHub-Actions-Workflow, eine Serverless-Funktion mit Timer.
Skripte zur Zertifikatserneuerung und Datensynchronisationen zwischen Systemen.
Alles hinter einer Firewall oder NAT, das von außen nicht erreichbar ist, aber ausgehende HTTPS-Anfragen senden kann.
Dauerhaft laufende Worker
Ein Queue-Worker oder Daemon läuft nicht nach Zeitplan, kann aber trotzdem einen Heartbeat senden. Pingen Sie alle paar Minuten aus der Hauptschleife und geben Sie dem Monitor ein Intervall statt eines Cron-Ausdrucks. Hängt die Schleife, wird der Prozess beendet oder startet der Server neu, ohne ihn wieder hochzufahren, bleiben die Pings aus und Sie erfahren davon. Pingen Sie aus der Schleife, die die eigentliche Arbeit erledigt, nicht aus einem separaten Thread, sonst meldet ein festhängender Worker weiterhin, dass alles in Ordnung ist.
Wann Sie beides brauchen
Die meisten echten Dienste haben eine Eingangstür und ein Backoffice. Überwachen Sie beides mit dem Werkzeug, das es sieht:
Ein Onlineshop: Uptime-Checks für Startseite und Checkout, Heartbeats für den nächtlichen Bestellexport und das Datenbank-Backup.
Ein SaaS-Produkt: ein Uptime-Check für den Health-Endpunkt der API, Heartbeats für den Queue-Worker und den Job, der Rechnungen versendet.
Ein interner Dienst: keine öffentliche Adresse, also ein Heartbeat aus dem Dienst selbst, dazu Uptime-Checks für die öffentlichen Seiten, die von seinen Daten abhängen.
Eine Alternative ist, den Job-Status über den Health-Endpunkt bereitzustellen, etwa indem der Check fehlschlägt, wenn das letzte Backup älter als 25 Stunden ist. Das funktioniert, koppelt aber die Uptime Ihrer Website an Ihre Backups, sodass ein verspätetes Backup in Ihren Berichten als Ausfall der Website erscheint. Ein separater Heartbeat hält die beiden Signale getrennt, ebenso wie die Personen, die den jeweiligen Alarm erhalten.
Das richtige Timing
Intervall für Uptime-Checks: jede Minute für umsatzrelevante Seiten, denn das Intervall ist die längste Zeit, in der Sie von einem Ausfall nichts merken. Weniger kritische Seiten kommen mit einem längeren Intervall aus.
Karenzzeit für Heartbeats: länger als die normale Schwankung beim Ende des Jobs. Ein Backup, das um 03:00 Uhr startet, 5 bis 20 Minuten dauert und am Ende pingt, braucht mindestens 20 Minuten Karenzzeit; 30 lassen Spielraum für eine langsame Nacht.
Maximale Laufzeit: Mit einem Start-Ping werden Sie alarmiert, wenn ein Lauf viel länger dauert als üblich. Ein hängender Job sendet zwar auch nie seinen Abschluss-Ping, aber dieser Alarm kommt, sobald das Limit überschritten ist.
Zeitzone: Ein Cron-Zeitplan läuft in der Zeitzone des Servers, oft UTC. Geben Sie dem Monitor dieselbe, sonst erwartet er den Job wegen der Zeitumstellung zweimal im Jahr eine Stunde zu früh oder zu spät. Das Cron-Ausdruck-Tool zeigt, wann ein Zeitplan tatsächlich läuft.
Häufige Fehler
Nur beim Start pingen. Ein Job, der startet und abstürzt, meldet sich trotzdem. Pingen Sie am Ende oder senden Sie beides.
Auch dann pingen, wenn der Job fehlschlägt. backup.sh; curl … pingt, egal was passiert ist. Nutzen Sie && oder senden Sie den Exit-Code, damit ein Fehler auch als Fehler gemeldet wird.
Ein Ping, der den Job blockieren kann. Geben Sie curl ein Timeout und Wiederholungen mit (-m 10 –retry 3), damit ein langsames Netzwerk weder den Job aufhält noch den Ping verliert.
Einen Heartbeat für eine öffentliche Website nutzen. Ein Server, der nach außen pingt, beweist nur, dass er das Internet erreicht, nicht dass Besucher ihn erreichen.
Den Cron-Daemon statt des Jobs überwachen. Der Daemon kann einwandfrei laufen, während ein einzelner Job jede Nacht fehlschlägt. Jeder wichtige Job bekommt seinen eigenen Heartbeat.
Mehr zur Heartbeat-Seite lesen Sie in Cron-Jobs überwachen und verpasste Cron-Aufgaben verhindern.
Beides an einem Ort mit Uptimecheck
Uptimecheck betreibt beide Arten von Monitoren im selben Konto, mit denselben Alarmkanälen und derselben Vorfallshistorie.
Uptime-Monitoring: HTTP(S)-, Ping- und Port-Checks bis zu jede Minute aus Stockholm, London und New York, wobei jeder Fehler vor einem Alarm von einem zweiten Standort bestätigt wird. HTTP-Checks können Statuscode, Keyword, JSON-Felder und Header prüfen.
Cron-Job-Monitoring: ein Crontab-Ausdruck in Ihrer Zeitzone, inklusive Sommerzeit, oder ein einfaches Intervall; eine Karenzzeit von 1 Minute bis 6 Stunden; /start-Pings mit einer maximalen Laufzeit von 1 Minute bis 24 Stunden; /fail oder der Exit-Code, um zu melden, wie ein Lauf geendet hat; und die mit dem Ping gesendete Ausgabe des Jobs, die im Alarm angezeigt wird.
Limits: Start enthält 15 Uptime-Monitore und 10 Cron-Jobs, Professional 100 und 50, Business 250 und 150. Siehe Preise.
Zur Einrichtung lesen Sie einen Cron-Job mit einem Heartbeat überwachen und die Ping-Beispiele für Cron-Jobs für Laravel, Kubernetes, GitHub Actions, systemd und Windows. Für Festplatten und Arbeitsspeicher des Servers darunter ergänzen Sie Server-Monitoring.
Behalten Sie Eingangstür und Backoffice im Blick. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.