I’m already testing it in UAT environment.
I decided to use Hangfire to run recurring jobs (aka plugins) I developed to cache into Redis database.
https://www.traveltexas.com/#/ has been using it in Production for importing data from partners.
We’ve been using it for a stanford health study. so far so good. We will be using it for other clients as it seems to be working well
I work at a Fortune 500 bank based in the Midwest and we’ve had Hangfire in production for some time now, running jobs for various B2B customers working with large files. It’s a tad young here, but it’s definitely not going anywhere. We’re “all in” - a .Net based solution was vastly preferable for us. A major concern is having your job store be the reliable piece. We’re a Microsoft house, and SQL server is already deeply ingrained into our IT infrastructure, so that was an easy sell for us. I personally prefer the .Net Core approach (found here), but that area we do not use in production.
Just make sure you get the Hangfire Client and DLL sharing portion correct. That will largely be up to your design and architectural preferences for your system.
1 Like
We are using in our application in production. One of the biggest global telecom operator is our customer.
1 Like
We’re using Hangfire for scheduling and managing audio recording conversion processor that runs several million jobs a day. It’s been in production for about 8 months now. Here’s a snapshot of our job dashboard:
2 Likes
Just started using it in development about a week ago. So far it is doing what we need it to. Our site goes live in 4th quarter this year and if Hangfire continues to work like it has in test thus far, we’ll be deploying it to prod with our app.
You could say things are pretty serious… /Kip_Dynamite
3 Likes
We are are using it heavily in production.
We are using Hangfire on most of our projects with great satisfaction.
This one is for one webapplication that synchronizes data between other applications : 
(failed number are because of misconfig from final users)
2 Likes
Been in Prod for 1 week, and only getting this error in Prod. Can not replicate in lower environments…
Errors while compiling a Template. Please try the following to solve the situation: * If the problem is about missing/invalid references or multiple defines either try to load the missing references manually (in the compiling appdomain!) or Specify your references manually by providing your own IReferenceResolver implementation. See https://antaris.github.io/RazorEngine/ReferenceResolver.html for details. Currently all references have to be available as files! * If you get ‘class’ does not contain a definition for ‘member’: try another modelType (for example ‘null’ to make the model dynamic). NOTE: You CANNOT use typeof(dynamic) to make the model dynamic! Or try to use static instead of anonymous/dynamic types. More details about the error: - warning: (0, 0) Assuming assembly reference ‘System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ matches ‘System.Web.Mvc, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’, you may need to supply runtime policy - error: (84, 9) The type ‘System.Object’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’. Temporary files of the compilation can be found in (please delete the folder): C:\Windows\TEMP\RazorEngine_xjrmjhi5.5we
Looks like you have different .NET runtimes installed or a different version of ASP.NET set up on the IIS server you are using. Or some differences in your web.config (or web.configs if you use the IIS for other apps too).
Side note, might want to open a separate thread on this as this was not strictly the topic of this thread.
Currently using hangfire on an ascendant Brazilian E-commerce integrator
I’ve just introduced Hangfire 1.7.0-beta into production last week after a few weeks of testing and it seems to be working great.
We needed solid support for timezones and dst and so the beta with Cronos is really perfect for us.
Running beta code in production is always risky but we had some requirements that our old batch system just couldn’t handle. I’m doing low volume only 8 recurring jobs but if things continue to run this way I’ll migrate more jobs over to Hangfire.
In the process of moving from testing to production with HF. It’s working great on my test server which is a clone of the production server. On the other hand it’s throwing inexplicable exceptions with no useful information (no stack trace, no output of the inner exception) when I try to queue a job.
We are using this on production but we are facing issue with merge replication. Do any1 have idea on this?
As an update 3 months later we’re still running Hangfire 1.7.0 beta in production and I’ve migrated 30 more jobs over without any issues. We aren’t a high job volume implementation but our jobs are very important to customers and so the reliability is important.
@Mr_Excellent_Spirit: if Hangfire rocks on your prod server, it is an absolute demon on our prod server (and I mean that in a good way 
). 23M successful jobs in 26 months… about 100,000/month average, though the current volume is around 50,000 jobs/day
2 Likes