Hangfire.HttpJob schedules HTTP calls as Hangfire background and recurring jobs

What the extension adds to Hangfire

Hangfire.HttpJob is a Hangfire extension whose stated purpose is separating job scheduling from business logic. The repository description puts it plainly: httpjob for Hangfire, restful api for Hangfire, job scheduling and business logic separated.

The feature list is six items and they are the whole product. You can add a delayed background job by HTTP post or on the dashboard. You can add a recurring job by HTTP post or on the dashboard. You can search for a job by job name on the dashboard. You can stop or start a job on the dashboard. There is a cron generator on the dashboard. And there is the Hangfire.HttpJob.Agent extension, described as a way to quickly develop a job program.

The design idea is that a scheduled job is not a delegate to a method in your application but a description of an HTTP request. That has a real appeal in a specific architecture. If the work lives in a service you do not control, or in a system that is not a .NET application, or in a team whose deployment you cannot push to, then scheduling the call from Hangfire is the only option that does not require a change on the other side.

The dashboard is a significant part of the surface, and it is worth being clear that this is not just a background library with an API. Four of the six features are dashboard operations: creating jobs, recurring jobs, searching by job name, and starting and stopping jobs. A cron generator sits alongside them. For an operator, that means the tool is partly a control panel.

The primary language is C#, the licence is MIT, the repository is not archived, and the last push was on 2026-04-18. There are no GitHub releases.

Installing the three NuGet packages and where each one fits

The library is distributed as NuGet packages, and the README lists three of them:

Install-Package Hangfire.HttpJob

Install-Package Hangfire.HttpJob.Agent

Install-Package Hangfire.HttpJob.Client

The three packages map onto the three ways you interact with the feature. The core package, Hangfire.HttpJob, is what the server needs in order to run the HTTP jobs and to expose the dashboard pages and the REST endpoint. The Agent package is the helper for building the job programs, and the README describes it as a way to quickly develop a job program with web jobs that support scheduling, with visualisation of the execution process through logs and progress on the Hangfire dashboard, and with a variety of web job types with different life cycles. Those types are listed as Singleton, Transient, and Hang up until stop command, which is a way of saying a job instance can be long lived, stopped on demand, or one-shot.

The Client package is the programmatic way to enqueue a job from another system, which is the third of the three ways the README lists for adding a job. The next section covers it.

The repository layout matches the packaging. There are Agent, Client, Server and Test directories alongside the solution file, which is a familiar shape for a .NET solution with a server component, a client library and a helper package, and it tells you that the server side and the client side are separately deployable artefacts.

The documentation lives in a wiki rather than in the repository, with a quick start and Docker quick start entry, then pages on how to create a background http job, how to create a recurring http job, how to use HttpJob.Agent, how to use it in sqlserver, and how to configure a mail service to report the job result. That mail page is the one to read before you rely on the notification feature.

The REST endpoint, and the payload it accepts

The REST interface is the part that matters for integration, because it is how a job gets created without deploying anything to the Hangfire server's own application.

The endpoint is reached by posting to a path with an operation query parameter, and the two operations are backgroundjob and recurringjob:

