Schedule node is not triggering workflows on set intervals.
Closed this issue · 9 comments
Bug Description
I have just updated to version (initially)1.56.2 from 1.55.3, and now on version 1.57.0 but the issue is persistent. when trying to use the schedule node, at first you struggle to save the workflow it keeps giving the error Workflow could not be activated: There was a problem activating the workflow: “ERROR: You specified an invalid ``date.”
but after some retries, it may save and you expect it to run on scheduled times but I got 2 executions before it completely stopped triggering and nothing. I has been like that now crippling our workflows.
To Reproduce
version: "3"
services:
pgsql:
image: "postgis/postgis:15-3.3-alpine"
environment:
- POSTGRES_DB=n8n
- POSTGRES_USER=postgres
- POSTGRES_HOST_AUTH_METHOD=md5
- POSTGRES_PASSWORD=<redacted>
expose:
- 5432
networks:
- proxy
volumes:
- /mnt/postgresql:/var/lib/postgresql/data
healthcheck:
test: ['CMD-SHELL', 'pg_isready -h localhost -U postgres -d n8n']
interval: 5s
timeout: 5s
retries: 10
n8n:
container_name: "n8n"
restart: always
image: n8nio/n8n:1.56.2
environment:
- WEBHOOK_URL=<redacted>
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=pgsql
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=postgres
- DB_POSTGRESDB_PASSWORD=<redacted>
- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=336
- NODE_OPTIONS=--max_old_space_size=8000
- NODE_TLS_REJECT_UNAUTHORIZED=0
- N8N_LOG_LEVEL=verbose
- GENERIC_TIMEZONE="Africa/Johannesburg"
expose:
- 5678
volumes:
- /mnt/n8n:/home/node/.n8n
networks:
- proxy
- services
depends_on:
- pgsql
- redis
redis:
image: redis
container_name: redis
restart: always
networks:
- proxy
networks:
proxy:
external: true
services:
external: true
Expected behavior
The schedule node is supposed to run on set intervals. But it is not doing that anymore. This means that now we have to trigger workflows manually and it defeats the purpose and a lot of work.
Operating System
Linux Ubuntu
n8n Version
1.57.0
Node.js Version
<20
Database
PostgreSQL
Execution mode
main (default)
Hey @onlypfachi,
We have created an internal ticket to look into this which we will be tracking as "GHC-200"
Can you please share a sample workflow where you are able to reproduce this?
This sounds like an edge-case, and without being able to reproduce this, it'll be difficult for us to fix it.
{"meta":{"instanceId":"ddef87a6d7a34dda27e46f04adecc8f25b6a5469c909474f5e21381a1d371970"},"nodes":[{"parameters":{"rule":{"interval":[{"field":"minutes","minutesInterval":10}]}},"id":"3b2d3c85-d2ad-46ac-acdd-ff35c9303565","name":"Schedule Trigger","type":"n8n-nodes-base.scheduleTrigger","typeVersion":1.2,"position":[1360,560]}],"connections":{},"pinData":{}}
even a single node like this in a workflow on its own still does the same behaviour
Go to the workflow settings and check the default timezone. What does it show?
If it shows this Default - Default Timezone not valid
:
Then the problem is with the Docker environment. The last update made something to force using the default timezone only.
My problem with it got fixed after changing the default timezone "In Coolify/Docker", not in the settings of workflows:
considering that the original post mentions GENERIC_TIMEZONE="Africa/Johannesburg"
, I don't know if the timezone being invalid is the issue here.
considering that the original post mentions
GENERIC_TIMEZONE="Africa/Johannesburg"
, I don't know if the timezone being invalid is the issue here.
He should check the workflow settings by observing the default value it outputs. If it outputs Africa/Johannesburg
, then it's not the same case as mine. If it gives Default - Default Timezone not valid
, then he has to check it. For my Coolify config Docker Compose
, it requires this format with double quotes:
- "GENERIC_TIMEZONE='Europe/Istanbul'"
@onlypfachi Can you please try changing the line - GENERIC_TIMEZONE="Africa/Johannesburg"
to - GENERIC_TIMEZONE=Africa/Johannesburg
(remove the quotes)
Hey @ARHAEEM,
This looks to be unrelated and it is something we are aware of and it is currently intentional. The max value for minutes is 59 as we take that value and create a cron syntax for it.
Instead you may be better off using Hours and setting it to 3. For the initial issue reported here it should be solved by setting the timezone correctly.