Default timezone in n8n workflow
Why relying on system timezone can cause scheduled workflows to run at unexpected times
What is this issue?
When a workflow doesn't specify an explicit timezone, it inherits the server's system timezone. If you migrate to a different server or cloud provider, your scheduled workflows may suddenly run at different times.
Common symptoms:
•Cron jobs running 3-8 hours early or late after server migration•Daily reports generated at midnight UTC instead of local time•Workflows triggered at wrong times after Docker image updates•Inconsistent execution times across development and production
Why is this dangerous?
Unpredictable scheduling
Server migrations or cloud provider changes can silently shift when your workflows execute.
Business process disruption
Scheduled reports, notifications, or data syncs may miss their intended time windows.
Data consistency issues
Daily aggregations or backups may include wrong date ranges when timezone shifts.
Debugging complexity
Timezone-related issues are notoriously hard to diagnose, especially across environments.
How to fix it
- 1
Set explicit timezone in workflow
Go to workflow Settings and select a specific timezone (e.g., 'America/New_York', 'Europe/London').
- 2
Use UTC for server-side operations
For data processing workflows, consider using UTC to avoid daylight saving time issues.
- 3
Document timezone requirements
Add notes to workflows explaining which timezone they should run in and why.
- 4
Configure n8n default timezone
Set GENERIC_TIMEZONE environment variable in n8n to establish a consistent default.
Scan your workflow now
Upload your n8n workflow JSON and instantly detect timezone configuration issues and other reliability problems.