Spring Boot Scheduler

Work through this checklist:

1. @EnableScheduling is missing. Without it, @Scheduled is silently ignored.
2. The class is not a Spring bean. It needs @Component, @Service or similar, and must be inside a scanned package.
3. The method takes parameters. Scheduled methods must have none.
4. A condition switched it off, such as @Profile or @ConditionalOnProperty on the class or configuration.
5. The schedule is further away than you think, for example a cron for 09:00 in another time zone.

GET /actuator/scheduledtasks quickly shows whether Spring registered the job.

Spring Boot’s scheduler uses one thread by default. While one job runs, every other job that is due must wait for it to finish.

Give the scheduler more threads:

spring.task.scheduling.pool.size=5

Check the thread names in your logs. If every job shows scheduling-1, they are all sharing a single thread.

Not by default. Spring never starts a job again while its previous run is still going, even with fixedRate and a larger thread pool. A late run simply starts as soon as the previous one ends.

Overlap only happens if you also mark the method @Async, which hands each run to a separate executor:

@Async
@Scheduled(fixedRate = 1, timeUnit = TimeUnit.MINUTES)
public void pollSensors() {
    // runs may now overlap if one takes longer than a minute
}

Only do this when the job is safe to run in parallel with itself.

@Scheduled is for repeated work. For a one-time task at startup, use an ApplicationRunner, or listen for the ApplicationReadyEvent:

@Component
public class StartupTasks {

    @EventListener(ApplicationReadyEvent.class)
    public void loadReferenceData() {
        // runs once, after the application is fully started
    }
}

ApplicationReadyEvent fires after the application is completely ready, which makes it a safe moment to call other services.

Without a zone, Spring uses the server’s time zone. Cloud servers and containers often run in UTC, so 0 0 9 * * * means 09:00 UTC, which is 14:30 in India.

Always state the zone you mean:

@Scheduled(cron = "0 0 9 * * *", zone = "Asia/Kolkata")

Use region names like Asia/Kolkata or Europe/London instead of fixed offsets like +05:30, so daylight saving time is handled correctly in regions that use it.

In regions with daylight saving time, clocks jump forward one night and back another. A job scheduled inside that hour may be skipped on the spring-forward night or seem to happen at an unexpected moment on the fall-back night.

Simple ways to stay safe:

• Avoid scheduling important jobs between about 01:00 and 03:00 local time in such regions.
• Or run the job in zone = "UTC", which has no daylight saving changes.
• Make jobs safe to repeat, so an extra run does no harm.

Regions without daylight saving, such as India, are not affected.

• * means every value of the field.
• ? means no specific value, and only applies to the day-of-month and day-of-week fields.

Use ? to show that one day field is not relevant because the other one decides the day:

0 0 9 ? * MON     every Monday at 09:00 (day of month does not matter)
0 0 9 15 * ?      the 15th of every month at 09:00 (weekday does not matter)

In Spring, 0 0 9 * * MON works the same way, so ? is mostly about readability and compatibility with other tools such as Quartz.

Spring cron supports special characters for these cases:

L handles months of different lengths and leap years automatically.

If the cron expression comes from a property, set it to a single dash. Spring treats "-" as “disabled”:

jobs.daily-report.cron=-

For fixedRate or fixedDelay jobs, put @ConditionalOnProperty on the job class so the bean is only created when enabled:

@Component
@ConditionalOnProperty(name = "jobs.exchange-rates.enabled", havingValue = "true")
public class ExchangeRateJob { ... }

A simple approach is a switch that the job checks before doing any work:

@Component
public class NewsletterJob {

    private final AtomicBoolean paused = new AtomicBoolean(false);

    @Scheduled(cron = "0 0 10 * * MON", zone = "Asia/Kolkata")
    public void send() {
        if (paused.get()) {
            return; // skip this run
        }
        // send the newsletter
    }

    public void pause()  { paused.set(true); }
    public void resume() { paused.set(false); }
}

Expose pause() and resume() through a secured admin endpoint. With several instances, store the flag in a database or shared cache so every server sees the same value.

