n8n Execution Data Redaction: What It Actually Hides

Short version: Enterprise only, on Cloud and self-hosted alike. It arrived in two pieces:

• n8n 2.16.0— per-workflow toggles. Workflow → … menu → Settings gives you two independent switches: Redact production execution data (webhooks, schedules, any active trigger) and Redact manual execution data (what you run from the editor).
• n8n 2.26.0— instance-wide enforcement under Settings → Security → Data redaction. Pick Production executions (the recommended floor) or Manual and production executions. Once enforced, the workflow toggles lock to Redact and the API rejects any workflow that tries to set a weaker policy.

If you're on Community, Starter or Pro, you won't see either switch. Don't panic about that yet — the rest of this post is about why the switch was never the part that mattered most.

When a redacted execution is opened, n8n swaps the data out at read time:

• Item JSON on every node's input and output becomes an empty object
• Binary data — PDFs, images, attachments — is dropped
• Fields a node author declared sensitive via sensitiveOutputFields are hidden
• Error messages shrink to the error type and HTTP status code, which matters more than it sounds: a lot of API errors echo the request body back

What stays: node names, status, timing, the workflow graph. You can still see that “Create Contact” failed with a 422 at 2:14am. You just can't see whose contact. It also flows into log streaming — redacted executions are redacted in log output too.

One design choice I like: it fails closed. If n8n can't resolve a node's type definition (say, a community node that got uninstalled), that node's whole output is redacted rather than guessed at.

This is the list nobody puts in the announcement post, and it's straight from n8n's own docs:

The first row is the one that bites. n8n describes redaction as UI-layer only, with no backend access control. Point a SQL client at a self-hosted Postgres and run something like this:

SELECT "executionId"
FROM execution_data
WHERE data LIKE '%@gmail.com%'
LIMIT 20;

On a lead-routing instance running the default save settings, that query comes back full whether redaction is on or not. Redaction changed who can see it through n8n. It didn't change what's sitting on disk.

The last row is a quieter trap. You set enforcement in staging, promote workflows to production through Git, and production has no enforcement until someone sets it again by hand.

I don't want to undersell it. It solves a real problem, just not the one people assume.

The real problem is people, not disks. On a shared instance, the ops person debugging a Slack notification can open the payroll workflow's executions and read salaries. A contractor with editor access can scroll through six months of customer phone numbers. Redaction fixes that: everyone sees that things ran, and only people with the execution:reveal scope can see what ran through them.

And reveals are audited. Clicking Reveal data asks for confirmation and emits n8n.audit.execution.data.revealed to your log streaming destination, with user, execution ID, workflow ID, IP and timestamp. Denied attempts emit reveal_failure, and policy changes emit n8n.audit.redaction-enforcement.updatedwith before and after values. For a SOC 2 auditor asking “who looked at customer data and when,” that's a clean answer. Executions that used dynamic credentials can't be revealed at all, even by an owner.

So: redaction is least-privilege for the execution viewer. Treat it as that and it's good. Treat it as data minimization and you'll write something false in a GDPR record.

Don't save it. These are the settings I change first on any self-hosted instance that touches leads, and none of them need Enterprise:

# docker-compose.yml → n8n.environment
- EXECUTIONS_DATA_SAVE_ON_ERROR=all          # keep failures, you need them
- EXECUTIONS_DATA_SAVE_ON_SUCCESS=none       # default: all
- EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false   # default: true
- EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=72                 # hours; default 336 (14 days)
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000       # default 10,000

Successful runs are where most personal data piles up, and they're the runs you almost never open. Failures you keep, because that's where you debug. If a blanket noneis too aggressive, the same options exist per workflow under Workflow settings → Save successful production executions. I set it on the workflows that carry contact data and leave internal plumbing alone.

Do the retention math for your volume, too. The defaults prune at 14 days or 10,000 executions, whichever hits first. A form webhook doing 1,500 runs a day hits the count cap in under seven days, so the age setting never kicks in. A workflow doing 40 a day keeps two full weeks of payloads. Same settings, very different exposure.

Three gotchas that show up in audits:

• Annotated executions are never pruned. Tag or rate an execution once while debugging and it lives forever, payload included.
• Pruning soft-deletes first. Hard deletes run every 15 minutes by default, with a 1-hour buffer. Fine for storage, worth knowing if you promise a deletion time to anyone.
• Backups outlive pruning. If you dump Postgres nightly and keep 30 days of dumps, your real retention is 30 days plus MAX_AGE, not MAX_AGE.

The most common leftover in a Code node is console.log(JSON.stringify($input.all())) from some old debugging session. In production that goes to stdout. Stdout goes to docker logs, and from there to whatever ships your logs — Loki, Datadog, a Synology log center nobody rotates.

Redaction does nothing here, and neither do the save settings. An execution that n8n never saved can still have printed its entire payload to a log that's retained for 90 days. Grep your workflow exports for console.logand delete anything that prints items instead of counts. It's a five-minute job.

If you've set up tracing for your AI agent workflows, check that too. Prompt and completion capture puts the same customer message into a second system with its own retention.

Not on its own. If you're a solo operator or a small team where everyone with n8n access already has database access, redaction hides data from people who can read it anyway. Spend the effort on the save settings and the log cleanup instead.

It starts to earn its keep when:

• several teams share one instance and shouldn't see each other's data
• contractors or clients get editor access to their own projects
• an auditor wants a record of who viewed customer data, not just a policy that says nobody does

That's also roughly the point where the Cloud vs self-hosted question gets serious, and where version control stops being optional — with the caveat above that enforcement won't ride along in Git.

In order:

1. SAVE_ON_SUCCESS=none on workflows with personal data, errors still saved
2. SAVE_MANUAL_EXECUTIONS=false and MAX_AGE down to 72 hours
3. Kill payload-printing console.log calls
4. Match your database backup retention to what you'd say out loud to a client
5. On Enterprise, enforce production redaction and stream reveal events somewhere you'll actually read

Steps one through four are the ones that change what's on disk. Step five changes who can look. Both matter, but if you only have 30 minutes, do the first four. The same thinking applies to where you store leads and to what your AI nodes are allowed to touch: decide what the system keeps before you decide who's allowed to see it.