Console Logger

Log messages for debugging

Overview

Logs a message to the console with full execution tracking. The message is written to the execution log and the item continues down the workflow, so you can drop the node anywhere in a chain to inspect what is flowing through it. Each forwarded item carries two markers added to its JSON: logged (always "ok") and processedAt (the epoch-millisecond timestamp of the write).

Category: Core Nodes
Tool Name: console_logger
Version: 1

Appearance: Icon: terminal | Color: #6b7280

Node Type

Action — processes input items and produces output

Input / Output

Direction	Port(s)
Input	`Input`
Output	`Output`, `Error`

Credentials

This tool does not require any credentials.

Parameters

Parameter	Type	Required	Default	Description
Message	`string`	Yes	`Default log message.`	The message to log. Supports expressions like {{ $json.field }}.
Log Level	`options`	No	`log`	The console method to use for logging.
				Options: `log`, `warn`, `error`, `info`, `debug`
Max Concurrency	`number`	No	`100`	Maximum number of items to process concurrently.
Output Empty?	`boolean`	No	`false`	If true, the node will output nothing even if it processed successfully.

Output Data

One output item per input item. The item JSON passes through with two markers added — logged (always "ok") and processedAt (the epoch-millisecond timestamp of the write) — and binary data is forwarded unchanged.

Turning Output Empty? on suppresses the output entirely: the messages are still logged, but the node emits no items, which ends that branch of the workflow.

Usage Examples

log the current item for debugging
print the status at this point
output the response to console
debug the workflow data
show what values are being processed

Example Configuration

Log a message built from the current item:

{
  "type": "console_logger",
  "parameters": {
    "message": "Default log message.",
    "logLevel": "log",
    "maxConcurrency": 100,
    "outputEmpty": false
  }
}

Error Handling

Mode	Behavior
stop	Halts workflow on first error
continue	Skips failed items, passes successful ones through
errorPort	Routes failed items to Error output port

Tips

Logs input data to the system console for debugging purposes. Use when you need to inspect intermediate data flowing through the pipeline. Produces the same items it received, with two markers added to each item JSON: logged and processedAt.

Frequently asked questions

Does the Console Logger node change the data before passing it on?

Mostly no, but it does add two fields to each item's JSON: `logged`, which is always the string `"ok"`, and `processedAt`, which is an epoch-millisecond timestamp recorded at the moment of the write. Everything else in the item is forwarded unchanged.

Will inserting Console Logger break my workflow chain?

No. The node passes every item it receives straight through to its Output connector, so your downstream nodes see the same data they would have without it (plus the two added markers). You can drop it anywhere in a chain and remove it later without rewiring.

What credentials or permissions do I need to use this node?

None. Console Logger requires no credentials, API keys, or external service connections — it writes only to BusyBot's internal execution log.

When does execution go to the Error output instead of Output?

The node exposes both an Output and an Error connector. If the logging step itself fails for any internal reason, execution routes to Error rather than Output. Under normal conditions all items exit through Output.

Can I use Console Logger to permanently store log data, or is it just for debugging?

It is intended for debugging and inspection only — the write goes to the execution log, not a persistent store or external logging service. For durable audit trails you would need a dedicated database or logging-service node downstream.