Set lockAtMostFor clearly longer than the job’s normal duration. If it is too short, the lock can expire while the job is still running and a second server may start it.

Start with @Scheduled. Move to Quartz when you need many jobs that users create and edit, or must not miss a run while the application is down. Spring Boot has a spring-boot-starter-quartz starter for this.

A scheduled job decides when work runs. Spring Batch helps with how to process large amounts of data reliably. Consider Spring Batch when a job:

• Processes thousands or millions of records, such as importing a large file.
• Must restart from where it stopped after a failure, instead of starting over.
• Needs a record of every run: start time, end time, records read, written and skipped.

The two work together: a @Scheduled method can launch a Spring Batch job at the right time.

Put @Transactional on the service method the job calls, not on the scheduled method itself. The job class stays a thin trigger, and the service controls its own database work.

Keep transactions short. One giant transaction around a job that updates 100,000 rows holds database locks for a long time and is fully rolled back if the last row fails. Process the work in smaller batches, each in its own transaction:

@Scheduled(cron = "0 0 2 * * *", zone = "Asia/Kolkata")
public void archiveOldOrders() {
    int archived;
    do {
        archived = orderArchiveService.archiveNextBatch(500); // @Transactional, 500 rows
    } while (archived > 0);
}

The run is simply missed. @Scheduled keeps no history, so after a restart it waits for the next scheduled time and does not catch up.

If a missed run matters, for example a daily billing job, design for it:

• Save the time of the last successful run in the database, and at startup check whether a run was missed.
• Make the job process everything not yet done, such as all unbilled orders, instead of “today’s orders”. Then the next run catches up automatically.
• Or use Quartz, which has built-in rules for missed runs.

Yes. On Java 21 with Spring Boot 3.2 or later, enable virtual threads:

spring.threads.virtual.enabled=true

Spring Boot then runs each scheduled job on its own virtual thread, so jobs no longer wait for a free thread and spring.task.scheduling.pool.size no longer applies. Each job still does not overlap with itself.

This suits jobs that mostly wait on databases or remote calls. Keep an eye on what they call: many jobs starting at once can still overload a database.

@Scheduled has no built-in time limit. Protect your jobs with timeouts at each slow step, and a time budget for the job as a whole:

@Scheduled(fixedDelay = 10, timeUnit = TimeUnit.MINUTES)
public void syncProducts() {
    Instant deadline = Instant.now().plus(Duration.ofMinutes(8));

    for (Long id : productService.idsToSync()) {
        if (Instant.now().isAfter(deadline)) {
            log.warn("Sync stopped at time budget; the rest continues next run");
            return;
        }
        productService.syncOne(id); // uses an HTTP client with its own timeouts
    }
}

Also set connection and read timeouts on HTTP clients and query timeouts on the database, so a single slow call cannot block the job forever.

• Visibility: make it public. This is the safe choice on every Spring version, and it is required when you combine the method with proxy-based features such as @Async or @Transactional.
• Return values: anything returned is ignored, because nobody receives it. Use void.
• Parameters: not allowed. Startup fails if a scheduled method has any.
• Static methods: not supported. The method must belong to a bean instance.

Since Spring Framework 6.1 (Spring Boot 3.2), scheduled methods are measured automatically when Actuator and Micrometer are present. Each job records a timer named tasks.scheduled.execution, tagged with the class and method:

GET /actuator/metrics/tasks.scheduled.execution

The timer shows how many times the job ran, its total and maximum duration, and whether runs succeeded or failed. Export it to a monitoring system such as Prometheus, and add an alert when a job is slower than usual or has not succeeded for a while.

Usually not. A common anti-pattern is a job that checks a table every few seconds for new work, such as “emails to send”. It adds a delay, keeps querying the database even when there is nothing to do, and needs locking when several instances run.

Better options for work started by a user action:

• @Async to run the work in the background right away.
• A message broker such as Kafka or RabbitMQ when the work must not be lost.
• Application events with @TransactionalEventListener to react after a save.

Keep @Scheduled for work that is truly driven by time.