Automation
Automate: schedules & webhook triggers
A workflow you have to click is a demo. Automation is what makes it a system, and there are two ways to start one without you: on a clock, or on an event. Both live on the Schedules page.
I built this scheduler and later found it had been running two-week-old code on my own production server, so the failure modes at the bottom of this page are not hypothetical ones I thought up for a help article.
Which one you want
| Schedule | Webhook trigger | |
|---|---|---|
| Starts when | A cron time you set | Something POSTs to your URL |
| Input to the run | Fixed, set once | The JSON body of the request |
| Good for | Digests, sweeps, nightly reports | Reacting to a form, a ticket, a payment |
| Fails quietly when | The condition inside never matches | The caller stops calling |
Schedules
- Open the Schedules page and pick the workflow.
- Add a cron schedule — for example every day at 9am.
- Save. It now runs on its own, and every run appears in Executions like any other.
Cron is as fine-grained as you need, but be realistic about volume: a five-minute schedule is about 288 runs a day, and each one costs tokens. A support-ticket-sized worked example comes to $0.0144 at our real rates, so 288 of those is roughly $4 a day of usage. Start daily and tighten it once you have seen what a run actually costs you.
Webhook triggers
- On the Schedules page, add a Webhook trigger to the workflow.
- Copy the generated URL — it contains an unguessable token, so treat it like a password.
- Have the external system POST JSON to it. The body becomes the workflow’s input and the run starts immediately.
- Check Executions to confirm the first real call arrived with the shape you expected.
Anyone holding that URL can start your workflow, which is the point and also the risk. If it leaks, delete the trigger and add a new one — the old token stops working.
The limits worth knowing before you rely on it
| Limit | Value | What happens at it |
|---|---|---|
| Workflow run time | about 61 minutes | The run is stopped |
| Stuck-run reaper | 90 minutes | A run still not finished is marked TIMEOUT, so nothing stays “running” forever |
http_request calls | 1,000 per user per day | Further calls are refused |
send_email | 100 per user per day | Further sends are refused |
How an automation fails without telling you
It runs and does nothing
This is the common one and it does not look like an error. A scheduled workflow whose condition never matches will finish as COMPLETED every single time while doing no work. Source: I shipped exactly this and wrote it up — a cleanup job of mine ran hourly for weeks, logged “removed 0 expired results”, returned success, and had never deleted anything.
The check that catches it is a count, not a status: have the run report how many items it processed, and compare that against what the source says it handed over.
Nothing runs at all
Workflows and agents are inactive by default, so nothing fires by accident. Open it and set it to Active. If a schedule exists and is Active and still nothing appears in Executions, the schedule is attached to a different workflow than the one you are looking at.
It ran before you were ready
A schedule starts at its next matching time, not when you finish editing. Add the schedule last, after the workflow does what you want by hand.
Next
- Give the workflow real tools so the scheduled run can act — see Give agents tools & integrations.
- Read what a failed or empty run is telling you — see How to troubleshoot a failed run.