Schedule n8n workflows externally via webhook

n8n is one of the most powerful open-source automation platforms out there. Its built-in Schedule Trigger node works for the 80% case: a workflow that should run every X minutes, hours or days. But once you need any of these, it starts to show its limits:

• Running a workflow on a precise cron expression (not just a fixed interval).
• Triggering the same workflow from outside n8n (say from your own app, Airtable, or a customer action).
• Running workflows on a self-hosted n8n instance that sleeps when idle.
• Keeping per-schedule timezones straight across a global team.

In this guide we'll wire up an n8n workflow to start on a Webhook trigger instead, and let Crontap drive the cadence from outside. You get full cron syntax, timezone control, retries, and log history, all without running another scheduler service yourself.

Why not just use the Schedule Trigger?

n8n's Schedule Trigger is great, but it has some sharp edges:

• Cron mode is awkward on the UI. The simplified mode hides cron syntax; the expression mode hides the upcoming-runs preview.
• It's tied to your n8n instance. If n8n is down or sleeping, the schedule doesn't fire.
• It can't be triggered manually from outside. You can't easily say "run this now" from an external tool or script.
• Retries on failure are DIY. You build them into the workflow instead of getting them from the scheduler.

Driving workflows from a Webhook trigger flips this. The workflow becomes a plain HTTP endpoint. Anything that can make an HTTP request can start it: a cron service, a form, a CRM, a cloud function, or another workflow.

The shape of the setup

Crontap (cron)  →  HTTP POST  →  n8n Webhook node  →  rest of the workflow

Crontap handles the when. n8n handles the what. The webhook URL is the contract between them. Here's how to wire it up.

Step 1: Create a Webhook-triggered workflow in n8n

Open your n8n instance (self-hosted or n8n.cloud) and create a new workflow.

1. Click the + and add a Webhook node as the trigger.

2. Set HTTP Method to POST.

3. Set Path to something descriptive, like crontap-sync or weekly-report.

4. Under Response, pick Immediately. You want the webhook to return a 200 as soon as the workflow starts, so Crontap doesn't time out waiting for a long-running workflow.

5. Save the workflow and click Execute workflow once (or toggle Active on). n8n will show you the production URL, something like:

   https://your-n8n.example.com/webhook/crontap-sync
   

6. Copy that URL. We'll hand it to Crontap in a moment.

If you care about security (and you should, since this endpoint is public), add one of these:

• Authentication → Header Auth, with a custom header like X-Crontap-Token and a long random secret.
• Or Basic Auth, if you prefer.

Step 2: Build the rest of your workflow

Add whatever your workflow actually needs to do after the trigger. A few common patterns:

• Fetch rows from Airtable, transform, write to Postgres.
• Pull data from a CRM, summarize with an LLM, post to Slack.
• Download a report, upload to S3, notify the team.

For this example we'll just add a Set node that logs the current timestamp, enough to prove the schedule is firing.

Your full workflow should end with something that returns success (or writes to a log you can check later). n8n's execution history is good for the first few runs, but you'll also want Crontap's logs for longer-term visibility.

Step 3: Create a Crontap schedule pointed at the webhook

Head to Crontap and create a new schedule.

1. In the URL field, paste the n8n webhook URL you copied.
2. Set the Method to POST.
3. If you added Header Auth on the n8n side, add the same header in Crontap's Headers section:
   • Name: X-Crontap-Token
   • Value: the secret you generated
4. Optionally, add a JSON Body payload. Anything you put here lands in the n8n workflow as $json on the trigger node, useful for telling the workflow which tenant/account to process, or for passing run metadata.

Here's a payload you can start with:

{
  "source": "crontap",
  "reason": "scheduled run",
  "runId": "{{runId}}"
}

Note: Crontap doesn't template {{runId}} in payloads today; that's just an illustrative placeholder. If you need per-run data, generate it on the n8n side using $now and $execution.id.

Step 4: Pick a schedule

This is the part that makes Crontap worth it for n8n. You can:

• Use human-readable input: "every 15 minutes", "every weekday at 09:30", "every 2 hours".
• Or switch to cron syntax for full control:

*/5 * * * *        # every 5 minutes
0 */2 * * *        # every 2 hours on the hour
30 9 * * 1-5       # weekdays at 09:30
0 0 1 * *          # first of every month at midnight

As you type, Crontap shows the next upcoming runs so you don't have to guess. If you're new to cron syntax, our cron cheat sheet has the common patterns you'll reach for.

Set the Timezone per schedule. This is the field that n8n's Schedule Trigger makes annoying to handle; with Crontap, each schedule has its own.

Step 5: Test it

Before you hit save, press Perform test in Crontap. It'll fire a real request at your n8n webhook immediately. You should see:

• A 200 response in Crontap (because the Webhook node is set to respond immediately).
• A new execution in your n8n Executions tab.

If the n8n side returned 4xx or 5xx, check:

• Is the workflow set to Active? The production URL only works when active.
• Does your auth header match on both sides?
• Is the method POST (not GET)?

Step 6: Add failure notifications

Open the Integrations panel on the Crontap schedule and wire up a failure alert:

• Slack via Incoming Webhook.
• Discord via channel webhook.
• Email if you prefer async.
• A custom webhook to your own app for anything fancier.

Crontap ships the failure payload with status code, response body and duration, so a Slack alert is immediately useful; you can usually debug from the message without opening the dashboard.

If you want to know when a run succeeded (e.g. "weekly report sent OK"), toggle Call on success too. For high-frequency schedules, leave it off so you don't drown in pings.

What you get vs the Schedule Trigger

Compared to n8n's built-in Schedule Trigger, this setup gives you:

• A real, queryable history of every run with status and duration.
• Retries and failure alerts without adding nodes to the workflow.
• Per-schedule timezones that actually work.
• The ability to manually trigger the workflow from anywhere that can POST (scripts, other workflows, even your browser with curl).
• Independence from your n8n instance's uptime; if n8n is briefly down, Crontap retries.

You lose the ability to configure scheduling from inside the n8n UI. If your team lives in n8n and that matters, keep the Schedule Trigger. For most teams, having scheduling, logging and alerting in one separate place is a net win.

Optional: mix and match

You don't have to pick one. A pattern we see often:

• Use the Schedule Trigger for workflows that are purely internal and don't need precise cron or monitoring.
• Use Webhook + Crontap for workflows that are customer-facing, need precise timing, need retries, or need to be triggerable from outside.

That way you get the simplicity of the built-in trigger where it shines, and the robustness of an external scheduler where you need it.

Wrapping up

We covered:

• Why n8n's Schedule Trigger falls short for some scheduling needs.
• How to build a Webhook-triggered n8n workflow.
• How to drive it from Crontap with cron syntax, timezones, retries and failure alerts.

If you want to go deeper on the cron expressions themselves, our cron syntax cheat sheet has every pattern you're likely to need. And if you're building recurring AI jobs, data syncs, reports or scheduled notifications on top of this setup, the use cases index has a page dedicated to each.