Celebration time!

I’m pleased to announce the release of JobRunr v6.0.0 (which is now available via Maven Central) and JobRunr Pro v6.0.0 which is available for customers with a subscription. As this is a major release, there are also some small breaking changes.

Some great new features to both JobRunr and JobRunr Pro!

New features in JobRunr

  • Job Builders: You can now create jobs using the JobBuilder and RecurringJobBuilder which allows you to configure all the aspects of a Job via this builder instead of the @Job annotation. This means you can now have one api to create jobs with different settings (including name and amount of retries). An example on how to use the JobBuilder:
    .withName("My Enqueued Job")
    .withDetails(() -> service.doWork()));

Off course, you can also schedule jobs:

    .withName("My Scheduled Job")
    .withDetails(() -> service.doWork()));

And this also works for JobRequests:

    .withName("Scan " + file.getName() + " for viruses")
    .withJobRequest(new ScanFileForVirusJobRequest(file.getAbsolutePath())));

  • Job Labels: Support for Job Labels! From now on, you can tag jobs with labels (think of a tenant / customer id / … ). These labels will be visible in the dashboard. Oh, did you know that in the pro version, you can search for these labels in the dashboard! A label can be added both via the existing @Job annotation or the new JobBuilder:
@Job(name="My Job", labels={"fast-running-job", "tenant-%0"})
void myFastJob(String tenandId) {
 // your business logic
    .withName("My Enqueued Job")
    .withLabels("fast-running-job", "tenant-" + tenantId)
    .withDetails(() -> service.doWork()));
  • Server name visible in dashboard: from now on, the server name is also visible in the dashboard. Under the tab BackgroundJobServers, you will see the host name of each server. This is also configurable and can be controlled via Spring Boot / Micronaut / Quarkus properties
  • Spring Boot 3 AOT support: As of JobRunr 6, we generate new artifacts for spring, one for projects on Spring Boot 3 and one for projects still on Spring Boot 2:

The jobrunr-spring-boot-3-starter will automatically participate in the ahead-of-time processing if you’re using a JobRequest.

  • MDC Support during success and failure of a job: when a Job fails or succeeds, this was already automatically logged. But, you now also have access to all your MDC variables when the success or failure message is logged. Two extra MDC variables have been added: jobrunr.jobId and jobrunr.jobName.
  • Performance improvements:
    • on job enqueue: whenever a Job is created, a notification is sent so the dashboard figures can be updated. As this is quite a heavy database aggregation, sometimes enqueueing jobs could take a little bit longer. This is now done one a different thread making sure that enqueueing jobs goes as fast as possible.
    • MicroMeter integration: if you were using JobRunr with a framework like Spring, Micronaut or Quarkus and have MicroMeter on the classpath, it would automatically enable metrics for the enqueued / failed / succeeded jobs on each BackgroundJobServer. As it uses the same heave database aggregation as above, this is now opt-in (or done on the server that hosts the dashboard as it is needed anyway) only, instead of enabled by default on each BackgroundJobServer. You can still opt-in manually using properties.
    • for MongoDB: we did some performance improvements related to slow queries in MongoDB
  • Stability improvement: as most of you know, JobRunr stops processing after 5 severe exceptions (e.g. when your database goes down, … ). This also happened when for some reason there was a ConcurrentJobModificationException. JobRunr is now smarter and after a successful run of the JobZooKeeper, the counter will now also go down. The main purpose for this counter is still to detect database outages (if JobRunr would not stop when a database outage happens, it would flood your logs immediately) and stop processing.

New features in JobRunr Pro

JobRunr Pro - the improved dashboard helps your team save even more time:

  • Recurring Jobs tab: The recurring jobs view has improved … a lot! You can now search for Recurring Jobs by name, label, nextRun, … . This comes in handy when you have a lot of recurring jobs.
  • Jobs tab: The jobs views has also seen some love and you can now also search for jobs by id and by recurring job id. This allows you to have an instant overview of all the different job instances for a certain recurring job.
  • Other improvements: you will now also see the server tags in the Background Job Server tab
  • Custom Authentication Provider: you can now plugin your own Authentication Provider allowing to plug in custom authentication
  • Queues improvements: a queue name should be an enum and this is now possible! When creating a job for a certain queue, you can now just pass an enum! To setup your queues, you can now also use the following property: org.jobrunr.queues.from-enum=your.package.QueueName where you pass the fully qualified class name to your enum containing the different queues.
  • Real-time enqueueing: JobRunr Pro will by default do real-time enqueueing - e.g. if you schedule a Job each night at 8pm, it will now also be enqueued exactly at 8pm (unless you have more than 1000 jobs to enqueue at that time as otherwise it may have a huge performance impact).

JobRunr Pro Enterprise - unlimited Recurring jobs and Dashboard Security for our most demanding customers:

  • Secured dashboard: the JobRunr dashboard now supports OpenId Connect (only OpenId Connect. OAuth2 and SAML is in the works). The OpenId authentication plugin has been tested with Google, Okta, Keycloak and Spring Authorization Server. And it gets even better: if somebody manually intervenes (delete, requeue, …) with a job using the dashboard, this is now audited!
  • Embedded dashboard in Spring: JobRunr can now be embedded completely inside your existing Spring container (Micronaut & Quarkus are planned for 6.1). This means that you can also add custom authentication & security using Spring Security.
  • Unlimited Recurring Jobs: not only the Recurring Jobs Dashboard has improved a lot, you can now also create an (almost) unlimited amount of Recurring Jobs. JobRunr Pro Platinum makes a difference between recurring jobs that run every minute or less (these are kept in memory) and recurring jobs that run less frequently than once per minute (which are requested from the database). This allows to have almost an unlimited amount of Recurring Jobs. We have personally tested with up to 15.000 Recurring Jobs that run on a certain timestamp.


  • DST issue: JobRunr had an issue related to saving timestamps to the DB - which we discussed in our blog post. This has now been solved and JobRunr 6 will automatically update all your scheduled jobs on initial start. This means that if you have a lot of scheduled jobs, JobRunr will need some time to update all your scheduled jobs.
  • Jobs deleted via Dashboard are not automatically permanently deleted: Jobs that were deleted via the dashboard would not get deleted permanently automatically. This has been solved now.

Breaking changes

  • If you are using the jobrunr-spring-boot-starter artifact, this has now been renamed to either jobrunr-spring-boot-2-starter and jobrunr-spring-boot-3-starter. Please choose the correct artifact depending on your Spring Boot version.
  • This release fixes the DST issue which is relevant for all SQL databases. JobRunr will automatically migrate all existing scheduled jobs to fix this issue which may take long (depending on the amount of scheduled jobs). If you are using the StorageProvider API to search for scheduled jobs, you may get different results after this release (shifted with the timezone you are in).
  • MicroMeter integration: before JobRunr 6 each BackgroundJobServer would automatically report statistics about the amount of ENQUEUED / SUCCEEDED / FAILED jobs to MicroMeter. As each BackgroundJobServer would report the same metrics and these metrics uses quite a have database aggregation, this now has changed to an opt-in setting.
  • The DisplayName filter has been removed and has now been replaced by the DefaultJobFilter.