Start automations automatically

Use the Trigger section on the automation’s General tab when work should start on a schedule or in response to an event. Every trigger starts the deployed version in live mode. Before enabling one, test the workflow with the input shape it will receive and check that its external actions are ready.

Choose how the automation starts

An automation has one configured trigger at a time. Changing its type replaces the previous binding. Replacing a webhook revokes its URL immediately; configuring another webhook later does not recover that credential.

An API or MCP client can also start work without a configured trigger. Its API key and project permissions authorize the request, and it sends the workflow’s input directly. See the API reference.

Set a schedule

1. 1

   Open the trigger settings

   Open the automation, then its General tab. Without a binding, the Trigger section says that the automation runs only when started by hand or through the API; choose Add trigger, then Schedule under Trigger type. A new trigger starts with Enabled off — keep it off while preparing a workflow that should not start yet.

2. 2

   Enter the timing

   Fill Cron and choose Timezone. A cron expression has five fields: minute, hour, day of month, month and day of week. Use an IANA timezone such as Europe/Zurich when local business hours matter; an unspecified timezone means UTC.

3. 3

   Check and save

   Review the next occurrence shown for a valid expression, then click Save beside the tabs. Confirm that the workflow’s deployed version accepts the schedule input above. When ready, turn on Enabled and save again. Check the next started run under Runs.

*/15 * * * *     every fifteen minutes
0 9 * * 1-5      09:00 on weekdays
0 6 1 * *        06:00 on the first of the month
30 8 1 * 1       08:30 on the 1st and on every Monday

Fields support *, numbers, ranges, steps and comma-separated lists. Both 0 and 7 mean Sunday. If both day-of-month and weekday are restricted, either match is enough; the last example runs on Mondays as well as the first day of each month.

Local time follows the timezone’s daylight-saving rules. A 09:00 Zurich schedule stays at 09:00 locally. Timing has one-minute resolution. Missed occurrences during an outage are not replayed; work resumes at the next occurrence. Impossible calendar dates are rejected when saving.

Receive a webhook

Choose Webhook, then save to generate the credential. Copy the full URL when it appears: the token is shown once and only its hash is stored. The section supplies an organization URL and a project URL pattern. Use the project URL for an active project in which the automation is installed; an automation with project bindings cannot run through the organization-only URL.

Post a small payload to the URL. JSON becomes payload inside the input wrapper, not the workflow’s top-level input. Other request bodies pass through as text. The limit is 256 KiB; upload large documents separately. An accepted request returns a run ID without waiting for completion.

For example, a posted { "invoiceId": "inv-1" } reaches the workflow as:

{
  "trigger": "webhook",
  "payload": { "invoiceId": "inv-1" }
}

Use a delivery ID, such as Idempotency-Key or the sender’s supported delivery header. Repeating that ID within 24 hours returns the original run. Without an ID, an identical body on the same URL within two minutes is treated as a duplicate. Send distinct IDs if identical payloads represent separate work. Webhooks lists supported headers, project routes, errors and response formats.

React to a platform event

Choose Platform event, select Event name, then save and enable when ready. Match the workflow’s schema to the trigger, event and payload wrapper in the table. Events raised by automation runs do not fire triggers, preventing a workflow from repeatedly starting itself through its own changes.

A workflow expecting required top-level fields such as owner and repo cannot accept schedule metadata or a wrapped webhook unchanged. Adapt its input schema and references, or use an API-started run that supplies those fields. The trigger settings do not provide arbitrary saved input fields.

Diagnose a missing start

First check Enabled, the deployed version and the last-fired information. Then inspect any recorded skip reason:

The last-fired timestamp advances when a run actually starts. A due trigger that cannot start work records a skip instead. This separates a broken schedule from a workflow that started and later failed.

When a schedule pauses itself

A schedule whose runs fail the same way at every occurrence would otherwise keep failing indefinitely. Tale counts the runs a trigger starts that fail with an error a retry won't fix: the automation's own code (node_error), a connector (connector_error), a model reply that does not match its schema (llm_output_invalid), or the organization's model provider (auth_error, missing_api_key, credit_exhausted, model_not_found). A successful run resets the count, and other failures, such as a rate limit or an unreachable provider, neither count nor reset it. A schedule that has already paused itself is the exception: it keeps the count that paused it, even when a run that was still in progress succeeds afterwards, and only saving the trigger clears it.

After five such failures in a row, the schedule turns Enabled off and records paused_after_failures. The Trigger section then shows the pause, the last failure's code and time, and View run, which opens that run. While runs are failing but the schedule is still on, the section shows how many failed in a row. Owners and Admins get a bell notification, which also reaches them by email when the organization has a connected mailbox, and the audit log records the pause. They can switch these notices off with Automation alerts under Settings > Notifications.

Open the failed run to read the error, and fix the automation or its connection. Then turn on Enabled and save. Saving the trigger starts a new count, whether it turns the schedule back on or leaves it off, and marks the notices read.

Webhook and platform-event triggers count failures the same way but are never paused. Their runs carry a delivery or an event, which a paused trigger would drop.

Pause or replace the trigger

Turn off Enabled and save to pause starts while retaining the configuration and run history. Re-enable it to resume. Remove trigger deletes the binding; for a webhook, its URL becomes unusable.

Triggers belong to the automation’s name, not a version. Deploying or rolling back keeps the same schedule or URL and changes which version future starts execute. Editing a trigger does not create a workflow version, so review trigger settings alongside any deployment that changes expected inputs.