FerrisPulse

Was ist FerrisPulse?

FerrisPulse ist ein Heartbeat-Monitoring-Service für Background-Jobs und geplante Automatisierungen. Statt zu prüfen, ob eine App auf HTTP-Anfragen reagiert, erwartet es einen Erfolgs-„Ping“ von Ihren Cron-Jobs, Queue-Workern, Backups und anderen Skripten.

Falls der nächste erwartete Heartbeat innerhalb des konfigurierten Intervalls ausbleibt, sendet FerrisPulse eine Down-Alarmmeldung und dann automatisch eine Recovery-E-Mail, sobald die Pings wieder ankommen. Das Ziel ist es, „stille Ausfälle“ (ein Job, der stoppt, während der Rest des Systems gesund wirkt) in einen sichtbaren Vorfall mit Zeitachse zu verwandeln.

Wichtige Funktionen

• Heartbeat-Überwachung für erwartete Job-Intervalle: FerrisPulse wartet auf einen eingehenden Erfolgs-Ping nach Zeitplan (z. B. stündlich oder nächtlich) und behandelt fehlende Pings als Down-Zustand.
• Erfolgs-Ping-URL pro Monitor: Kopieren Sie eine monitor-spezifische Ping-URL und rufen Sie sie per HTTP POST nur nach erfolgreichem Job-Abschluss auf, damit der „Heartbeat“ abgeschlossene Arbeit widerspiegelt.
• Down-Alarme plus Recovery-E-Mails: Bei fehlendem Heartbeat sendet FerrisPulse einen Down-Alarm; beim nächsten Ping sendet es eine Recovery-E-Mail und schließt den Vorfall.
• Vorfalls-Zeitachse und Heartbeat-Historie: Das Dashboard zeigt Status, Heartbeat-Historie und Vorfallsfenster, statt dass Sie Ausfälle aus Logs rekonstruieren müssen.
• Konfigurierbares Intervall und Grace Period: Monitore umfassen ein erwartetes Intervall und können eine Grace Period für Laufzeitvariationen enthalten.

FerrisPulse nutzen

1. Erstellen Sie einen Monitor für den zu überwachenden Job, legen Sie das erwartete Intervall (Kadenz) fest und fügen Sie bei Bedarf eine Grace Period hinzu.
2. Kopieren Sie die Ping-URL des Monitors.
3. Senden Sie in Ihrer Automatisierung einen HTTP POST an die Ping-URL nur nach erfolgreichem Job-Abschluss.
4. Lassen Sie FerrisPulse laufen; es erkennt fehlende Heartbeats, sendet Down-Alarme und dann Recovery-E-Mails, sobald die Pings wieder ankommen.

Anwendungsfälle

• Cron-Job, der stündlich laufen soll: Richten Sie einen stündlichen Monitor ein und pingen Sie die URL nach Skript-Ende. Bei stillem Ausfall über mehrere Stunden sendet FerrisPulse einen Down-Alarm mit erwarteter Kadenz und Dashboard-Link.
• Backup-Snapshot-Verifizierung: Für nächtliche Backups konfigurieren Sie einen täglichen Monitor und senden den Ping nur nach erfolgreichem Backup-Abschluss. So fangen Sie Pipeline-Staus ab, ohne breitere App-Uptime-Alarme auszulösen.
• Queue-Worker-Gesundheit (abgeschlossene Arbeit, nicht nur Server-Gesundheit): Bei Queue-Workern senden Sie den Erfolgs-Ping nach Verarbeitungsende. FerrisPulse alarmiert, wenn die erwartete Kadenz abgeschlossener Arbeit stoppt.
• Geplante ETL-/Reporting-Pipelines: Für stündliche oder tägliche Abrechnungssyncs oder Reports pingen Sie am Workflow-Ende. FerrisPulse hält eine Vorfalls-Zeitachse, damit verpasste Läufe trackbar werden.
• Automatisierungsskripte durch geplante Infrastruktur: Egal ob interner oder externer Zeitplan – Workflow bleibt gleich: Ping nach erfolgreichem Skript-Ende senden und FerrisPulse Stille erkennen lassen.

FAQ

Wie melde ich FerrisPulse, dass ein Job gelaufen ist?

Sie rufen eine monitor-spezifische HTTP POST Ping-URL nach erfolgreichem Job-Abschluss auf. FerrisPulse erwartet Pings im konfigurierten Intervall.

Was löst einen Alarm aus?

Ein Alarm wird ausgelöst, wenn der nächste erwartete Heartbeat/Ping bis zum Monitorkadenz (mit Grace-Period-Unterstützung) ausbleibt.

Alarmiert FerrisPulse während eines Vorfalls wiederholt?

Die Seite beschreibt einen Down-Alarm pro Vorfall und eine separate Recovery-E-Mail beim Ping-Rückkehr, um Alert-Stürme zu vermeiden.

Wo sehe ich, was passiert ist?

FerrisPulse bietet eine Dashboard-Ansicht mit Status, Heartbeat-Historie, Vorfallsfenstern und Alert-Verhalten an einem Ort.

Welche Job-Systeme unterstützt es?

Die Site gibt an, es funktioniert mit cron, systemd-Timern und Worker-/Scheduler-Ökosystemen wie BullMQ, Sidekiq, Celery, GitHub Actions sowie Sprachen/Umgebungen wie Bash, Node.js, Python und Ruby.

Alternativen

• Uptime-/Health-Check-Überwachung (HTTP-Endpunkt-Checks): Nützlich für App-Verfügbarkeit, übersieht aber „stille Ausfälle“, bei denen der Webserver funktioniert, während Background-Jobs (Cron/Queues/Backups) nicht laufen.
• Log-basierte Alarme: Können durch Fehlermeldungen ausgelöst werden, erfordern aber oft aktives Log-Checken und erkennen fehlende Ausführungen nicht so direkt wie ein Heartbeat.
• Job-Scheduler-Benachrichtigungen (integrierte Cron/systemd/GitHub Actions-Alarme): Manche Umgebungen benachrichtigen bei Fehlern, aber der Workflow unterscheidet sich, da FerrisPulse explizite Erfolgs-Pings zentriert und erwartete Kadenz überwacht.
• Queue-Überwachungstools für Backlog/Throughput: Diese tracken Worker- und Queue-Verhalten, FerrisPulse überwacht aber speziell das Vorhandensein von Erfolgs-Heartbeats zum Abschluss der Arbeit.