Running and monitoring

Once a graph is built, three toolbar controls decide whether and how it runs, and the builder's Activity view is where you watch what actually happened.

Quick overview

1. Click Validate to catch obvious problems first.
2. Click Test to run the graph once immediately, regardless of its trigger.
3. Click Activate to publish it and start listening for its real trigger.
4. Open the Activity view (the icon rail) for run history, step logs, and per-node stats.
5. Click Pause any time to stop new runs without losing the draft.

Detailed reference

Test, Activate, and Pause

Control	Does
Test	Saves your draft, publishes it, and queues one run at the trigger node immediately. Fails with the validation report if the graph is not valid.
Activate	Saves and publishes the draft as a new version, then sets the automation to Active so it starts reacting to its real trigger.
Pause	Sets the automation to Paused. It stops starting new runs but keeps its draft and history intact; Activate resumes it.

Run status

Status	Meaning
Active	Currently in progress, sitting at some node
Completed	Reached an exit node, or ran off the end of the graph
Exited	Stopped by a Filter node whose condition was not met
Failed	Hit an unrecoverable error

Step status

Each node a run passes through leaves one entry in the step log.

Status	Meaning
ok	The step ran (or, for a trigger or logic node, was evaluated) successfully
skipped	The step's condition filtered it out, or its executor is not wired yet, see Nodes
error	The step's action failed, for example a webhook call that did not return a success response

The Activity view

Panel	Shows
Runs	Every run for this automation: its status, the node it is currently on (or its error), and how long ago it started
Recent step logs	The latest node-by-node events across runs, with a short message where relevant
Node stats	Per-node counters: how many times each node was entered, completed, skipped, or failed, across every run

A Refresh button reloads all three. Before an automation has ever run, this view shows a plain empty state instead of blank panels.

Reliability

Runs advance one node at a time in the background, and each node's step is recorded once, even if the background process checking on runs happens to overlap itself. In practice that means an action like sending a webhook will not fire twice for the same step just because the check that advances it ran more than once.

Retries and per-node error handling

An action node can be configured, in its own inspector, to retry itself (0 to 5 times, with a wait between attempts) before falling through to its On error behavior: continue past the failure, stop the whole run, or route to a dedicated error path. The automation's Settings also has a Default on-error behavior used by any action that hasn't set its own. See Building a workflow for exactly where these live.

Node stats in Activity are cumulative across every published version of an automation, not reset each time you activate a change; a spike in one node's failed count can be from an old version's behavior as much as the current one, so cross-check against the Runs panel's timestamps.

Step by step

Walkthrough: test, read the result, then activate

1. Build a graph and click Validate; fix anything it flags before moving on.
2. Click Test. This saves the draft, publishes a new version from it, and immediately queues one run at the trigger node, independent of whatever the real trigger is.
3. Switch to the Activity icon in the rail. On an automation's first-ever run you'll briefly see a plain empty state instead of blank panels; click Refresh if the run doesn't show up right away, since the tick advances runs in the background rather than instantly.
4. Open the run in the Runs panel to see which node it's currently sitting on (or its error), then check Recent step logs for a node-by-node account, including any skipped steps and their message.
5. Once it behaves the way you expect, click Activate. This publishes another version, even if nothing changed since Test, and flips the automation's status to Active so its real trigger takes over from here.

Walkthrough: diagnose a run that isn't advancing

1. Open Activity and find the run; its status and current node tell you exactly where it's sitting.
2. If it's Active but hasn't moved in a while, check whether that node is a Delay or Tarihe kadar bekle (Wait until a date); those are meant to sit there, sometimes for days, and resume on their own.
3. If it's sitting on an action node, check Node stats for that node's failed/skipped counters; a node with a Retry configured will keep re-attempting on its own wait schedule before it ever reaches its On error behavior.
4. If nothing is moving across every automation at once, that's almost always the periodic tick not running at all (see the self-hosted tip below) rather than a problem with this one graph.

Troubleshooting

• A run's status stays Active forever. Either it's genuinely waiting on a Delay, a Wait-until-date, or a retry schedule (check the current node), or the periodic tick that advances runs isn't running at all; see the self-hosted tip below.
• Step logs are empty even though the run clearly did something. Check the automation's Settings for Save execution data: Errors only hides successful steps, and None hides everything, both there to save storage or avoid logging sensitive payloads.
• A run failed with "zaman aşımı" (timeout). Settings has a Max run duration; a run older than that many seconds is auto-failed even mid-delay. Raise it, or leave it unset (off) for automations that are meant to wait a long time.
• The automation paused itself. Settings' Circuit breaker auto-pauses an automation after that many runs fail back to back. Check the failure reason in Activity, fix it, then Activate again once you're confident it's resolved.
• A webhook or a busy event produced more runs than expected. Check Settings' Concurrency; the default, Free, allows unlimited runs of one automation in parallel. Single at a time, Skip if busy, or Queue all cap how many can be in flight together.
• Nothing runs at all on a self-hosted install. This is the most common self-hosted gap: nobody scheduled the periodic job. See the tip below.

Tips

Test first, activate second

Test runs immediately without touching the automation's status, so you can check the result in Activity before flipping it to Active.

Self-hosted deployments

On a self-hosted install, an administrator needs to schedule the periodic job that advances runs and checks due schedules; see Self-Hosting. This is automatic on the managed service.

Related

• Building a workflow
• Triggers
• Versioning and sharing