Appearance
Runs and logs
Every automation run happens on the server, off the back of a durable queue. Nothing depends on a browser staying open, and a restart mid-run does not lose work.
How a run executes
Something happens on the board. A row lands in the trigger queue straight away.
A worker claims the row and moves it from pending to running. Claiming is serialized, so a burst of events does not have two workers walking the same graph.
The worker finds every active automation on the board whose trigger matches the event, and runs each one. An automation that is paused, archived, or whose trigger does not match is skipped without cost.
The graph is walked breadth-first from the trigger. Each node runs, and each one's outgoing edges are queued unless the node says otherwise.
When the walk ends, a log row is written with the status, the error if there was one, the path the run took, and how long it took in milliseconds. The automation's run count and last-run time are updated, and the trigger row is deleted.
Up to 100 queued rows are handled per sweep; the rest wait for the next one, a minute later at most.
Branching
- A Condition node sends the run down its True or False edge, never both.
- A Filter node that fails queues nothing, so that branch simply ends.
- A For Each node walks its body edges once per item, then queues its after edges.
- Deleting the focus task stops the run there, since there is nothing left to act on.
A node that fails does not stop the rest of the graph. Other branches keep running, the run is marked as an error, and the log reports the first failure, because that is the one to fix.
Delays
A Delay node does not hold a worker open. It stores the rest of the run and finishes. A sweep picks it back up when the wait is over and continues from exactly where it left off.
If you edit the graph while a delayed run is parked, the resume only picks up nodes that still exist.
Retries and double-writes
If a run cannot be delivered at all, its queue row stays claimed. A sweep releases it back to pending after five minutes and it is tried again, with a backoff between attempts.
Every write-bearing node claims its own slot before it runs. On a retry that slot is already taken, so the node is skipped and the walk carries on: a retried run never posts the comment twice or creates the task twice.
Caps
| Cap | Value | What it protects |
|---|---|---|
| Nodes executed per run | 10000 | A runaway loop or a cycle |
| Items per For Each | 1000 by default, 5000 at most | One loop swallowing the whole budget |
| Write calls per Agent node | 20 | A runaway agent |
| HTTP Request timeout | 10 seconds, at most 3 redirects | A slow or looping endpoint |
Hitting the step budget marks the run as an error and says so, rather than truncating quietly.
The Last run panel
Press Run in the builder and the result lands in a panel at the bottom of the canvas.
| Part | What it shows |
|---|---|
| The dot in the header | Green for a clean run, red when there was an error |
| The error line | The message, when there is one |
| Path | The nodes the run visited, in order |
| A block per Debug node | What that node captured |
A Debug node's snapshot has three parts: the values you pinned, anything a Parse node produced, and the status and body of any HTTP Request. With no Debug node in the graph, the panel says so and invites you to drop one in.
Running from the builder lands any unsaved edits first, because the server runs the saved automation, not the canvas. If the automation is paused, running it switches it on.
Run history
Every run writes a log row: which automation, which board, the trigger event and its data, the path, the status, the error and the duration.
The counts are visible in the app:
- The rail in the Automations view shows a run count and how long ago the last run was, or Never triggered.
- Settings > General > Automations has Runs and Last run columns for every automation in the workspace.
The rows themselves are available over the API, at GET /v1/automations/{id}/logs, and through the automations_get_logs MCP tool. See REST API and MCP.
Deleting an automation deletes its run history with it.
Managing every automation at once
Settings > General > Automations is the workspace-wide list, for owners and admins.
| Control | What it does |
|---|---|
| Search | By automation name or board name |
| Board and State | Filter to one board, or to Active, Disabled or Archived |
| Checkboxes plus Enable, Disable, Archive, Delete | Bulk actions on the selection |
| The header count | How many are active, and the cap when there is one |
Archiving an active automation deactivates it immediately and it stops running. Deleting removes the automations and their run history for good.
Who gets the credit
An automation's writes are attributed to the automation, not to a person. The activity feed and the audit log name the automation against anything it changed, including runs the clock started with no user involved. See Security and audit.
When an automation does not fire
| Symptom | Check |
|---|---|
| Nothing happens at all | The switch. A paused automation never runs, and importing one always leaves it paused. |
| An amber warning circle on the row | Open it: the graph has an error. The switch lists what is wrong. |
| It runs but skips a step | That node is missing required configuration, or its branch condition was false. Add a Debug node before it and run it by hand. |
| It fires on the wrong things | Narrow the trigger. Most triggers take a list, tag, member, field, folder, status or branch filter. |
| It will not switch on | The graph can trigger itself, so it is blocked. Change the trigger or the action that feeds it. |
| The switch fails with a limit message | Your plan's active-automation cap. Pause another one, or see Plans and billing. |
| A scheduled run was late or skipped | A workspace that sleeps between bursts of activity can miss a tick. The Scheduled Trigger panel warns when this applies. |
| An HTTP Request fails | The URL may point at a private address, which is refused unless the workspace opted in. |
| An AI node does nothing | AI has to be available for the workspace, and the Agent node needs a model that can call tools. See AI settings. |
Start with Debug
A Debug node costs nothing, works on every plan, and answers most "why did it do that" questions in one run. Put it right before the node that misbehaves, press Run, and read the snapshot.