url:http://{hangfireserver}/hangfire/httpjob?op=backgroundjob
method:post
data:
{
  "Method": "POST",
  "ContentType": "application/json",
  "Url": "http://XXXXXXX",
  "DelayFromMinutes": 1,
  "Data": "{\"userName\":\"test\"}",
  "Timeout": 5000,

The payload is a description of the HTTP call to make: the method, the content type, the target URL, the body as a string, and a timeout in milliseconds. For a background job there is a delay in minutes, and the recurring example in the README adds a cron expression instead, spelled Corn in the JSON of that second example, which is worth knowing before you guess at the field name.

Two fields are about credentials rather than about the request. BasicUserName and BasicPassword are described in the README as the two parameters to set if you want Hangfire to send basic authentication when it executes the HTTP call, and they are left empty in the example.

The recurring example uses a cron value of 0 12 * */2, so the same payload shape covers both operations, with the schedule field being the only real difference, plus a job name to identify it on the dashboard.

Security is the obvious question about an endpoint like this, because anyone who can post to it can schedule an arbitrary outbound HTTP request from your server, with your server's network position. The README does not describe authentication or authorisation for this endpoint, which is a gap you have to close yourself with whatever your host provides.

Registering the extension in the ASP.NET Core startup

Enabling the feature in the host application is a small addition to the Hangfire configuration, and the README's startup example shows the whole shape of it.

The service registration is the standard Hangfire call, and the extension is added as a Use method on the global configuration, right after UseConsole:

		globalConfiguration.UseStorage(
				new MySqlStorage(
					"Server=localhost;Port=3306;Database=hangfire;Uid=root;Pwd=123456;charset=utf8;SslMode=none;Allow User Variables=True",
					new MySqlStorageOptions
					{
						TransactionIsolationLevel = IsolationLevel.ReadCommitted,
						QueuePollInterval = TimeSpan.FromSeconds(15),
						JobExpirationCheckInterval = TimeSpan.FromHours(1),
						CountersAggregateInterval = TimeSpan.FromMinutes(5),
						PrepareSchemaIfNecessary = false,
						DashboardJobListLimit = 50000,
						TransactionTimeout = TimeSpan.FromMinutes(1),
					}))
			.UseConsole()
			.UseHangfireHttpJob();

The UseHangfireHttpJob() call is the entire integration on the server side. Everything before it in the chain is ordinary Hangfire configuration, and the storage options shown are a MySQL storage with a 15 second queue poll interval, hourly job expiration checks and five minute counter aggregation.

Those example values are not recommendations and should not be deployed as they are. The connection string in the sample carries a username and a password in clear text, and the dashboard authorisation in the same example accepts a hardcoded login and password with RequireSsl set to false and SslRedirect set to false, which means the dashboard would be served over plain HTTP with credentials that anyone reading the file knows.

The dashboard itself is mounted with app.UseHangfireDashboard and the Hangfire server with app.UseHangfireServer, and the HttpJob pages live under the /hangfire path along with the REST endpoint, so a dashboard that is locked down also locks down the job creation endpoint.

Enqueuing from code with the client package

The third way to create a job is the client library, and it is the one that fits an integration where the caller already has a .NET application.

The client points at a server URL and calls one of two static methods, AddBackgroundJob or AddRecurringJob, each taking a job description and a set of options for the server credentials:

    Install-Package Hangfire.HttpJob.Client

    var serverUrl = "http://localhost:5000/job";
    var result = HangfireJobClient.AddBackgroundJob(serverUrl, new BackgroundJob

The job description carries the same fields as the REST payload, which is the point of the design: the three entry points produce the same job. Method and Url describe the call, Mail is a list of addresses to notify, SendSucMail asks for a success notification, and DelayFromMinutes schedules a background job. The recurring variant adds a Cron value and a Data object holding the request body, and the README's example for it is a Post with an anonymous object as the body and a cron of 40 17 * * *.

The HangfireServerPostOption carries the basic authentication credentials for the Hangfire server itself, so the client authenticates to the server as a caller. That is a separate concern from the BasicUserName and BasicPassword on the job, which are the credentials the server will present to the target URL when it makes the call. Two different pairs of credentials, and a configuration that is easy to mix up.

For a recurring job the cron value is the piece worth getting right, and the dashboard's cron generator is there to help produce it.

Where Hangfire.HttpJob is the wrong tool

Three limits, and the first is the one that decides whether you need this at all.

The first is that an HTTP hop is a cost, and in the common case it is a cost you do not need to pay. If the job target is code you deploy, then a plain Hangfire job that invokes a method in your own assembly is strictly simpler: no network, no timeout, no serialisation of the payload, no external system that can be down, and the stack trace points at your code rather than at an HTTP response. The extension exists for the case where the target is genuinely remote, and adopting it outside that case means paying a network failure mode for a job that did not need one.

The second is the security surface, which the README's own examples make concrete. The REST endpoint accepts an arbitrary outbound URL and method, which makes it a request forgery primitive by design, and the README does not describe how it is authenticated. The dashboard example ships with a fixed credential pair and SSL disabled. A production deployment has to replace both, and the fact that the configuration lives in a startup file rather than in a secret store means the credentials are likely to end up in source control.

The third is the state of the project. The README is written in a mixture of English and Chinese, the example job names and mail addresses use Chinese strings, the wiki is the primary documentation and it lives outside the repository, and there are no GitHub releases at all. The last push was on 2026-04-18, so the code is not frozen, but there is no release history to pin against and no changelog to consult for what changed.

The alternative approach is to keep the job in process. The concrete test is whether the thing you want to schedule is something you can deploy. If it is, a Hangfire job with a method reference is the better design, and the extension's value evaporates. If it is not, then a generic HTTP scheduler is the right shape, and the question becomes whether this extension or a dedicated scheduler built around a cron-driven HTTP client is the better fit, with the difference being that a dedicated scheduler owns the retry and alerting behaviour that Hangfire already gives you.

Editorial conclusion

Adopt Hangfire.HttpJob if you already run Hangfire and need to schedule calls against a third party or a separate service, since defining the job as an HTTP request with a method, URL, payload, delay and cron removes the need to deploy a worker assembly for every scheduled task. Do not adopt it if you can call the target in process, because an HTTP hop adds a network failure mode and a timeout to work that did not need either, and do not deploy the configuration in the README as it stands, because it contains example database credentials and dashboard basic auth credentials in clear text. Verify first that your Hangfire version and storage provider are compatible with the extension, that the outgoing request credentials and the dashboard authorisation are replaced with your own secrets, that the mail notification path is configured if you rely on it, and that the job naming and cron values behave the way your operators expect on the dashboard.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. yuzd/Hangfire.HttpJob on GitHub