Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
JobRunr lets a Java application persist work and execute it outside the caller’s thread: submit a job, store its details through a StorageProvider, and have a BackgroundJobServer process it. Use BackgroundJob.enqueue for immediate work, BackgroundJob.schedule for a one-time delay, or recurring scheduling for cron- or interval-based work. For production, configure durable storage, start workers explicitly, and protect the dashboard as a privileged operations interface.
How JobRunr’s parts fit together
JobRunr is a library embedded in your JVM application, not a separate job service that runs without your application. Its main components have distinct responsibilities:
- Job API or scheduler: accepts work from application code.
BackgroundJoboffers convenient static methods;JobSchedulercan be injected directly. StorageProvider: persists job definitions and execution state. Job details are stored as JSON through a supported serializer.BackgroundJobServer: claims and executes stored jobs using worker threads.- Dashboard: provides a web interface for inspecting jobs, failures, recurring definitions, and worker servers.
These components can share one application deployment, or scheduling and web traffic can be separated from worker deployments. Configuring storage and scheduling alone does not start workers: the background server and dashboard are opt-in in the documented setup. Do not start more than one BackgroundJobServer in the same JVM.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Configure storage and submit work
JobRunr’s plain-Java guide demonstrates modern Java 25 syntax, while the library itself is compatible with Java 8 and higher. Adapt the setup and syntax to your framework and Java version; the following is illustrative rather than a complete framework-specific configuration.
// Illustrative: configure a durable StorageProvider for production first.
JobScheduler scheduler = ...;
scheduler.enqueue(() -> reportService.generate(reportId));
scheduler.schedule(Instant.now().plusSeconds(300),
() -> reportService.generate(reportId));
scheduler.scheduleRecurrently("nightly-report", "0 0 2 * * *",
() -> reportService.generateNightly());The static convenience form for immediate work is BackgroundJob.enqueue(() -> service.method(...)); one-time delayed work uses BackgroundJob.schedule(Instant, lambda). Recurring work is registered through the recurring scheduling API with a cron expression or interval. A recurring definition causes individual jobs to be created as its schedule comes due; it is not one long-running job.
Prefer injecting and using JobScheduler directly in application code that needs straightforward testability. Job lambdas and their arguments are serialized, so avoid capturing large or unsuitable object graphs. As a general design practice, pass stable identifiers where practical and reload current business data when the job runs; this keeps persisted job arguments small and avoids relying on stale in-memory state.
Rank #2
Choose the scheduling pattern
| Need | Pattern | Behavior |
|---|---|---|
| Run work as soon as a worker can process it | enqueue |
Creates an immediately eligible background job. |
| Run a single job later | schedule with an Instant |
Creates a one-time delayed job. JobRunr’s scheduling documentation lists a 15-second default poll interval for scheduled jobs; this is a configuration default, not a promise of exact-to-the-second execution. |
| Repeat work over time | Recurring scheduling with a cron expression or interval | Registers a recurring definition that generates jobs as its schedule comes due. |
Use storage that matches recovery needs
InMemoryStorageProvider is useful for trying the API, but it does not preserve jobs across process restarts. For production, choose a supported persistent relational or NoSQL provider, configure its serializer and credentials, and ensure database availability and capacity are appropriate for the workload. JobRunr’s performance is limited by the underlying database, so storage is an operational dependency, not merely setup plumbing.
A durable provider allows persisted work to remain available after an application restart, but it does not make every business action transactional or safe to repeat. Design job effects—such as sending messages, charging accounts, or updating external services—for possible repetition and define how operators should recover when the work or a dependency fails.
Handle retries and failed jobs deliberately
JobRunr’s official introduction says that jobs are retried automatically with exponential backoff up to 10 times by default. Once retries are exhausted, the job is marked FAILED and remains visible for investigation. The retry count can be customized through annotations or JobBuilder; the documentation also describes custom retry filters and policies.
- Use automatic retries for failures that may clear on their own, such as a temporary dependency outage.
- Do not assume retries fix invalid input, a persistent configuration error, or a deterministic bug; repeated attempts can waste capacity or repeat side effects.
- After correcting the cause, decide whether to requeue the failed job or delete it according to the business impact and recovery procedure.
The JobRunr FAQ’s “only process a job once” wording refers to optimistic locking when workers claim a job. That claim mechanism is not a guarantee of exactly-once effects in external systems; application-level idempotency and recovery design remain necessary.
Rank #4
Monitor execution with the dashboard
The dashboard is disabled by default and must be enabled explicitly. In the documented default local setup, it is available at http://localhost:8000. It shows job states and histories, exception details and stack traces, recurring jobs, and worker-server visibility.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- Check the counts of enqueued, processing, and failed jobs to spot a growing backlog or failure increase.
- Open a failed job’s history and stack trace to identify the failing operation and the recorded exception.
- Verify the underlying cause is fixed, then requeue or delete the job only when that action is operationally appropriate.
The dashboard exposes job data and allows destructive actions such as deleting jobs. The deployment guide warns, “Do not deploy an insecure dashboard.” Run it on one instance rather than on every worker, keep it on internal networking or behind an authenticated gateway, and do not expose it publicly. OSS basic authentication is available, but JobRunr’s documentation characterizes it as relatively weak. JobRunr Pro documentation lists advanced dashboard options such as SSO and role-based access control; check current edition details if those controls are requirements.
Best Value
Use metrics for ongoing monitoring
JobRunr’s deployment guide identifies Micrometer metrics as an option for external monitoring. Background-job-server metrics cover per-node CPU, memory, worker-pool size, and heartbeats; job metrics report counts by state. Job metrics are off by default, while server metrics are on by default in the Spring and Micronaut integrations. The documentation does not prescribe alert thresholds: teams can use these signals to define alerts for sustained failures, backlog growth, or unhealthy servers.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Deploy and scale workers safely
A combined deployment is a simple starting topology: the application accepts work, the scheduler creates scheduled jobs, and a background server processes them. The dashboard can be enabled on a single instance if operators need it. When job load or scaling needs justify separation, run worker deployments independently from web-facing application instances while keeping them connected to the same supported storage.
Multiple application instances can join the processing cluster. JobRunr documents a master server that performs recurring scheduling and housekeeping. Adding worker threads or instances is not, by itself, a throughput guarantee: assess job duration, queue behavior, database load, and downstream service limits together. Scale storage and workers in response to observed workload rather than assuming workers are the only constraint.
Official documentation pages consulted for this guide: Introduction, Background Job Scheduling in Java, Deployment, Dashboard, and Scheduling jobs. Their pages returned no publication date; defaults and features may change.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
