Why Your Cron Job Runs at the Wrong Time (Even When the Expression Is Correct)

You write a cron expression, deploy your application, and expect a task to run at 9 AM.

But it runs at 6 PM.

The expression is valid. The scheduler is working.

So what went wrong?

Often, the problem isn't the cron syntax. It's the assumptions around it.

Here are three common scheduling mistakes.

1. A cron expression doesn't specify a timezone

Consider this expression:

0 9 * * *

In a traditional five-field cron format, this means:

Run every day at 09:00.

But 09:00 in which timezone?

That depends on the environment and scheduler configuration.

If your server interprets the schedule in UTC, the task runs at 09:00 UTC.

For users in South Korea, that's 18:00 KST.

The cron expression itself isn't wrong. It just doesn't contain the timezone information you expected.

1. Every 15 minutes doesn't mean 15 minutes after deployment

Consider:

*/15 * * * *

This means the job runs at minute 0, 15, 30, and 45 of each hour.

If you deploy at 10:07, it doesn't wait until 10:22.

The next scheduled execution is 10:15.

This difference matters when developers confuse fixed schedules with interval timers.

Cron describes matching clock times, not elapsed time since an application started.

1. Daylight saving time can change the result

Imagine a daily task scheduled for 02:30 in a timezone that observes daylight saving time.

On the spring transition, that local time may not exist.

During the autumn transition, some local times occur twice.

Different schedulers handle these situations differently.

Depending on the implementation and configuration, a job can be skipped, repeated, or adjusted.

For time-sensitive operations, never assume that every local day contains exactly 24 hours.

How to avoid surprises

Before deploying a cron schedule:

Confirm whether your scheduler uses UTC, server-local time, or a configured timezone.

Check the next several execution times.

Verify whether your scheduler uses five-field or six-field expressions.

Document your intended timezone alongside the schedule.

Test daylight saving transitions if the job operates in affected regions.

For example, this JavaScript snippet shows how to display a UTC timestamp in Seoul time:

const date = new Date("2026-10-23T09:00:00Z");

const formatted = new Intl.DateTimeFormat("en-GB", {
timeZone: "Asia/Seoul",
dateStyle: "medium",
timeStyle: "short"
}).format(date);

console.log(formatted);

It displays 18:00 in Seoul.

When debugging a scheduled task, always separate two questions:

What does the cron expression mean?

Which timezone does the scheduler use to interpret it?

Both need to be correct.

Preview your cron schedule

I built a browser-based Cron Generator as part of DevRivet to help create expressions, understand their meaning, and preview upcoming execution times.

https://devrivettools.com/cron-generator

It's a convenient way to check expressions before using them in your application. Always verify the actual scheduler's timezone and cron dialect before deployment.

What's the most confusing cron scheduling issue you've encountered?