Scheduled tasks

Scheduled tasks in the sidebar manages execution plans separately from the workflow canvas. Select a task on the left; the detail area shows its trigger, next and previous runs, bound workflow and recent history.

Create a task#

Choose New task, enter a name, select a workflow and choose a manual, scheduled or webhook trigger. Daily (pick time) uses a time picker with an hour column and a minute column; picking the minute closes it, and the arrow keys move within a column. The time is in your computer's time zone (the detail area says which zone a task's schedule uses; tasks created earlier run on UTC, and their owner can switch them to the local zone in one click). Manual tasks do not run on a schedule.

Once you pick a workflow, the dialog lists its start inputs: scheduled runs use what you fill in here, and the workflow's defaults for blanks. Inputs marked * with no default are required — the task can't be created without them. Anything other nodes need (picking a file or a connection) has to be filled in on the workflow canvas first. After creation, the Workflow inputs row in the detail area shows what was filled in, and the owner can Edit inputs.

Clicking the bound workflow row in the detail area opens that task's workflow, not whichever workflow the Workflows page last had open.

Run and disable#

Run a task immediately or toggle its enabled state in the detail area. Only the task's owner can change, enable or disable, delete, reset the trigger secret of, or run it now: a task runs as its owner, on the owner's keys and quota, and sharing it into the workspace lets teammates see it and how it's doing — not manage it. On someone else's task these controls are greyed out, and hovering explains why. Disabling prevents future automatic triggers; inspect history for work already running. Records show time, duration and result. Read failures and fix the workflow before retrying. The run history refreshes on its own: runs started outside this page — a webhook, a scheduled trigger — appear too, and the Last run field updates with them, without reloading the page.

Every trigger first goes through the same pre-run check as Run in the workflow editor: required parameters, chat model, clone engine, digital-human consent, referenced nodes that no longer exist… If it can't run, nothing starts and nothing is spent; the run record states why and a notification says "Scheduled task didn't start" with the task's name — nobody is watching when a schedule fires, so a quiet failed record isn't enough.

Who a run acts as#

Scheduled triggers, webhook triggers and Run now all run as the task's owner (whoever created it): their model keys, their usage, and only the publishing accounts and browser profiles they may use — their own or those shared into the workspace. If the graph references an account or profile someone hasn't shared, that run fails saying it "belongs to someone else and hasn't been shared"; ask its owner to share it, or switch to one the task owner owns.

The version being run counts too. Teammates can edit workflows: when the owner's task runs a version someone else changed, whoever changed it must also be able to use the private accounts, browser profiles or files on this computer it needs — otherwise the run stops and says this version was changed by someone else. Once the owner has reviewed the change, Approve this version on that run's row lets the next run go through. Approving doesn't change the graph or add a version, and it only counts for things the approver can use. On a single-user install the author and the owner are the same person, so this never comes up.

AI and plugin connections work the same way. They spend the owner's keys and quota: if a version someone else changed uses chat, generation, voice or translation nodes, or plugin nodes, it only spends once the owner approves it. Until then a due run stops before it starts, spending nothing; the task stays enabled and the run's row offers Approve this version. Workflows that use no connection at all (only templates, conditions, editing, local rendering) aren't affected.

• Clicking Run now counts as approval. The owner is right there: the click approves the current version, so this run and later scheduled ones go ahead. Run in the workflow editor and approving an agent's "run workflow" card yourself work the same way. Only due, webhook-triggered and auto-approved agent runs actually wait for approval. It approves this workflow's current version only — a called sub-workflow someone else changed and you haven't approved still stops and asks you to approve that one.
• Needs your approval. When someone changes a workflow your task uses (or a sub-workflow it calls), you get a notification; the task shows Needs your approval in the list, and its details say which workflow and version, with Approve this version right there. Teammates see Waiting for its owner — their approval doesn't count, since it isn't their money. Whoever edited the workflow also sees a note at the top of the editor that the task resumes once you approve.

Scheduling runs on the connected backend. In local mode it runs with the app, so fully quitting stops scheduled execution. With a remote backend, that server must stay running. Closing a window and quitting the application are different actions. See Workflows for triggers and variables.

When the bound workflow is deleted#

Deleting a workflow disables the scheduled tasks bound to it on the spot, so they stop firing on schedule. The tasks and their run history are kept; deleting them is your decision. Such a task's toggle cannot be switched on and Run now is unavailable (hovering explains why), and webhook triggers are refused — instead of leaving a run that fails after 0 seconds every time. Tasks that were already enabled while bound to a deleted workflow are disabled automatically on upgrade. To keep going, create a new task bound to an existing workflow.

Webhook triggers and follow-up#

A webhook task's detail area shows its Trigger URL. An external system (CI, n8n, a script) POSTs to it to fire one run, without signing in: the secret in the URL is the credential. The same secret also lets it check how that run is going and cancel it, so the caller does not have to trigger and wait blindly.

The secret is shown only once. The backend stores only a hash of it: right after you create a webhook task or reset its secret, the full trigger URL is shown that one time — copy it into the external system then. After you leave the page it is masked; reset it to get a new URL. Webhook tasks created before secrets were stored as hashes had a secret every member of the workspace could see, so their detail area reminds the owner to reset it once — the old URL keeps working until then.

Expand How to call it under the trigger URL for three copyable commands that already carry this task's address (and the secret right after it's generated; afterwards a <secret> placeholder):

# Fire one run; returns run_id
curl -X POST 'http://127.0.0.1:8800/api/hooks/scheduled-tasks/<task_id>?secret=<secret>'
 
# Check that run's status and progress
curl 'http://127.0.0.1:8800/api/hooks/scheduled-tasks/<task_id>/runs/<run_id>?secret=<secret>'
 
# Cancel that run
curl -X POST 'http://127.0.0.1:8800/api/hooks/scheduled-tasks/<task_id>/runs/<run_id>/cancel?secret=<secret>'

The example uses the default local backend address; commands copied from How to call it use the backend you are actually connected to.

• Triggering returns a run_id. If the previous run has not finished, or the bound workflow was deleted, the trigger is refused (HTTP 409) and no run is opened.
• The status call returns status (queued / running / succeeded / failed / cancelled), progress (0–1), and message / error text in the language of the request's Accept-Language header. A cancelled run is reported as cancelled, separate from a failure: one is something you stopped, the other may need an alert or a retry.
• Cancelling works at node granularity: the step currently executing finishes, then the run stops, and any child jobs it spawned are cancelled too.
• A secret reaches only this task's own runs. A run_id belonging to another task is treated as not found.

If the secret leaks (or you've lost it), the owner chooses Reset secret next to the trigger URL. The old URL stops working immediately, and so do status checks and cancels made with the old secret; update the external system to the new URL. A run that is already going is not affected.