Fix n8n schedule trigger timezone issues

If your workflows are firing at the wrong hour, the most common cause is a timezone mismatch between the host, container and the Schedule Trigger node. This n8n schedule trigger timezone guide shows how to check host time, container env vars, the node timezone, and fix n8n.cloud, Docker, desktop and self hosted installs so schedules run at the expected local time.

Why this happens

n8n evaluates cron and scheduled triggers using the server process time. That time can come from the host operating system, the container environment, or the Schedule Trigger node's explicit timezone setting. If any layer is set to UTC while you expect Africa/Lagos, your 9 AM job will run at UTC 9 AM. Many Docker containers run in UTC by default, and n8n.cloud infrastructure also uses UTC, so the node or environment needs to be aligned.

Step-by-step fix

1. Confirm the expected time and timezone you want, for example Africa/Lagos.
2. Check the Schedule Trigger node first. Open the node, find the timezone or timezone selector and set it to your zone. If you enter a Cron expression, also set the timezone there. This is the simplest fix for single workflow problems.
3. Check the process time inside n8n. Run a quick workflow or use a node that returns the server date, for example a Schedule Trigger linked to an HTTP Request to a logging endpoint, or a Set node with an expression {{$now.toISOString()}}. Compare that to your local clock.
4. Verify host and container times. On the host run timedatectl or date -R. For Docker run docker exec -it <container> date -R or docker-compose exec n8n date -R. For Kubernetes use kubectl exec -n <ns> <pod> -- date -R.
5. If the container is wrong, set the TZ environment or map time files. For Docker Compose add TZ=Africa/Lagos under environment, or bind-mount /etc/timezone and /etc/localtime into the container. Then restart the container.
6. For n8n.cloud, set the timezone in the Schedule Trigger node for each workflow or use timezone-aware cron expressions. Note that n8n.cloud infrastructure runs on UTC, so node-level timezone selection is required for local times.
7. Re-test using a simple workflow that logs {{$now}} on the scheduled run to confirm times are correct.

n8n schedule trigger timezone: tool specific notes

Different deployments require different actions. Use the checklist below based on your host.

n8n.cloud

• n8n.cloud infrastructure typically runs in UTC. The fastest fix is to open each workflow's Schedule Trigger node and set the timezone field to your local zone (for example Africa/Lagos).
• If you have many workflows, include an explicit timezone in the Cron field or a metadata tag so you can find and update them fast. See the community thread where someone fixed 9 AM running at 1 AM for the same reason: My 9 AM workflow fired at 1 AM.

Docker and Docker Compose

• Containers default to UTC unless configured. Edit your docker-compose.yml and under the n8n service add:

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - TZ=Africa/Lagos
    volumes:
      - ~/.n8n:/root/.n8n

• Alternatively, bind mount /etc/localtime and /etc/timezone from the host into the container to match host timezone.
• Restart the container with docker-compose up -d and verify with docker exec -it <container> date -R.

Self hosted on Linux or VM

• Set the server timezone with sudo timedatectl set-timezone Africa/Lagos. Confirm with timedatectl.
• Restart the n8n service or process so Node.js picks up the change.

Desktop

• n8n desktop uses your OS timezone. Confirm your machine clock and timezone settings in Windows or macOS and restart the desktop app if needed.

Reusable test workflow and remediation script

Create this quick test workflow to confirm behavior before and after fixes. In n8n build:

• A Schedule Trigger node with Mode set to Cron and expression */1 * * * * and timezone set to the zone you want to test.
• A Set node that stores serverTime with value {{$now.toISOString()}}.
• An HTTP Request or logging endpoint that receives the payload for your central log, or just view executions in n8n.

// Cron expression example when testing one minute runs
Cron: */1 * * * *
Timezone: Africa/Lagos

Remediation script example to show container time and suggest fixes:

#!/bin/bash
CONTAINER_NAME=n8n
echo "Host time: $(date -R)"
docker exec -it $CONTAINER_NAME date -R || echo "Container not running or docker missing"

echo "If container shows UTC, add TZ=Africa/Lagos to your docker-compose and restart with:"
echo "  docker-compose down && docker-compose up -d"

echo "On a Linux host, set system timezone with: sudo timedatectl set-timezone Africa/Lagos"

This script does not edit files for you. It collects evidence and gives the precise commands to run based on your setup.

How to stop it happening again

• Standardize on one source of truth for time. For teams in Nigeria, choose Africa/Lagos as the canonical timezone and document it.
• Add a checklist item to workflow delivery: always set the Schedule Trigger timezone or include a timezone comment in the workflow description.
• For Docker images add TZ to the environment in a central Compose file or Helm values so new deployments inherit the correct timezone.
• Use the small test workflow above in your CI or deployment smoke tests to verify schedule behavior after updates.
• If you run n8n.cloud, treat timezone as a per-workflow setting because infrastructure is UTC.

When to get help

If you have confirmed host, container and node timezone settings are aligned but a workflow still runs at the wrong time, gather execution logs and reach out. Post evidence showing host time, container time (date -R), the Schedule Trigger node screenshot and the Cron expression. The n8n community thread above helped others diagnose a 9 AM versus 1 AM problem, and if you see database connection or other errors after changes, that may be separate and need different troubleshooting.

If you want a walkthrough for your specific deployment, Automate Naija helps builders and freelancers in Nigeria set these up and verify schedules are correct. Learn to build automations like this with Automate Naija.

Frequently asked questions

Why did my 9 AM n8n workflow run at 1 AM?

Most likely your server or container was on UTC while you expected Africa/Lagos. The Schedule Trigger node uses the process time unless you set a timezone in the node. Check the node timezone, then check host and container clocks with date -R or timedatectl .

How do I check the timezone inside my Docker n8n container?

Run docker exec -it container date -R to see the container clock. Also run docker exec -it container printenv TZ to see if a TZ env var is set. If it shows UTC, add TZ=Africa/Lagos to your docker-compose environment and restart.

Does n8n.cloud use my local timezone?

n8n.cloud infrastructure runs on UTC, so you must set the timezone in each workflow's Schedule Trigger node if you want local times. For many workflows set the timezone in the node to avoid surprises.

What is the quickest fix for many wrong-time schedules?

Open each affected workflow and set the Schedule Trigger node timezone explicitly to your desired zone. For a long term fix standardize the TZ env in your deployment or bind host time files into containers so new workflows inherit the correct time.

Build it with us. The community is free and the build track teaches this kind of automation week by week: see pricing or join the community.