Der Backup-Job, der plötzlich stillstand
Anstatt dass AmICited Ihren Server abfragt, ruft Ihr geplanter Job nach jeder erfolgreichen Ausführung seine eigene eindeutige Ping-URL auf. Wird das erwartete Intervall zuzüglich einer Toleranzzeit verpasst, wird ein Vorfall eröffnet — so werden Fehler erkannt, die reguläre Uptime-Prüfungen nicht sehen können.
Stille ist der Alarm
Ein Cron-Job, der abstürzt, ein Backup, das nicht mehr läuft, ein Import, der hängt — keiner von ihnen erreicht einen öffentlichen Endpunkt, den ein Monitor prüfen könnte. Heartbeats kehren das Modell um: Ihr Job beweist, dass er lebt, und AmICited meldet sich nur, wenn es still wird.
- ✓Eindeutige Ping-URL pro Job — eine Zeile am Ende eines Skripts, keine serverseitige Abfrage erforderlich.
- ✓Erwartetes Intervall und Toleranzzeit — legen Sie fest, wie oft der Job laufen soll und wie viel Spielraum er hat, bevor ein Fehlschlag zählt.
- ✓Benachrichtigungen an die richtigen Personen — Benachrichtigungsempfänger werden pro Heartbeat konfiguriert, genau wie bei jedem anderen Monitor.
- ✓Erkennt, was Uptime-Prüfungen nicht können — nächtliche Backups, geplante Importe und Queue-Worker werden nie von einer Besucheranfrage getroffen.
Teilen Sie dem System mit, wann ein Fehlschlag erwartet wird
Ein Heartbeat, den Sie für geplante Wartungsarbeiten bewusst pausiert haben, sollte keinen Vorfall auslösen. Planen Sie ein Wartungsfenster ein, damit sowohl Heartbeats als auch Uptime-Monitore verstehen, dass die Lücke erwartet wird und kein Fehler ist.
- ✓Eingrenzung nach Domain oder Monitor — unterdrücken Sie genau die Prüfungen, die von den geplanten Arbeiten betroffen sind.
- ✓Wiederkehrend oder einmalig — ein nächtliches Deploy-Fenster oder eine einzelne geplante Migration, beides möglich.
- ✓SLA-Berechnung bleibt korrekt — geplante Ausfallzeiten werden nie auf Ihr Uptime-Ziel angerechnet.
Bereit, den Job zu erkennen, der plötzlich stillstand?
Free check · 7-day trial · no credit card