Utility & debugging
Helper nodes for observability, validation, and ending workflows cleanly.
Log
What: Writes a message to the execution log. Visible in the per-node output and in /logs.
Inputs: Any.
Outputs: Pass-through (the input data is forwarded unchanged on output).
Configuration:
| Field | Notes |
|---|---|
| Message | The text to log. Supports expressions. |
| Level | debug, info, warn, error |
| Include input | Attach the input data alongside the message |
Use case: Trace what's happening between nodes during development; record audit events in production.
Example:
Message: Processed order {{ $trigger.body.orderId }} for {{ $trigger.body.customerName }} at {{ $node["Create label"].json.trackingNumber }}
Level: infoDebug
What: Like Log but with a breakpoint-style pause. When the workflow hits a Debug node in debug mode, execution pauses until you click Continue in the editor.
Use case: Step through a workflow to inspect intermediate state.
Notes: Only takes effect when the workflow is run in debug mode (toolbar's Run dropdown → Debug). In normal runs, behaves like Log.
Terminal
What: Marks the workflow's end point and emits the final output.
Inputs: Whatever you want to return.
Outputs: The terminal output of the workflow.
Configuration:
| Field | Notes |
|---|---|
| Status | success (default) or failed, controls the execution's final status |
| Output | The data to return |
Use case:
- Make the final output of a workflow explicit and named (rather than implicit from the last action node).
- Force a
failedstatus from a logic branch without throwing an exception (e.g. "if we got this far, it's a business-rule failure").
Schema Validator Guard
What: Validates data against a JSON Schema. Routes valid items to output, invalid items to error with detailed validation messages.
Use case: Trust boundaries, validate inputs from external triggers or upstream APIs before passing them to consuming nodes.
Configuration:
| Field | Notes |
|---|---|
| Schema | A JSON Schema object |
| Mode | strict (any extra field is an error) or permissive (extras ignored) |
Output Format Guard
What: Ensures a node's output matches an expected shape. Different from Schema Validator: the Output Format Guard reshapes / coerces, not just validates.
Operations: Drop unexpected fields, coerce types, fill missing fields with defaults.
Use case: Normalising AI Agent output that's supposed to be JSON but sometimes isn't quite.
Rate Limiter Guard
What: Throttles a downstream operation to N invocations per time window.
Configuration:
| Field | Notes |
|---|---|
| Max calls | e.g. 100 |
| Window | e.g. 60 seconds |
| Behaviour on limit | block (delay until budget refills), drop (skip), error |
Use case: Protecting yourself from accidentally overwhelming a flaky downstream API even when retries kick in.
Set
Covered in Storage & database. Reproduced here for discoverability because it's heavily used for debugging, set a checkpoint value, use the inspector to see what's in it, decide what to do next.
Cache Storage
Covered in Storage & database. Useful in debugging for caching slow upstream calls during iteration.
Tips & gotchas
- Log everything during development; trim before production. Verbose logs cost storage and obscure the real signal.
- The Debug node is editor-only. In production runs scheduled or webhook-triggered, it logs but doesn't pause.
- Schema Validator Guard's error messages are JSON Schema-style, readable but not always user-friendly. Wrap with a Data Transform if you need to surface them to humans.
- Rate Limiter is per-worker, per-key. In a multi-worker deployment, two workers each get their own budget unless you switch the backend to Redis (admin-configured).
Related
Found something out of date? This page lives in the Flero docs content set.