JobRunr is an open-source job-scheduling library for the Java platform that lets developers enqueue, delay or run recurring background tasks across one or many JVMs while persisting state in a relational or NoSQL data store.

First released in April 2020 by Belgian developer Ronald Dehuysser, the project has become a popular alternative to Quartz Scheduler and Spring Batch for cloud-native workloads owing to its lightweight API, zero-XML configuration and embedded dashboard.^[1] Dehuysser unveiled the initial public version of JobRunr on GitHub during the early COVID-19 lockdowns, positioning it as "Hangfire for Java." The library compiled cleanly on the JDK 17 early-access builds by July 2021, signalling an emphasis on forward compatibility and participation in Oracle's Quality Outreach programme.^[2]

Version 4.0 (September 2021) marked the first major milestone. InfoQ reported that the release added a job-analysis performance mode, static-method lambda support and optional byte-code caching, together with first-class starters for Spring Boot, Quarkus and Micronaut.^[3]

Six months later, JobRunr 5.0 shipped with default-retry configuration, cron extensions supporting "last-day" semantics and an officially supported Spring Native starter. The update also introduced Duration-based recurrent scheduling and optional MDC propagation in the dashboard logs.^[4]

JobRunr 6.0 (February 2023) focused on developer ergonomics: a fluent JobBuilder API, arbitrary job labels, an opt-in Micrometer metrics bridge and performance tweaks that halved enqueue latency under load test.^[1]

With JobRunr 7.0 (May 2024) the project embraced JDK 21's virtual threads, automatically switching the worker pool when the host JVM supports it, and replaced random UUIDs with time-based UUIDs to reduce database-index fragmentation. The release also moved the @Recurring annotation into the core module and introduced an InMemoryStorageProvider for rapid CI pipelines.^[5]

JobRunr targets common background-processing tasks, sending email batches, PDF generation, ETL pipelines or asynchronous REST callbacks, without requiring a separate service bus. Jobs are expressed as ordinary Java 8 lambdas or method references; at run time the library inspects the byte-code with ASM, serialises the invocation metadata to JSON and stores it via a pluggable StorageProvider (RDBMS, MongoDB, Redis, Elasticsearch or in-memory).^[6]

Key functional highlights include:

• Unified API: three one-liners (enqueue, schedule, scheduleRecurrently) and a more expressive fluent builder added in v 6.0 for complex triggers.^[1]
• Distributed execution: optimistic locking ensures exactly-once semantics even when multiple BackgroundJobServer instances poll the same table or collection.^[1]
• Dashboard: a self-contained Servlet that surfaces live job graphs, retries and server-health metrics and, since v 5.x, MDC variables for trace propagation.^[4]
• Framework integrations: Spring Boot starter (native-image aware), Quarkus extension, Micronaut bean, Jakarta EE CDI wiring and a thin JUnit 5 test harness.^[4]
• Observability: optional Micrometer timers and counters for succeeded, failed and enqueued jobs; structured logs; and SQL-level telemetry.^[1]
• Performance options: virtual threads (v 7.0 +), time-based UUIDs, cached job analyses, batched SQL and configurable thread counts per server.^[5]

Internally, JobRunr follows a storage-centric architecture. During scheduling the library captures the target lambda or method, its arguments and metadata; serialises this envelope as JSON and inserts it into a job table (or equivalent collection); commits using optimistic locking so that exactly one caller wins in a cluster.^[1] Worker nodes, BackgroundJobServers, poll the storage at a configurable interval (200 ms in fast in-memory mode; 5–15 s in production). When a server claims a job it deserialises the payload, resolves any Spring or Micronaut beans, executes user code in a worker thread, virtual or platform, and then updates the job state atomically. Failed executions are automatically re-queued with exponential back-off up to a default of ten retries (tunable or overridable per job).^[4]

Because the storage layer is abstracted behind StorageProvider, JobRunr can run on traditional RDBMS systems such as PostgreSQL, MariaDB and Oracle and on NoSQL engines like MongoDB. Each provider supplies SQL or driver-specific concurrency primitives; for example, v 7.0 introduced SELECT … FOR UPDATE SKIP LOCKED for PostgreSQL and MySQL to minimise lock contention.^[5]

The dashboard and REST endpoints are packaged so that they do not require a separate service; they share the same transaction scope as job execution, guaranteeing eventually consistent metrics. A commercial "JobRunr Pro" edition layers priority queues, batch chaining and forthcoming carbon-aware scheduling on top of the open-source core.^[7]

• Official website
• jobrunr on GitHub