Comparatif
Alternative à Hangfire — jobs planifiés sans héberger de scheduler
Hangfire excelle dans le traitement de jobs en file d'attente à l'intérieur de votre app. SteadyCron prend en charge la part de ce travail qui consiste juste à « exécuter ceci selon un planning » — déplacée entièrement hors du processus.
Planifier, exécuter et surveiller — un seul produit.
| SteadyCron | Hangfire | |
|---|---|---|
| Jobs fire-and-forget / en file depuis des handlers de requêtes | Non — pas son rôle | Oui — son point fort |
| Jobs récurrents planifiés (type cron) | Oui — appelle votre endpoint depuis l'extérieur | Oui — `RecurringJob.AddOrUpdate` |
| Stockage requis pour la planification | Aucun — trigger sans état | SQL Server, Redis, ou un autre stockage persistant |
| Tourne dans votre processus applicatif | Non — trigger HTTP externe | Oui — entre en concurrence avec le traitement des requêtes |
| Survit à un déploiement/redémarrage en cours de planning | Oui — le planning vit hors de l'app | Dépend de la durabilité du stockage et de la config serveur |
| Relances avec backoff | Oui — configurable par job | Oui — attribut `AutomaticRetry` |
| Tableau de bord / historique des jobs | Oui — hébergé, aucune config d'auth nécessaire | Oui — auto-hébergé, nécessite sa propre auth |
| Monitoring au niveau du code .NET | Oui — SDK `SteadyCron.Monitoring` (`TrackAsync`) | N/A |
| Continuations / batches / chaînes de jobs | Non | Oui |
| Option d'hébergement EU | Oui — Hetzner, Allemagne | Auto-hébergé, à votre choix |
Comparaison fondée sur des informations publiques au moment de la rédaction. Les détails concernant Hangfire peuvent avoir changé — consultez leur site pour la dernière version.
Les points forts de Hangfire
Hangfire est une bibliothèque mature et bien conçue pour le traitement de jobs en file d’attente à l’intérieur d’une application .NET : mettre un job en file depuis une action de contrôleur, enchaîner des continuations, regrouper des travaux liés en batch, relancer automatiquement, et tout inspecter dans un tableau de bord. Si vos jobs sont déclenchés par des événements applicatifs — un upload utilisateur, une commande passée, un webhook reçu par votre app — Hangfire est le bon outil, et SteadyCron ne cherche pas à remplacer cela.
Là où les deux divergent : le job récurrent
Hangfire fait aussi des jobs récurrents —
RecurringJob.AddOrUpdate("report", () => GenerateReport(), Cron.Daily). C’est
un planning cron qui vit à l’intérieur de votre app, soutenu par SQL Server ou
Redis uniquement pour que le planning survive à un redémarrage.
C’est exactement la part pour laquelle SteadyCron est conçu. Plutôt qu’un appel de méthode que Hangfire déclenche depuis un stockage qu’il interroge, vous exposez un simple endpoint HTTP et SteadyCron l’appelle selon le planning — avec relances, timeout et journal d’exécution complet — entièrement en dehors du processus et de la base de données de votre application. Aucune table de stockage à provisionner, aucun état de job récurrent à maintenir cohérent entre instances si vous scalez horizontalement.
Gardez votre instrumentation .NET
Si vous préférez ne pas toucher au déclencheur et voulez juste du monitoring,
le SDK SteadyCron.Monitoring
enveloppe n’importe quelle méthode — déclenchée par Hangfire ou non — avec
TrackAsync, afin que SteadyCron sache que le job a tourné, combien de temps
il a pris, et s’il a échoué, sans changer où vit le planning.
Que choisir ?
- Gardez Hangfire pour les jobs fire-and-forget mis en file depuis votre application, les continuations, les batches, et tout ce qui doit tourner à l’intérieur de votre app en réponse à des événements applicatifs.
- Passez à SteadyCron pour la part des jobs récurrents qui consiste vraiment juste à « appeler ceci selon un planning » — et que vous préférez ne pas maintenir le stockage, le scaling ou l’auth du tableau de bord de Hangfire juste pour garder ce planning en vie.
- Utilisez les deux si c’est réellement ce dont votre app a besoin : Hangfire pour le travail en file à l’intérieur du processus, SteadyCron pour les jobs récurrents déclenchés depuis l’extérieur, et le SDK .NET si vous voulez que SteadyCron surveille des jobs toujours déclenchés par Hangfire.
Questions fréquentes
SteadyCron remplace-t-il Hangfire ?
Pas entièrement, et nous préférons le dire clairement plutôt que de survendre. Si vous utilisez Hangfire pour des jobs fire-and-forget mis en file depuis un handler de requête, des continuations ou du traitement par batch, SteadyCron ne convient pas — c'est clairement le territoire de Hangfire. Si vous utilisez Hangfire principalement pour `RecurringJob.AddOrUpdate` — un job qui tourne simplement selon un planning —, cette partie peut sortir entièrement de votre app : SteadyCron appelle un endpoint HTTP selon le planning à la place, et vous n'avez plus besoin du stockage SQL Server ou Redis de Hangfire juste pour maintenir un planning de type cron en vie.
Pourquoi sortir les jobs planifiés de Hangfire plutôt que simplement l'optimiser ?
Les jobs récurrents de Hangfire tournent à l'intérieur de votre processus applicatif et lisent depuis le même stockage (souvent la même base de données) que votre app utilise pour tout le reste. Un job de sauvegarde, un générateur de rapport ou une tâche de nettoyage qui se déclenche à 2 h du matin partage désormais connexions et CPU avec tout ce qui tourne dans ce processus. Déplacer le déclencheur vers SteadyCron — un appel HTTP depuis l'extérieur — découple entièrement cette charge du runtime de votre app ; votre endpoint fait le travail quand il est appelé, et rien n'a besoin de tourner en continu en arrière-plan en attendant le prochain tick.
Puis-je toujours surveiller les jobs depuis mon app .NET ?
Oui. Le SDK `SteadyCron.Monitoring` fournit `TrackAsync` pour envelopper n'importe quelle méthode — y compris une toujours déclenchée par Hangfire, un job Quartz.NET, ou un simple `BackgroundService` — afin que SteadyCron sache quand elle a démarré, réussi ou échoué, et vous alerte si elle ne tourne pas à l'heure. Le SDK ne remplace jamais votre scheduler ; il informe simplement SteadyCron de ce qui s'est passé.
Et le tableau de bord de Hangfire ?
Le tableau de bord de Hangfire est vraiment bon pour inspecter les files et l'état des relances, et si vous continuez à utiliser Hangfire pour du travail en file, gardez-le. Le tableau de bord de SteadyCron couvre les jobs que SteadyCron déclenche réellement — planning, journal d'exécution, codes de réponse — sans que vous ayez à configurer l'autorisation d'une page d'administration supplémentaire dans votre app.
Essayez SteadyCron gratuitement
5 tâches HTTP et 10 heartbeats, gratuits pour toujours. Sans carte bancaire.
Essayez SteadyCron gratuitement