Automation logs hold more PII than your database

Your largest store of customer personal data is probably not your database. It is your automation platform's execution history. n8n, Zapier, and Make all save the full input and output of every step by default, so each run records the entire inbound webhook body, every API request and response, and any attachments that passed through. That history is usually a superset of your database, because it keeps fields you deliberately chose never to persist, and it keeps them on a retention clock you almost certainly never set.

This is not a bug. It is the default that makes debugging possible: when a run fails, you want to see exactly what every node received and returned. The problem is that the same feature quietly turns your automation tool into a parallel datastore full of personal data, and most operators have never looked at how long it holds that data or what is in it.

Why your execution log is a superset of your database

Your database holds the fields you designed it to hold. A customer row might have a name, an email, a phone number, and an order ID. You decided those columns on purpose, and you left out the rest.

Your execution log made no such decision. It captured whatever flowed through the workflow. If one step calls Stripe, the log holds the full Stripe customer object, not just the ID you saved. If a step reads an inbound email, the log holds the entire message body, headers and all, not the three fields you extracted from it. If a form lets someone upload a document, the binary file is in there too. The log is a recording of everything the automation touched, before you filtered it down to the few columns you actually keep.

That is why the log is the bigger liability. The data you were careful about is in your database under your retention rules. The data you never meant to keep, the raw payloads and full API responses, is sitting in your automation history, governed by a default you have not read. The instinct to record everything for debugging is correct, and it is exactly the point of logging the request and response of every step. The miss is treating that log as ephemeral when it is one of your most sensitive stores.

What each platform keeps, and for how long

The defaults are knowable, and they are not the same. Here is what the three common platforms do out of the box, as of June 2026.

Platform	Saved by default	Default retention	What is in each record
n8n (self-hosted and Cloud)	Full data of every node, on both success and error	Pruning on by default: last 14 days or 10,000 executions, whichever comes first	Full input and output of every node, plus binary attachments per the binary data mode
Zapier	Data in and out of each step, for every task	About 30 days, up to roughly 69 days on the monthly deletion cycle	The input and output of each step in the Zap run
Make	Full bundle data passed between modules	Plan-dependent window, set by your pricing tier	The complete bundles for each run, viewable in the history detail

The n8n numbers come from its execution-data settings: EXECUTIONS_DATA_SAVE_ON_SUCCESS and EXECUTIONS_DATA_SAVE_ON_ERROR both default to all, and pruning is enabled by default with EXECUTIONS_DATA_MAX_AGE at 336 hours and EXECUTIONS_DATA_PRUNE_MAX_COUNT at 10,000. Worth knowing: n8n never prunes annotated executions, the ones you tag or rate, so a run you flagged while debugging can outlive the window indefinitely.

Zapier keeps Zap history for about 30 days by default, but its deletion runs once a month, on the first Monday, retaining the current and previous two months. So a run created early in a month can sit there for close to 69 days before it is cleared. Make ties its retention to your plan, and the run detail holds the full bundles, which is the full data moving between modules.

The takeaway is not that any one window is too long. It is that you did not choose any of these numbers, and the data they cover is broader than you think.

The compliance gap nobody closes

Here is the scenario that catches teams. A customer emails and asks you to delete their data. You find their row, delete it, and confirm. Done.

Except a copy of that customer's data is still in your automation history. The run that created the record holds their full payload. The run that emailed them holds the message. The run that charged them holds the Stripe response with their details. None of that moved when you deleted the database row. It stays until the retention window expires or until you go in and delete those specific runs by hand.

For anyone operating under GDPR, CCPA, or a contractual data-processing term, that log is personal data you are still processing and still storing. A deletion request is not satisfied by clearing the obvious copy and leaving the shadow copy in your workflow tool. This is the part operators miss, because the automation platform does not feel like a database, so it never makes it onto the retention map. Put it on the map. This is general information about how the tools behave, not legal advice, but the gap is real and it is easy to close once you can see it.

The three controls that fix it

You do not need to stop logging. You need to log less, keep it for less time, and keep the sensitive parts out of it. Three controls, applied per platform, do all three.

Control	n8n	Zapier	Make
Save less	Set EXECUTIONS_DATA_SAVE_ON_SUCCESS to none and keep errors only, or turn off saving per workflow in settings	Set the per-Zap detailed data and error-only options where available, and avoid storing payloads in Storage or Tables you do not need	Turn off "Allow storing of incomplete executions" you do not need and avoid extra data stores holding payloads
Keep it shorter	Lower EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT to match your real policy	On Enterprise, set retention to 7 to 30 days; otherwise export and delete on your own schedule	Match the plan whose retention fits your policy, and delete history you do not need
Strip the PII	Add a Set or Code node that drops or hashes personal fields before any heavy step	Add a Formatter or Code step to remove fields before the steps that log full payloads	Add a Set Variable or tools module to redact fields before the modules that carry the bundle

The first two controls are settings. The third is a design move, and it is the one that actually shrinks your exposure, because it changes what gets recorded in the first place.

Strip PII before the step that logs it

The cleanest fix is to never let the sensitive value reach a node that saves its data. If a step does not see a field, the field is not in that step's log.

Take a flow that receives a webhook with a full customer object, looks up their account, and posts a summary to Slack. By default, every one of those nodes logs the full object, so the customer's email, phone, and address are recorded three times across the run. You only needed the account ID and the order total.

Insert a transform step right after the trigger that keeps the two fields you use and drops the rest. In n8n that is a Set node in "keep only set" mode, or a Code node returning a trimmed object. In Zapier it is a Formatter or Code step. In Make it is a Set Variable or a small mapping. Everything downstream now sees, and logs, only the ID and the total. If you need to act on a sensitive value but not store it, hash it: pass a SHA-256 of the email instead of the email, so you can still match records without keeping the plaintext in history.

This is the same instinct as pushing a model early and narrow when you decide whether a step needs AI at all. Constrain what each step can see, and the blast radius of that step shrinks, whether the risk is a hijacked model or a logged payload. It is also the quiet half of prompt-injection defense: the less personal data a step holds, the less an attacker who reaches that step can exfiltrate.

What to do next

Open the run history of your busiest automation and read one full execution end to end, every node, every payload. Count how many times a customer's email, phone, or full record appears, and ask whether you meant to store any of it. Then check one number: the retention window that history is on right now, which you can find in n8n's execution settings, Zapier's data-retention page, or Make's plan. Almost no one has looked at both, and the gap between what is in there and what you intended is usually wide.

If that gap is wide, fix it in the order that pays off fastest: add the strip-or-hash step first because it shrinks every future run, then shorten the window, then turn off success-data saving where you do not need it. We build workflow automation systems with that redaction step in by default, so the execution log holds the fields the flow uses and nothing more. If you want a read on what your current automations are quietly storing, send us the flow and we will tell you what is in the log and how to get it out.