The Log Node
The Log node is how you make a step you built yourself — an HTTP/service call, an internal computation — visible and accountable to the platform. Anywhere you do work that isn't an Agent node, a Log node records it. And it does more than record: it's also one of the two points where the run's cost and time limits are enforced.
What it records
You place a Log node after a step and tell it about that step:
- node name — a label for the step;
- worker type — either
service(an external service call) orinternal(a computation). Notagent— agents log themselves, so that type isn't offered here; - worker slug — for a service, the service's slug (used to look up its pricing); for internal, a descriptive slug;
- status —
successorerror; - optionally: duration, consumption (
input_size/output_size), an error message, and the request/response payloads to store.
For a service call, the consumption is the important part: report input_size/output_size in the service's declared unit (the unit/per_unit from the service snapshot), and the platform computes the dollar cost from the service registry. For an internal step there's no billable consumption — it's logged for the timeline, at zero cost. Each log entry also carries an auto-generated idempotency key, so a retried log call can't create a duplicate row or double-count cost (you never see or set this key).
It enforces limits too
Just like the Agent node, the Log node reads the platform's response to its log call — the run's running tally and the abort flag. If the run has breached its cost or time limit, abort is true, and the Log node terminates the run and stops. So every Log node you place is also a checkpoint against the guardrails; between Agent and Log nodes, a well-instrumented workflow checks its budget at every meaningful step. (The abort flag itself is covered in Handling the Abort Flag.)
When the log call fails
If the call to the platform itself fails, the Log node follows your n8n On Error / Retry On Fail settings — the same pattern as the Agent node. With Stop-Workflow and retry on, it lets n8n retry; with retry off, or with a Continue setting, it terminates the run, so a failed log (which would blind the threshold checks) doesn't leave the run limping along uncounted. The safe default is Stop Workflow, optionally with Retry On Fail for transient blips.