What to Keep Out of Your Automation Logs (n8n & Make Redaction Checklist, 2026)
What to keep out of your automation logs Short answer: log that something happened and which record it touched, not the sensitive content itself. Execution history is useful for debugging, but it is also a second copy
What to keep out of your automation logs
Short answer: log that something happened and which record it touched, not the sensitive content itself. Execution history is useful for debugging, but it is also a second copy of your data that more people can read, export, and forget about.
The question comes up regularly in automation communities ("what information do you deliberately keep out of your logs?"), and most builders only think about it after a log leaks something.
What to keep out
| Category | Why it is risky in logs | What to log instead |
|---|---|---|
| API keys, tokens, auth headers | Anyone with log access can reuse them | Credential name only |
| Passwords, reset links, magic links | Direct account takeover | Nothing; just "link sent" |
| Full email bodies and attachments | Personal and business data copied everywhere | Message id + subject hash |
| Payment details, bank info | Compliance exposure | Last 4 digits or an order id |
| Personal data (phone, address, ID numbers) | Privacy law obligations | Internal customer id |
| Raw LLM prompts containing customer text | Prompts quietly carry the data above | Template name + record id |
A 15-minute redaction pattern
-
Add one "Log Safe" step at the end of each branch (a Set / Code node in n8n, a Set variable module in Make) that builds a small object:
workflow,record_id,status,timestamp. - Send only that object to your log destination (sheet, database, Slack alert).
- Turn down built-in retention. In n8n, review the settings that control saving execution data for successful and failed runs, and how long old executions are pruned. In Make, review scenario history retention for your plan.
- Mask before alerting. Error alerts to chat should name the workflow and record id, never paste the payload.
- Keep secrets in credential stores, not in node parameters or hard-coded in Code nodes where they show up in exports.
Quick test
Pick your busiest workflow, open the last failed execution, and ask: if I pasted this screen into a public forum for help, what would I regret? Whatever you listed is what needs redacting.
Where Make helps
If your team prefers a visual scenario builder, Make lets you keep the log step as a single reusable module at the end of each route. You can start on the free plan: Make free plan.
Common mistakes
- Redacting in the log node but not in the error path. Error workflows often receive the full payload.
- Pinning real customer data while testing and leaving it in the workflow.
- Sharing workflow exports that still contain pinned data or hard-coded keys.
- Assuming "internal" means safe. Contractors, backups and screenshots all widen the audience.
Bottom line
Log identifiers and outcomes, not content. A tiny "Log Safe" step per workflow costs minutes now and avoids a painful cleanup later.
Disclosure: Some links are affiliate links — I may earn a commission at no extra cost to you.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.