Comparativa
Alternativa a Hangfire — jobs programados sin alojar un scheduler
Hangfire es excelente para el procesamiento de jobs en cola dentro de tu app. SteadyCron se encarga de la parte de ese trabajo que en realidad es solo «ejecutar esto según un horario» — movida fuera del proceso por completo.
Programar, ejecutar y monitorizar — un solo producto.
| SteadyCron | Hangfire | |
|---|---|---|
| Jobs fire-and-forget / en cola desde request handlers | No — no es su función | Sí — su punto fuerte |
| Jobs recurrentes programados (tipo cron) | Sí — llama a tu endpoint desde fuera | Sí — `RecurringJob.AddOrUpdate` |
| Almacenamiento necesario para programar | Ninguno — disparador sin estado | SQL Server, Redis u otro almacén persistente |
| Corre dentro de tu proceso de app | No — disparador HTTP externo | Sí — compite con el manejo de peticiones por recursos |
| Sobrevive a un deploy/reinicio a mitad de horario | Sí — el horario vive fuera de la app | Depende de la durabilidad del almacenamiento y la config del servidor |
| Retries con backoff | Sí — configurable por job | Sí — atributo `AutomaticRetry` |
| Dashboard / historial de jobs | Sí — alojado, sin configuración de auth necesaria | Sí — autoalojado, necesita su propia auth |
| Monitoreo a nivel de código .NET | Sí — SDK `SteadyCron.Monitoring` (`TrackAsync`) | N/A |
| Continuations / batches / cadenas de jobs | No | Sí |
| Opción de alojamiento en la UE | Sí — Hetzner, Alemania | Autoalojado, tú elijes |
Comparativa basada en información pública disponible en el momento de la redacción. Los detalles sobre Hangfire pueden haber cambiado — consulta su sitio para la información más reciente.
Los puntos fuertes de Hangfire
Hangfire es una librería madura y bien construida para el procesamiento de jobs en cola dentro de una aplicación .NET: encolar un job desde una acción de controlador, encadenar continuations, agrupar trabajo relacionado en batches, reintentar automáticamente, e inspeccionar todo en un dashboard. Si tus jobs se disparan por eventos de la aplicación — una subida de archivo, un pedido realizado, un webhook que tu app recibió — Hangfire es la herramienta correcta, y SteadyCron no intenta sustituir eso.
Dónde divergen los dos: el job recurrente
Hangfire también hace jobs recurrentes —
RecurringJob.AddOrUpdate("report", () => GenerateReport(), Cron.Daily). Eso
es un horario cron que vive dentro de tu app, respaldado por SQL Server o
Redis solo para que el horario sobreviva a un reinicio.
Esa es exactamente la parte para la que está construido SteadyCron. En lugar de una llamada a un método que Hangfire invoca desde almacenamiento que consulta, exponer un simple endpoint HTTP y que SteadyCron lo llame según el horario — con retries, timeout y un registro de ejecución completo — desde completamente fuera del proceso y la base de datos de tu aplicación. Sin tabla de almacenamiento que provisionar, sin estado de job recurrente que mantener consistente entre instancias si escalas horizontalmente.
Conserva tu instrumentación .NET
Si prefieres no tocar el disparador y solo quieres monitoreo, el
SDK SteadyCron.Monitoring
envuelve cualquier método — disparado por Hangfire o no — con TrackAsync,
de modo que SteadyCron sepa que el job corrió, cuánto tardó, y si falló, sin
cambiar dónde vive el horario.
¿Cuál deberías elegir?
- Mantén Hangfire para jobs fire-and-forget encolados desde tu aplicación, continuations, batches, y todo lo que necesite correr dentro de tu app en respuesta a eventos de la aplicación.
- Pásate a SteadyCron para la parte de jobs recurrentes que en realidad es solo «llamar a esto según un horario» — y prefieres no mantener el almacenamiento, el escalado o la auth del dashboard de Hangfire solo para mantener vivo ese horario.
- Usa ambos si eso es lo que tu app realmente necesita: Hangfire para trabajo en cola dentro del proceso, SteadyCron para jobs recurrentes disparados desde fuera, y el SDK de .NET si quieres que SteadyCron monitoree jobs que sigan siendo disparados por Hangfire.
Preguntas frecuentes
¿SteadyCron sustituye a Hangfire?
No por completo, y prefiermos decirlo claramente antes que sobrevenderlo. Si usas Hangfire para jobs fire-and-forget encolados desde un request handler, continuations o procesamiento por batches, SteadyCron no encaja — eso es claramente territorio de Hangfire. Si usas Hangfire principalmente para `RecurringJob.AddOrUpdate` — un job que simplemente corre según un horario —, esa parte puede salir completamente de tu app: SteadyCron llama a un endpoint HTTP según el horario en su lugar, y ya no necesitas el almacenamiento de SQL Server o Redis de Hangfire solo para mantener vivo un horario tipo cron.
¿Por qué sacar los jobs programados de Hangfire en vez de simplemente optimizarlo?
Los jobs recurrentes de Hangfire corren dentro de tu proceso de aplicación y leen del mismo almacenamiento (a menudo la misma base de datos) que tu app usa para todo lo demás. Un job de backup, un generador de informes o una tarea de limpieza que se dispara a las 2 de la madrugada ahora comparte conexiones y CPU con todo lo demás que corre en ese proceso. Mover el disparador a SteadyCron — una llamada HTTP desde fuera — desacopla esa carga por completo del runtime de tu app; tu endpoint hace el trabajo cuando se le llama, y nada tiene que correr continuamente en segundo plano esperando el siguiente tick.
¿Puedo seguir monitoreando jobs desde mi app .NET?
Sí. El SDK `SteadyCron.Monitoring` te da `TrackAsync` para envolver cualquier método — incluido uno que siga siendo disparado por Hangfire, un job de Quartz.NET, o un `BackgroundService` normal —, de modo que SteadyCron sepa cuándo empezó, tuvo éxito o falló, y te alerte si no corre a tiempo. El SDK nunca sustituye a tu scheduler; solo le dice a SteadyCron qué pasó.
¿Y el dashboard de Hangfire?
El dashboard de Hangfire es realmente bueno para inspeccionar colas y el estado de los retries, y si sigues usando Hangfire para trabajo en cola, mantenlo. El dashboard de SteadyCron cubre los jobs que SteadyCron realmente dispara — horario, registro de ejecuciones, códigos de respuesta — sin que tengas que configurar autorización para una página de administración adicional en tu app.
Prueba SteadyCron gratis
5 HTTP jobs y 10 heartbeat checks, gratis para siempre. Sin tarjeta de crédito.
Prueba SteadyCron gratis