FerrisPulse

Qu’est-ce que FerrisPulse ?

FerrisPulse est un service de surveillance de heartbeat pour les jobs en arrière-plan et l’automatisation programmée. Au lieu de vérifier si une application répond aux requêtes HTTP, il attend un « ping » de succès de vos jobs cron, workers de file d’attente, backups et autres scripts.

Si le prochain heartbeat attendu n’arrive pas dans le délai configuré, FerrisPulse envoie une alerte de panne, puis un email de reprise automatiquement quand les pings reprennent. L’objectif est de transformer un « échec silencieux » (un job qui s’arrête sans que le reste du système semble défaillant) en incident visible avec une chronologie.

Fonctionnalités principales

• Surveillance de heartbeat pour les cadences de jobs attendues : FerrisPulse guette un ping de succès entrant selon un planning (ex. : horaire ou nocturne), et traite les pings manquants comme une panne.
• URL de ping de succès par moniteur : copiez une URL de ping spécifique au moniteur et appelez-la via HTTP POST uniquement après succès du job, pour que le « heartbeat » reflète un travail terminé.
• Alertes de panne + emails de reprise : en cas de heartbeat manquant, FerrisPulse envoie une alerte de panne ; au ping suivant, un email de reprise et fermeture de l’incident.
• Chronologie d’incidents et historique des heartbeats : le tableau de bord affiche statut, historique des heartbeats et fenêtres d’incidents, sans reconstruction manuelle à partir des logs.
• Cadence configurable et période de grâce : les moniteurs incluent un intervalle attendu et une période de grâce pour les variations de durée d’exécution.

Comment utiliser FerrisPulse

1. Créez un moniteur pour le job à suivre, définissez l’intervalle attendu (cadence) et ajoutez une période de grâce si nécessaire.
2. Copiez l’URL de ping du moniteur.
3. Dans votre automatisation, envoyez un HTTP POST à l’URL de ping uniquement après succès du job.
4. Laissez FerrisPulse tourner ; il détectera les heartbeats manquants, enverra des alertes de panne, puis des emails de reprise quand les pings reprennent.

Cas d’usage

• Job cron horaire : configurez un moniteur horaire et pinguez l’URL après fin du script. Si le script s’arrête silencieusement plusieurs heures, FerrisPulse envoie une alerte de panne avec la cadence attendue et un lien vers le tableau de bord.
• Vérification de snapshots de backup : pour des backups nocturnes, configurez un moniteur quotidien et émettez le ping uniquement après succès du backup. Cela détecte les blocages de pipeline sans alerter sur l’uptime global de l’app.
• Santé des workers de file (travail terminé, pas juste santé serveur) : avec des workers de file, envoyez le ping de succès après traitement. FerrisPulse alerte si la cadence de travail réussi s’arrête.
• Pipeline ETL/rapports programmé : pour syncs de facturation ou rapports horaires/quotidiens, pinguez en fin de workflow. FerrisPulse maintient une chronologie d’incidents pour tracer les exécutions manquées.
• Scripts d’automatisation déclenchés par infra programmée : interne ou externe, même workflow — pinguez après succès du script et laissez FerrisPulse détecter le silence.

FAQ

Comment notifier FerrisPulse qu’un job s’est exécuté ?

Appelez une URL de ping HTTP POST spécifique au moniteur après succès du job. FerrisPulse attend les pings selon la cadence configurée.

Qu’est-ce qui déclenche une alerte ?

Une alerte se déclenche si le prochain heartbeat/ping attendu n’arrive pas dans la cadence surveillée (avec support d’une période de grâce).

FerrisPulse alerte-t-il en boucle pendant un incident ?

La page décrit une alerte de panne par incident et un email de reprise séparé au retour du ping, évitant un storm d’alertes dupliquées.

Où voir ce qui s’est passé ?

FerrisPulse propose un tableau de bord avec statut, historique des heartbeats, fenêtres d’incidents et comportement des alertes en un seul endroit.

Quels systèmes de jobs supporte-t-il ?

Le site indique une utilisation avec cron, timers systemd, et écosystèmes workers/schedulers comme BullMQ, Sidekiq, Celery, GitHub Actions, plus langages/environnements comme Bash, Node.js, Python et Ruby.

Alternatives

• Surveillance uptime/contrôles de santé (vérifications d’extrémités HTTP) : Utile pour la disponibilité de l’app, mais peut manquer les « défaillances silencieuses » où le serveur web est sain tandis que les jobs en arrière-plan (cron/queues/backups) ne tournent pas.
• Alertes basées sur les logs : Les alertes peuvent être déclenchées par des messages d’erreur a posteriori, mais il faut souvent vérifier activement les logs et cela ne détecte pas les exécutions manquantes aussi directement qu’un heartbeat.
• Notifications des planificateurs de jobs (alertes cron/systemd/GitHub Actions intégrées) : Certains environnements notifient les échecs, mais le workflow diffère car FerrisPulse repose sur un ping de succès explicite et surveille le rythme attendu.
• Outils de surveillance de queues axés sur l’arriéré/débit : Ils suivent le comportement des workers et queues, mais FerrisPulse surveille spécifiquement la présence de heartbeats de succès au moment de l’achèvement du travail.