Triggers: time, event, API
An automation starts at a time of day, on an event or at the call of another system. Which trigger fits what, how to read a cron expression – and why events are the riskiest variant.
Boaz LichtensteinFacts checked on 10 November 2026
So far your automation has run by the clock. That is the simplest of three triggers – and not always the fitting one. Know all three and you choose deliberately instead of running everything hourly.
The three triggers
Schedule is the right default. It is predictable, easy to check and uses a known amount.
Event pays off when waiting costs something: a support request should be pre-sorted within minutes, not the next morning.
API call – often called a webhook – is the route for developers: your store system reports “new return” to an address, and the agent starts there.
Cron in a minute
Schedules are expressed in the same notation almost everywhere. Five fields separated by spaces:
┌ minute (0–59)
│ ┌ hour (0–23)
│ │ ┌ day of month (1–31)
│ │ │ ┌ month (1–12)
│ │ │ │ ┌ weekday (0–7, 0 and 7 = Sunday)
│ │ │ │ │
30 7 * * 1-5 Monday to Friday at 7:30
0 9 * * 1 every Monday at 9:00
0 */2 * * * every two hours on the hour
0 8 1 * * on the first of every month at 8:00
An asterisk means “every”. Two traps:
- Time zone. Many platforms calculate in UTC. “7:30” is then 8:30 in Germany in winter and 9:30 in summer. Check the setting before you start wondering.
- Minimum interval. For scheduled tasks in ChatGPT and for cloud tasks in Claude Code, one hour is the shortest cadence. Claude Code rejects tighter expressions.
What the platforms offer
ChatGPT has, besides schedules, event-triggered tasks for connected apps such as Gmail, Slack and GitHub. They are not available on the Free and Go plans and are capped at 30 runs per hour and 720 per day – across all your event tasks together. Scheduled tasks in ChatGPT
Claude Code offers all three triggers for tasks in the cloud, also combined: schedule, GitHub events and a dedicated endpoint per task that another system calls via HTTP POST. According to the documentation the feature is a research preview. There are also scheduled tasks in the desktop app – they run on your machine and only while the app is open. Scheduled tasks in Claude Code
Why events are riskier
A schedule starts with your brief. An event starts with third-party content: a stranger’s email, the text of a ticket. Three problems follow that a schedule does not have.
Foreign instructions. The content that triggers the run can contain instructions. An agent that reacts to incoming email reads every email anyone sends.
Loops. If the agent reacts to new comments and writes one itself, it may trigger itself again.
Floods. A hundred events in an hour are a hundred runs. Platforms set caps; with Claude Code, according to the documentation, whatever exceeds them is dropped, not caught up later.
The answer is not to do without events but to allow them less than a schedule: read only, pre-sort only, drafts only. You know the columns for that from Approvals and limits.
The endpoint is a key
An API trigger consists of an address and a token. Whoever has both can start the agent. Treat the token like a password: it belongs in the secrets store of the calling system, not in a note, an email or a repository.
The rule of thumb
Start with the schedule. Switch to the event only when you can name what waiting costs. And use the API call when a system you control yourself is to trigger the start.