Create a Logging Step That Writes a Compact Run Record

A single row should answer what happened on this run without reopening the automation platform run detail. By now the workflow produces a lot of evidence scattered across steps, triage fields, the route taken, retry counts, HTTP status, error classes, and platform run history captures all of it, but per-tool and hard to summarize at a glance. This lesson pulls that evidence into one compact, cross-tool record: we'll define the schema, pick a sink to write it to, wire the logging step into the n8n workflow, verify it across three representative runs, and apply privacy and retention rules so the log doesn't become its own liability.

That row tells us which input was processed, what the triage step output, which route executed, whether retries happened, and whether an error occurred. The key is that a logging step is a deliberate side effect we control, separate from platform history. Platform history is per-tool and sometimes hard to summarize, while the log row is cross-tool and easy to query.

Scope is one compact schema and one durable write at the end of the n8n workflow. The rule is to log just enough fields to reproduce and debug, not the entire message body by default.

To make the schema concrete, we can inspect and adjust an example table definition before wiring it into the workflow.

The schema is a direct evolution of the manual run log discipline. We still capture the minimum evidence needed to answer what happened, but now the workflow writes the record automatically on every run.

Rule: Log identifiers and outcomes first, and store large raw payloads behind a reference like raw_response_ref instead of copying full blobs