# Cron-Jobs & Backups überwachen: wenn stille Hintergrund-Prozesse ausfallen > Warum fehlgeschlagene Backups und Cron-Jobs oft unbemerkt bleiben, und wie ein Dead Man's Switch den stillen Ausfall abfängt. Mit Setup-Anleitung. Source: https://uptimeify.io/de/blog/cron-jobs-backups-ueberwachen Der gefährlichste Ausfall ist der, den niemand bemerkt. Eine Website, die offline geht, schreit: Besucher beschweren sich, das Monitoring schlägt an, jemand reagiert. Ein Backup, das seit drei Wochen nicht mehr läuft, schweigt. Es gibt keine Fehlermeldung, kein rotes Signal, keinen Anruf. Der Ausfall wird erst sichtbar, wenn du das Backup dringend brauchst, und feststellst, dass es nicht existiert. **Cron-Jobs und Backups überwacht man deshalb anders als eine Website**: nicht, indem man auf ein Fehlersignal wartet, sondern indem man auf ein erwartetes Lebenszeichen achtet. Dieser Artikel erklärt, warum stille Prozesse durchs Raster fallen, wie ein Dead Man's Switch sie abfängt, und wie du das in wenigen Minuten einrichtest. - **Stille Hintergrund-Prozesse werfen im Fehlerfall keine Fehlermeldung**: ein Backup, das nicht startet, ist eine Abwesenheit, kein Alarm. - **Klassisches Monitoring wartet auf ein Signal, das gerade dann ausbleibt**, deshalb übersieht es genau diese Ausfälle. - **Ein Dead Man's Switch kehrt die Logik um:** Der Job meldet sich; bleibt die Meldung aus, wird alarmiert. - **Das Setup ist minimal:** eine zusätzliche Zeile im Skript, die nach erfolgreichem Lauf eine eindeutige URL pingt. - **Für Agenturen:** unbemerkte Backup-Ausfälle sind ein stilles Haftungsrisiko. Ein Heartbeat macht sie sichtbar. ## Warum stille Prozesse durchs Raster fallen Das übliche Monitoring einer Website funktioniert nach einem einfachen Prinzip: Man fragt regelmäßig „läuft die Seite?" und wartet auf die Antwort. Kommt keine oder eine fehlerhafte Antwort, ist klar, dass etwas kaputt ist. Dieses Modell ist stark, aber es setzt voraus, dass es überhaupt etwas gibt, das man anfragen kann. Genau das fehlt bei Hintergrund-Prozessen. Ein Cron-Job, ein nächtliches Backup, ein Daten-Import, ein Cache-Warmer, all das läuft nicht an einer Adresse, die man abfragen könnte. Es läuft im Verborgenen, gesteuert von einem Zeitplan, und meldet sich normalerweise bei niemandem. Und hier liegt die Tücke: Wenn ein solcher Prozess fehlschlägt, entsteht in den meisten Fällen kein Ereignis, das man beobachten könnte. Ein Backup-Skript, das wegen eines geänderten Datenbank-Passworts nicht mehr durchläuft, wirft die Fehlermeldung höchstens in ein Log, das niemand liest. Ein Cron-Job, den ein voller Datenträger stoppt, hinterlässt keine Spur im Blickfeld. Der Ausfall ist eine **Abwesenheit**, und Abwesenheit lässt sich mit klassischem Monitoring nicht erkennen, weil da nichts ist, worauf man reagieren könnte. Das ist der Grund, warum diese Ausfälle oft wochenlang unbemerkt bleiben. Nicht, weil sie selten wären, sondern weil sie leise sind. Und leise Ausfälle sind die teuersten, weil man von ihnen genau dann erfährt, wenn es zu spät ist. Klassisches Monitoring erkennt einen Ausfall an einem Signal, aber ein fehlgeschlagener Cron-Job oder ein nicht gestartetes Backup erzeugt kein Signal, sondern eine Abwesenheit. Abwesenheit ist unsichtbar, bis man das Ergebnis braucht. ## Der Dead Man's Switch: Monitoring umgedreht Die Lösung für ein Problem der Abwesenheit ist, die Abwesenheit selbst zum Alarm zu machen. Genau das leistet ein Dead Man's Switch, ein Konzept, das den Namen von jenen Sicherheitsschaltern hat, die auslösen, sobald der Bediener sie loslässt. Übertragen aufs Monitoring heißt das: Nicht das Fehlersignal löst den Alarm aus, sondern das Ausbleiben des Erfolgssignals. Die Mechanik ist elegant einfach. Der überwachte Job bekommt die Aufgabe, sich nach jedem erfolgreichen Durchlauf kurz zu melden: ein „Ich habe funktioniert" an eine Monitoring-Stelle zu senden. Dieses Lebenszeichen nennt man Heartbeat. Das Monitoring wiederum weiß, in welchem Rhythmus dieser Heartbeat kommen soll: alle 24 Stunden beim nächtlichen Backup, alle fünf Minuten beim häufigen Cron-Job, einmal pro Woche beim wöchentlichen Report. Solange die Heartbeats pünktlich eintreffen, ist alles ruhig. Bleibt einer aus, weil der Job abstürzte, gar nicht startete oder mittendrin hängen blieb, erwartet das Monitoring das Signal vergeblich und schlägt Alarm. Der entscheidende Unterschied zum klassischen Modell: Hier wird **die Stille zum Auslöser**. Man muss den Fehler nicht mehr sehen können; es genügt, dass das erwartete Erfolgssignal ausbleibt. Damit wird genau die Sorte Ausfall sichtbar, die vorher unsichtbar war: der stille, spurlose, teure. Ein Dead Man's Switch macht die Abwesenheit eines Erfolgssignals zum Alarm. Der Job sendet nach jedem Erfolg einen Heartbeat; bleibt der erwartete Heartbeat aus, wird alarmiert. Die Stille selbst wird sichtbar. ## Das Setup: ein Cron-Job in wenigen Minuten Die Stärke dieses Ansatzes ist, wie wenig er verlangt. Um einen Cron-Job zu überwachen, brauchst du keine neue Infrastruktur und keine Bibliothek, nur eine einzige zusätzliche Zeile am Ende deines Skripts. Der Ablauf hat drei Schritte. **Schritt 1: Einen Heartbeat-Monitor anlegen.** Im Monitoring erstellst du einen Heartbeat-Check und legst das erwartete Intervall fest, also wie oft der Job sich melden soll, plus eine Toleranz für normale Laufzeitschwankungen. Für ein nächtliches Backup etwa: erwarteter Heartbeat alle 24 Stunden, mit einigen Stunden Kulanz. Der Monitor gibt dir eine eindeutige Ping-URL zurück. **Schritt 2: Den Ping ins Skript einbauen.** Am Ende deines Cron-Jobs oder Backup-Skripts, nach dem erfolgreichen Teil, fügst du einen kurzen Aufruf dieser URL hinzu. Mit `curl` ist das eine Zeile: ```bash # ... dein Backup- oder Cron-Job läuft hier ... # Nach erfolgreichem Durchlauf: Heartbeat senden curl -fsS --retry 3 https://uptimeify.io/heartbeat/ > /dev/null ``` Wichtig ist die Platzierung: Der Ping steht **nach** dem eigentlichen Arbeitsschritt, sodass er nur ausgelöst wird, wenn dieser durchgelaufen ist. Bricht das Skript vorher ab, wird der Ping nie erreicht, und genau das ist gewünscht, denn dann bleibt der Heartbeat aus und der Alarm greift. **Schritt 3: Alarmierung verknüpfen.** Zuletzt hängst du den Heartbeat-Monitor an dieselbe Alarmierung wie deine übrigen Checks. Bleibt ein Lebenszeichen aus, läuft der Alarm über die Kanäle, die du ohnehin nutzt, bei Uptimeify über dieselbe bestätigte, EU-gehostete Benachrichtigung wie bei Website- oder Server-Monitoren. Das war es. Ab jetzt weißt du am selben Tag, wenn ein Backup ausfällt, nicht erst in dem Moment, in dem du es zurückspielen willst. Das Setup ist dreistufig und minimal: Heartbeat-Monitor mit erwartetem Intervall anlegen, eine Ping-Zeile ans Ende des Skripts setzen, an die bestehende Alarmierung hängen. Der Ping steht nach dem Arbeitsschritt, damit nur echter Erfolg zählt. ## Was sich überwachen lässt, jenseits von Backups Backups sind das offensichtlichste Beispiel, aber das Prinzip trägt viel weiter. Überall, wo ein Prozess planmäßig laufen soll und sein Ausfall keine sichtbare Spur hinterlässt, ist ein Heartbeat die passende Antwort. Ein paar typische Kandidaten aus dem Agentur-Alltag. **Datenbank-Backups** sind der Klassiker: nächtlich, unsichtbar, kritisch. **Daten-Importe und -Exporte**, etwa ein nächtlicher Sync zwischen Shop und Warenwirtschaft, fallen still aus, bis die Bestände nicht mehr stimmen. **Cache-Warmer und geplante Bereinigungen** halten eine Seite schnell und aufgeräumt; ihr Ausfall zeigt sich erst schleichend in schlechter Performance. **Wiederkehrende Reports und Rechnungsläufe**, ein Skript, das monatlich Rechnungen erzeugt oder Reports verschickt, dürfen keinen Monat aussetzen, ohne dass es auffällt. **Zertifikats- oder Token-Erneuerungen**, die per Cron laufen, sind besonders tückisch: Ihr stiller Ausfall wird erst sichtbar, wenn etwas abläuft und plötzlich nichts mehr geht. Das verbindende Muster ist immer dasselbe: ein zeitgesteuerter Prozess, dessen Erfolg niemand aktiv sieht und dessen Fehlschlag erst mit Verzögerung schmerzt. Für jeden davon gilt dieselbe einfache Kur: ein Heartbeat am Ende des Skripts, ein erwartetes Intervall im Monitoring. Jeder zeitgesteuerte Prozess, dessen Ausfall keine Spur hinterlässt, verdient einen Heartbeat. Sieh dir an, wie sich Cron-Jobs, Backups und Imports mit erwarteten Intervallen und bestätigter Alarmierung überwachen lassen. ## Warum das für Agenturen ein Haftungsthema ist Für eine Agentur ist ein unbemerkter Backup-Ausfall nicht nur ein technisches Ärgernis, sondern ein stilles Risiko mit realen Folgen. Der Moment, in dem ein Backup gebraucht wird, ist definitionsgemäß ein Krisenmoment: ein Server ist ausgefallen, Daten sind verloren, eine Migration ging schief. In genau diesem Moment festzustellen, dass die letzten drei Wochen an Backups fehlen, verwandelt eine beherrschbare Panne in eine Katastrophe. Und die Frage, die dann im Raum steht, lautet nicht „warum ist der Server ausgefallen?", sondern „warum habt *ihr* nicht gemerkt, dass die Backups nicht liefen?". Genau hier liegt der Wert eines Heartbeats über das rein Technische hinaus. Er verschiebt die Verantwortung von „wir hoffen, dass die Backups laufen" zu „wir wissen, dass sie laufen, und werden am selben Tag informiert, wenn nicht". Diese Gewissheit ist etwas, das du deinem Kunden gegenüber vertreten kannst, und sie schützt dich in dem Gespräch, das im Ernstfall unweigerlich kommt. Ein Backup, dessen Lauf jeden Tag bestätigt wird, ist ein belegbares Versprechen; ein Backup, das „eigentlich laufen sollte", ist eine Hoffnung. Für Agenturen, die kritische Infrastruktur für ihre Kunden betreiben, ist die Überwachung stiller Prozesse deshalb kein technisches Extra, sondern Teil der Sorgfaltspflicht. Der Aufwand, eine Zeile pro Skript, steht in keinem Verhältnis zum Risiko, das er abfängt. Ein unbemerkter Backup-Ausfall wird zum Haftungsthema, sobald das Backup gebraucht wird. Ein Heartbeat verschiebt die Lage von „wir hoffen, es läuft" zu „wir wissen es und werden sofort gewarnt". Aus einer Hoffnung wird ein belegbares Versprechen. ## Vom blinden Fleck zur lückenlosen Sicht Der eigentliche Gewinn dieses Ansatzes ist, dass er einen blinden Fleck schließt, von dem viele gar nicht wissen, dass sie ihn haben. Die meisten Monitoring-Strategien decken das Sichtbare ab: Websites, Server, Dienste, die antworten, wenn man fragt. Die stillen Prozesse im Hintergrund, die niemand fragt und die sich nie von selbst melden, bleiben außen vor. Sie laufen im Vertrauen, dass sie laufen, bis dieses Vertrauen eines Tages enttäuscht wird. Ein Dead Man's Switch schließt diese Lücke mit minimalem Aufwand und kehrt das Prinzip um, das ihn nötig macht: Statt darauf zu warten, dass ein Problem laut wird, machst du die Stille selbst hörbar. Jeder erwartete Heartbeat, der ausbleibt, wird zu einer frühen, klaren Warnung, lange bevor die Konsequenz sichtbar wird. Für jeden zeitgesteuerten Prozess, der deinen Kunden wichtig ist, ist das der Unterschied zwischen „wir haben es rechtzeitig gemerkt" und „wir haben es zu spät gemerkt". Am Ende geht es um dieselbe Haltung wie beim gesamten Monitoring: nicht überrascht zu werden. Der Unterschied ist nur, dass die stillen Prozesse die einzigen sind, die dich ohne einen Heartbeat garantiert überraschen, und zwar im ungünstigsten Moment. Eine Zeile im Skript schließt genau diese Lücke. Schließ den blinden Fleck in deinem Monitoring. Sieh dir an, wie Uptimeify Cron-Jobs und Backups per Heartbeat überwacht, EU-gehostet, mit derselben bestätigten Alarmierung wie deine übrigen Monitore.