10. Executions and Monitoring¶

Building an automation is easier than noticing that it quietly stopped. This page is about that part.

Dashboard — the overall picture¶

The first screen you see after signing in.

Metric	Meaning
Total Workflows	How many workflows you have built
Total Executions	How many times they have run in total
Success Rate	The success rate
Active Executions	How many executions are running right now

Recent Executions below shows the latest runs. If the success rate suddenly drops, start here.

Reading the execution history¶

Workflow detail → the bottom of the Overview tab holds that workflow's execution history.

Click a single execution and you can see, per node:

Each node's status (succeeded / failed / retrying)
The input that node received
The output that node produced
The error message, if it failed

90% of debugging ends right here. Look at the output of the node just before the one that failed and you will usually see immediately whether the expression path was wrong or the value was empty.

Reading the statuses¶

The execution as a whole

Status	Meaning
`RUNNING`	In progress
`COMPLETED`	Succeeded all the way through
`FAILED`	Failed partway
`CANCELLED`	Cancelled

Each individual node

Status	Meaning
`PENDING`	Waiting its turn
`RUNNING`	Running
`COMPLETED`	Succeeded
`FAILED`	Failed
`RETRYING`	Retrying
`CANCELLED`	Cleaned up because the execution ended in failure

CANCELLED is not a problem with that node itself. It means the node was still running when another node failed and ended the execution, so it got cleaned up. The real cause is in the FAILED node.

Retries and timeouts¶

External APIs fail sometimes. There are two mechanisms so that a temporary failure does not stop the whole automation.

- id: fetch-orders
  name: Fetch orders
  type: CALL
  integration: http_request
  timeout: 10s
  retry-policy:
    max-attempts: 3
    backoff:
      type: EXPONENTIAL
      initial-delay: 500ms
      multiplier: 2.0
      max-delay: 10s
    retry-on: ["429", "5xx"]
  input:
    ...

`timeout` — how long to wait¶

timeout: 10s

Past this duration the node counts as failed. The formats you can use are 500ms · 10s · 5m (a number plus ms/s/m).

Kind of node	Recommended
Fast API lookups	`5s` – `10s`
Heavy lookups and report APIs	`30s` – `1m`
AI calls (`llm_chat`)	`30s` – `2m`

If you set no timeout, the execution can hang for a long time waiting on an API that never answers. It is worth setting one on every external call.

`retry-policy` — how many times to try again¶

Field	Required	Description
`max-attempts`	✅	Maximum attempts (including the first one). `3` means 1 initial attempt + 2 retries
`backoff.type`	✅	`FIXED` (the same gap every time) or `EXPONENTIAL` (progressively longer)
`backoff.initial-delay`	✅	How long to wait before the first retry
`backoff.multiplier`		The factor when using `EXPONENTIAL`. Defaults to `2.0`
`backoff.max-delay`		An upper bound on the wait
`retry-on`		Which HTTP statuses to retry on. Leave it empty for every retryable failure

The values retry-on accepts are exact codes ("429", "503") or ranges ("5xx", "4xx"). Any other string causes the save to be rejected.

retry-on: ["429", "5xx"]     # ✅ only rate limiting and server errors
retry-on: ["503"]            # ✅ only a specific code
retry-on: ["TIMEOUT"]        # ❌ no such name exists

With EXPONENTIAL, initial-delay: 500ms and multiplier: 2.0, the waits grow 500ms → 1s → 2s → 4s.

When not to retry¶

Do not put retries on anything that must not send the same request twice.

Node	Retry
Reads (GET)	✅ Safe
Data transforms	✅ Safe
Sending a message	⚠️ It may go out twice
Payments and order creation	❌ Dangerous

For message sending, it is safer to narrow it to clear delivery failures, like retry-on: ["429", "5xx"].

Set up failure alerts — please do this¶

If an automation that runs every day quietly stops, nobody finds out. This is the feature that prevents it.

Go to Notifications in the sidebar to configure it.

Field	Description
Webhook URL	Where failure alerts go. It has to start with `http://` or `https://`
Enable notifications	Turn this off and nothing is sent even on failure

When a workflow execution ends in failure, one POST goes to this address.

Creating a Slack incoming webhook¶

Create an app, or open an existing one, at api.slack.com/apps.
Turn on Incoming Webhooks.
Use Add New Webhook to Workspace to pick the channel that receives alerts.
Paste the resulting https://hooks.slack.com/services/... address into the Notifications screen.

Discord works the same way — channel settings → Integrations → Webhooks.

If a URL is already configured, the screen shows it masked. Saving with the field left blank keeps the existing URL and only toggles it on or off.

This is a different feature from sending to Slack inside a workflow. What you configure here is a system alert saying "the automation failed"; a slack_post_message node is a business message sent because the automation worked.

Editing a workflow while executions are running¶

When an execution starts, the shape of the workflow at that moment is saved, and that execution follows that shape to the end.

If you edit a workflow while a long execution is in flight, the execution already running is unaffected.
Your edits apply from the next execution onward.
When you edit a workflow over MCP, the edit is rejected if an execution is in progress. Wait for it to finish, or cancel it, and try again.

Pre-flight checklist¶

Worth running through once whenever you turn on a new automation.

[ ] Did you set a timeout on the external call nodes?
[ ] Did you set a retry-policy on the read nodes?
[ ] Did you avoid putting unnecessary retries on sending and payment nodes?
[ ] Did you configure the failure alert webhook under Notifications?
[ ] Did you set an explicit timezone on the schedule trigger?
[ ] Did you pass API keys via ${secrets.*} instead of writing them into YAML?
[ ] Did you attach | raw everywhere you pass an array?
[ ] Did you actually run it once and check the result in the execution history?

Next → 11. Turning It into an AI Assistant (MCP)