Scheduling n8n workflows from outside n8n
The n8n Schedule Trigger is capable and lives inside your n8n instance — so it fires only while that instance is up, in whatever timezone the instance thinks it is in. Both of those catch people out.
What n8n gives you
n8n Schedule Trigger. A trigger node with intervals from seconds to months, plus custom cron. The workflow must be saved and published for it to fire.
- Intervals
- Seconds, minutes, hours, days, weeks, months, custom cron
- Timezone (self-hosted)
- Defaults to America/New_York
- Timezone (Cloud)
- Detected, falling back to GMT
- Requirement
- The workflow must be saved and published
Checked against n8n docs on 18 August 2026. These change — if a deploy disagrees with this page, believe the deploy and tell us.
When this is the right answer
Most people reading this should keep what they have. It is worth being specific about when:
- Your instance runs continuously and you have set the timezone deliberately. The Schedule Trigger is the simplest thing that works and there is no reason to add anything.
- You are on n8n Cloud, where keeping the instance up is somebody else’s job.
Where it runs out
Self-hosted defaults to America/New_York
Not UTC, and not your machine’s timezone. A workflow set to run at 09:00 on a fresh self-hosted instance runs at 09:00 New York time until someone changes GENERIC_TIMEZONE — which is a quiet several-hour error.
A scheduler inside a process cannot fire when the process is down
A container that restarts, a host that sleeps, a deploy that takes a few minutes — the schedule pauses with it, and no missed run is reported.
Forgetting to publish means nothing runs
A saved but unpublished workflow does not fire, and looks exactly like one that does until you check.
Scheduling it from outside
Swap the Schedule Trigger for a Webhook node and call it from outside. The rest of the workflow is untouched, and the schedule now lives somewhere that is not the thing being scheduled.
The webhook URL, with header auth on the node
POST https://your-n8n-host/webhook/daily-sync
X-Cron-Secret: <the value configured on the Webhook node>The gain is that a failure is now visible: if n8n is down, the call fails, and you are told. With the Schedule Trigger, an instance that is down produces no run and no error — just nothing.
What getNodi adds
getNodi calls a URL on a schedule and tells you what happened. Any schedule down to your plan’s floor, in your timezone rather than UTC, with retries, a record of every run — status, latency, response — and an alert the first time one fails. Credentials are encrypted at rest and requests can be HMAC-signed so your endpoint can verify they came from us.
The free plan runs 3 jobs hourly and needs no card, which is enough to find out whether this works for you. What it will not do is run a container, hold a connection open for an hour, or execute your code — it makes HTTP requests, and everything above is a way of making that enough.