@Scheduled — Cron Jobs and Fixed-Rate Tasks in Spring Boot

@Scheduled is Spring's built-in mechanism for recurring tasks — cron jobs, periodic cache refreshes, health pings. The defaults hide a critical limitation: every scheduled task runs on the same single thread.

The single-thread problem

• Spring creates one scheduler thread by default — if a task takes 5 seconds and is scheduled every 3 seconds, subsequent firings queue up behind the running one
• Configure a custom ThreadPoolTaskScheduler with a pool size matching the number of concurrent tasks you expect
• Always set an ErrorHandler — otherwise failures are silently logged to stderr

`fixedRate` vs `fixedDelay`

• fixedRate = 5000 — fires every 5 seconds from the previous start time; if the task takes 6 seconds, the next fires immediately after completion (no overlap by default)
• fixedDelay = 5000 — fires 5 seconds after the previous execution completes; total cycle time = task duration + delay
• fixedRate is for metrics and health checks where timing regularity matters; fixedDelay is for sequential processing where overlap is unsafe

Cron expressions

• Spring uses a 6-field cron: seconds, minutes, hours, day-of-month, month, day-of-week
• @Scheduled(cron = "0 0 8 * * MON-FRI") = 8:00 AM every weekday; note the leading 0 for seconds — Unix cron has no seconds field, a common copy-paste mistake

Clustered deployments

• Every instance runs every task — no built-in coordination
• ShedLock or Quartz clustered scheduler for at-most-once cluster-wide execution

Add @EnableScheduling to a @Configuration class — without it, every @Scheduled annotation is silently ignored. In an interview, the strong answer is: `@EnableScheduling` + thread pool + error handler + `/actuator/scheduledtasks` for verification, with ShedLock for clustered coordination.