What should I and shouldn't I log in a workflow?
Too little log means no debug. Too much log means GDPR risk, storage cost and noise. Rule: log identifiers and metadata, not payloads.
Try this first
- 1Log by default: flow_id, run_id, step, timestamp, status, duration, external ids of related records (order_id, contact_id, message_id).
- 2Never log: passwords, API keys, full card numbers, social security numbers, medical data, password resets, MFA codes.
- 3For PII (name, email, phone): log a hash or the first few characters, not the full value. For debug it is enough, the regulator has nothing to trip on.
- 4Retention: 30 to 90 days for operational logs, 1 year for audit-relevant logs. Longer only with legal cause.
- 5Test logs with a fake payload containing sensitive ids: review them, you'll see immediately if anything sensitive leaks.
When to bring us in
Unsure if your current flow logs are GDPR-proof, a quick review on 2 or 3 flows gives you the picture. We can help.
See also
- n8n: self-host or cloud?Self-hosted is cheaper at volume and keeps data local. Cloud removes ops burden.
- Zapier or Make: which fits better?Zapier is straight-line; Make handles complex flows with routers and iterators for less money.
- Power Automate Cloud or Desktop: which to use?Cloud for SaaS integrations and triggers. Desktop for RPA against legacy Windows apps without APIs.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.