All nodes/Data/Diagnostics
Log
Writes a message to the execution log at the given level (debug / info / warning / error). Supports Jinja templates ({{inputs.input}}, {{variables.x}}). Passes the input value through unchanged, so the node can be inserted mid-pipeline.
Type in the graph: log
Exec
An error branch can be enabled (expose_error_output) to handle failures on their own path.
Ports can be split into separate execution and data handles.
Try it
Minimal working workflow
- Execute + Data
Runs as pasted
When to use it
The node writes a line into the run’s journal and passes the value through unchanged. You place it where it is unclear what actually flows along an edge: before a branch, after parsing an external service’s response, inside a loop. Because the value passes through, the node can be inserted into an existing chain without changing its logic.
A journal entry is not a reply to the user: what reaches the chat is decided by Exit.
How it works
The “Message” field is a Jinja template. It defaults to {{ inputs.input }}, so the incoming
value is what gets journaled; you can also compose your own line with references such as
{{ nodes.<id>.output }} or {{ variables.<name> }}.
The level (debug, info, warning, error) affects nothing but filtering: the log panel toggles levels with buttons and also filters by node, by text and by time since the start of the run. You can read the journal on the “Logs” tab of a run and in the run panel inside the editor — entries appear as the workflow executes.
Up to 10 000 entries are kept per run: past that the node adds one warning line and drops the
rest. An over-long message is truncated with a …[truncated] marker.
Common mistakes
- A cleared field writes an empty line. The step still runs and the journal gets a blank
entry. Put
{{ inputs.input }}back if you want the value. - Secrets land in the journal as plain text.
{{ secret.… }}in the message is stored in the database and shown to everyone who can see runs. - The journal does not live forever. Logs are removed together with the rest of a run’s detail once your plan’s retention policy kicks in; run metadata is kept.
- Something has to trigger the node. It does not observe the graph from the side: only what arrives on its “Input” port is written.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Inputinput | Execute + Dataexecute_data | — | Run trigger and value forwarded to the output handle |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Output (same as Input)output | Execute + Dataexecute_data | — |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Levellevel | string | info | Severity of this log entry. Options: |
Messagemessage | string | {{ inputs.input }} | Message body. Supports Jinja templates: {{inputs.input}}, {{variables.x}}, {{nodes.some_node.output}}. Defaults to the incoming value; clearing the field writes an empty journal line. supports templates |
Shared fields
Every node has these three — the platform adds them, not the node author.
expose_error_output— When enabled, show an execution output to connect nodes that run if this step fails.split_ports_in— Show separate execution and data input handles instead of one combined port.split_ports_out— Show separate execution and data output handles instead of one combined port.