How to Schedule Cron Jobs in a Specific Timezone (e.g., 7AM UK Time) — A Complete Guide
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! 🕰️
Comments ()