How to Schedule Cron Jobs in a Specific Timezone (e.g., 7AM UK Time) — A Complete Guide

How to Schedule Cron Jobs in a Specific Timezone (e.g., 7AM UK Time) — A Complete Guide
Photo by Swag Photography / Unsplash

When working with scheduled tasks in Linux using cron jobs, the default behavior is to follow the system timezone. However, when your application or team operates in multiple timezones — or you simply want to schedule tasks based on UK local time (such as 7 AM London time) — things can become tricky, especially with Daylight Saving Time (DST) involved.

In this article, we’ll walk through how to reliably run a cron job every day at 7:00 AM UK time, and cover best practices, common mistakes, and logging techniques to make your cron tasks more manageable and observable.


✅ The Basics of Cron

A standard cron entry looks like this:

* * * * * /path/to/command

This means:

  • minute hour day-of-month month day-of-week
  • command: the command you want to run

So for a daily task at 7 AM, you’d write:

0 7 * * * /path/to/your-script.sh

But this executes at 7 AM based on the server’s timezone, which may not be UK time.


🌍 Using Timezones in Cron with CRON_TZ

The CRON_TZ environment variable allows you to run a specific cron job in a specific timezone, even if the server’s timezone is different.

To run a script at 7:00 AM UK time:

CRON_TZ=Europe/London
0 7 * * * /path/to/your-script.sh
✅ Note: This syntax is supported in Vixie cron, the default in most modern Linux distributions like Ubuntu, Debian, and CentOS.

🧠 Why This Matters (Especially for UK Time)

The UK observes Daylight Saving Time (DST):

  • GMT (UTC+0) in winter
  • BST (UTC+1) in summer

Using CRON_TZ=Europe/London ensures your job runs at 7:00 AM local time, automatically adjusting for DST. Without this, you would have to manually change the schedule or work in UTC.


⚠️ Important Notes & Gotchas

1. CRON_TZ Only Affects That Line

Each line in crontab is treated independently. If you want multiple jobs to follow the same timezone, each must be prefixed:

CRON_TZ=Europe/London
0 7 * * * /path/to/first-script.sh

CRON_TZ=Europe/London
30 7 * * * /path/to/second-script.sh

There is no way to set CRON_TZ globally within a user’s crontab -e file.


2. Log Your Output

By default, cron jobs do not show any output. If your script echoes text or encounters an error, it will vanish into the void unless you redirect it:

CRON_TZ=Europe/London
0 7 * * * /path/to/your-script.sh >> /var/log/my-script.log 2>&1

This will:

  • Append standard output and errors to /var/log/my-script.log
  • Help you debug issues or verify that the script ran

3. Use Absolute Paths

Cron jobs do not run in your usual environment. Always use full paths for everything:

✅ Good:

/usr/bin/php /home/user/myapp/script.php

❌ Bad:

php script.php

To discover the correct path, use:

which php
which node
which bash

4. Check if Cron is Running

Your job won’t execute if the cron service is not active.

On RHEL/CentOS:

sudo systemctl status crond

On Ubuntu/Debian:

sudo systemctl status cron

Ensure it's enabled and running, especially after a reboot.


5. How to Verify Your Job Ran

Here are a few ways to confirm execution:

  • Check your log file (if you redirected output).

Add a timestamp:

echo "Job ran at $(date)" >> /var/log/my-script.log

Include a logger command inside your script:

logger "My 7AM UK cron job ran"

This will write to /var/log/syslog or /var/log/messages.


🧪 Test Before Going Live

Want to be sure everything works before committing to a long-term schedule?

Set your job to run a few minutes from now for testing:

CRON_TZ=Europe/London
15 14 * * * /path/to/your-script.sh >> /tmp/test.log 2>&1

If it works, you can change it back to:

CRON_TZ=Europe/London
0 7 * * * /path/to/your-script.sh

🛡️ Best Practices Recap

  • Use CRON_TZ to schedule timezone-specific jobs reliably
  • Log everything — especially during development and testing
  • Use absolute paths to avoid environment-related failures
  • Confirm cron is running on the server
  • Test on a short interval before setting long-term schedules
  • Monitor for failures using logs or external alerting

🧭 Final Thoughts

Handling timezones in cron jobs doesn’t have to be a pain — as long as you use CRON_TZ correctly and stick to logging and verification practices. This is especially important for time-sensitive workflows like sending scheduled emails, generating reports, or triggering time-based jobs for users in specific regions like the UK.

With the right setup, your cron job will run daily at exactly 7:00 AM local UK time, regardless of whether the UK is on GMT or BST — and without needing manual intervention when clocks change.

Stay sharp, and happy scheduling! 🕰️

Support Us