Spring Cron Expression Examples for @Scheduled

Spring Boot cron expressions are a practical way to run recurring background tasks with @Scheduled. They look similar to Linux cron, but Spring uses a six-field format that includes seconds, which changes how you write and reason about schedules. This guide walks through real spring cron expression examples, explains spring cron syntax, and shows how to avoid production mistakes when scheduling jobs for APIs, data pipelines, reports, and maintenance workflows.

Spring Cron Format Explained

Spring cron syntax is built around six fields in this order: second, minute, hour, day of month, month, and day of week. A common source of confusion is that Linux cron usually uses five fields and does not include seconds. When developers copy a Linux schedule directly into a Spring Boot annotation, the expression may become invalid or run at a different frequency than expected. Understanding field order is the first step in writing reliable schedules.

Each field supports special operators that make a cron expression flexible. The wildcard * means “every value.” Step values such as */5 mean “every five units” within that field. Ranges like 1-5 represent intervals, and comma-separated lists like 1,3,5 represent specific discrete values. You can combine these operators to model many common recurring tasks without writing custom scheduler logic.

In Spring Boot, cron expressions are most often used with @Scheduled(cron = "...") on methods in managed components. The scheduler evaluates your expression continuously and triggers the method when the current time matches all fields. This makes cron perfect for periodic jobs such as clearing caches, syncing records, rotating tokens, collecting metrics, and sending digest notifications. It also means that small syntax errors can have big operational impact, so teams should always validate schedules in pre-production.

If you are searching for a spring cron syntax guide, remember these practical guardrails: always verify the second field, confirm weekday numbering conventions, and set explicit timezone behavior when your workload depends on local time. For many backend teams, cron is part of core reliability engineering, so building confidence in syntax pays off quickly.

Common Spring Cron Expression Examples

1) Cron expression every 5 minutes spring

Cron: 0 */5 * * * *
Meaning: Run at second 0 of every 5th minute.
@Scheduled(cron = "0 */5 * * * *")

This is one of the most searched spring boot @Scheduled cron example patterns. It is ideal for polling queues, refreshing cached data, and running lightweight health checks.

2) Every 10 minutes

Cron: 0 */10 * * * *
Meaning: Run at second 0 every 10 minutes.
@Scheduled(cron = "0 */10 * * * *")

Use this for jobs that do not require near-real-time frequency, such as periodic cleanup, aggregation, or external API synchronization with moderate SLA needs.

3) Daily at 2 AM

Cron: 0 0 2 * * *
Meaning: Run every day at 02:00:00.
@Scheduled(cron = "0 0 2 * * *")

Nightly batch tasks such as report generation, retention policies, and archive jobs commonly use this schedule. Validate timezone assumptions before production rollout.

4) Every weekday at 9 AM

Cron: 0 0 9 * * MON-FRI
Meaning: Run at 09:00:00 Monday through Friday.
@Scheduled(cron = "0 0 9 * * MON-FRI")

Good for business-hour workflows such as summary notifications, finance sync, or operational reminders that should avoid weekend execution.

5) Every Monday at 8:30 AM

Cron: 0 30 8 * * MON
Meaning: Run at 08:30:00 every Monday.
@Scheduled(cron = "0 30 8 * * MON")

Weekly workflows often use this pattern for report distribution, backlog snapshots, or weekly summary events for teams.

6) First day of month

Cron: 0 0 0 1 * *
Meaning: Run at midnight on day 1 of every month.
@Scheduled(cron = "0 0 0 1 * *")

Monthly billing, ledger checks, quota resets, and financial rollups are typical cases where this expression is valuable.

7) Every 30 seconds

Cron: */30 * * * * *
Meaning: Run every 30 seconds.
@Scheduled(cron = "*/30 * * * * *")

This schedule is useful for short-interval monitoring or lightweight reconciliation, but ensure the underlying job duration is small enough to avoid overlap and resource pressure.

Difference Between Spring and Linux Cron

The most important difference is field count. Linux cron traditionally uses five fields (minute, hour, day-of-month, month, day-of-week), while Spring cron uses six fields by adding a leading seconds value. This difference alone explains many scheduling bugs when teams migrate shell cron jobs into a Spring application.

Another practical difference is execution context. Linux cron runs through the operating system scheduler, while Spring cron runs inside the JVM and depends on application lifecycle. If the app is down, jobs do not run. If multiple instances run the same scheduler in distributed systems, each instance may trigger unless coordination is implemented.

Spring also gives you convenient annotation-based wiring with @Scheduled, making cron behavior part of the codebase and easier to version with pull requests. Linux cron remains strong for host-level automation, but Spring cron is usually better for application-owned background workflows where domain logic and scheduler definitions belong together.

How to Test Spring Cron Expressions

Teams should validate cron expressions before deployment to avoid silent failures or noisy over-triggering. Start by translating business intent into a candidate expression, then check frequency, day constraints, and timezone behavior. Finally, test with realistic job durations and monitoring enabled.

You can validate quickly with the CodeUtils Cron Builder, which provides parsing and readable interpretation to help spot errors early:Open Cron Builder. This workflow is especially useful when reviewing pull requests or troubleshooting production scheduling issues.

Common Spring Cron Mistakes

Forgetting the seconds field and pasting a 5-field Linux schedule directly into @Scheduled.
Assuming server timezone matches business timezone without explicitly configuring scheduling behavior.
Running high-frequency jobs without checking execution duration, causing overlap and thread pool exhaustion.
Using weekday names inconsistently across environments and not validating locale behavior.
Treating cron as fire-and-forget and skipping instrumentation, retries, and failure alerting.
Not considering multi-instance deployment, leading to duplicate execution in horizontally scaled services.