Part 9 of the n8n Workflow Testing Series — this article covers the last piece of the production puzzle. Once your workflow is live and running, a log table is how you know what it is doing every day.
Screenshot note: Some images are “n8n-inspired” mockups, not exact screen captures of your n8n environment—but they are meant to make the steps easier to follow. Hint, hint, n8n Design Team… if the editor ever looks this slick, I will pretend I had nothing to do with manifesting it.
The Invisible Workflow Problem
Your workflow is live. It runs on its own. Leads come in, records get created, emails go out. Everything seems fine.
But do you actually know what it did yesterday? Do you know how many leads it processed? Do you know which ones it skipped and why? Do you know whether any failed validation or triggered an error?
Most builders do not. The workflow runs quietly in the background, and unless something breaks badly enough to trigger an alert, there is no simple record of what happened.
n8n does keep an execution history, and that is useful. But it is a technical record — a list of runs with node-by-node details. It is great for debugging, but it is not the kind of clean summary a client, a teammate, or your future self can read at a glance.
A log table solves this. It is a simple, readable record — one row per workflow run, or one row per key action — that tells you what your workflow did, when it did it, and what the result was. You can share it with a client. You can filter it by date. You can spot patterns. You can prove something happened.
This article shows you how to build one.
Why an External Log Table Is Worth Building
n8n’s built-in execution history is useful for debugging. When something breaks, you open the execution, click through the nodes, and find the problem. That is what Articles 7 and 8 covered.
But execution history has limits that matter in production:
It is not always easy to share. A client or a business owner cannot log into your n8n instance to check whether their invoice workflow ran correctly last Tuesday. A Google Sheet can be shared with anyone.
It may not keep records forever. Depending on your n8n plan and configuration, older executions may be deleted automatically after a certain period. An external log table is permanent until you decide otherwise.
It is technical. Reading execution history requires understanding n8n’s interface. A log table in a spreadsheet can be understood by anyone, with no training.
It does not summarize patterns. Execution history shows you one run at a time. A log table lets you filter, sort, and count — so you can see things like “how many leads were processed this week” or “how many failed validation in the last month.”
Think of execution history as your workshop and the log table as your receipt book. Both matter. They serve different purposes.
Where to Keep Your Log Table
You do not need anything fancy. The best place for a log table is wherever you and your team already look at data.
Google Sheets is the most common choice for beginners. It is free, easy to share, and most people already know how to use it. n8n has a built-in Google Sheets node that makes writing to a sheet straightforward.
Airtable works well if you prefer a more database-like structure. You can add views, filters, and automations on top of your log data. n8n has an Airtable node.
Notion is a good option if your team lives in Notion. You can add a log database inside the same workspace where you keep your project notes and documentation.
Supabase or Postgres are better choices for builders who are comfortable with databases and need to query log data at scale or build reports from it. These take more setup but are more powerful.
Any other database you already have access to — MySQL, SQLite, or a no-code database tool — will also work. The format matters less than the habit of using it.
For most beginners, start with Google Sheets. You can always move to something more powerful later.
What Fields to Include
Keep the log table simple. You do not need dozens of columns. Here are the fields that give you the most useful information without becoming a burden to maintain.
| Field | What it records | Why it matters |
|---|---|---|
| Timestamp | When the workflow ran | Lets you search by date and correlate with external events |
| Workflow name | Which workflow wrote this row | Essential when one log table covers multiple workflows |
| Environment | DEV, STAGING, or PRODUCTION | Tells you whether this was a real run or a test |
| Execution ID | The n8n execution ID | Links the log row back to the full execution in n8n for debugging |
| Record ID | The ID of the record being processed | Tells you exactly which customer, order, or form submission this row is about |
| Status | Success / Skipped / Failed / Dry-run | The most important field — tells you what the workflow did |
| Action taken | A short description of what happened | For example: “Lead created in CRM” or “Skipped — duplicate email” |
| Error message | The error text if something went wrong | Lets you diagnose failures without opening n8n |
| Test case ID | The test case this run was part of | Only needed during testing — leave blank in production |
| Dry-run | True or False | Tells you whether this was a real run or a test run |
Not every workflow needs all ten fields. Start with Timestamp, Workflow name, Environment, Status, Action taken, and Record ID. Add the others as your needs grow.
The Difference Between Technical Logs and Business Logs
Before you build your log table, it helps to decide who it is for.
A technical log is for you and your teammates. It captures the execution ID, node names, raw error messages, and internal field values. The goal is to help you debug problems and trace what happened.
A business log is for clients, managers, or stakeholders. It uses plain English. It might say “Invoice sent to Acme Corp for $2,400” instead of “Gmail node executed — recipient: accounts@example.com — execution ID: 48291.” The goal is to give a non-technical person a clear picture of what the workflow accomplished.
For most production workflows, you want both.
The simplest approach: build one log table that covers the technical fields, and then add one or two plain-English summary columns — like “Action taken” — that translate the technical result into plain language. That way you have one log that works for debugging and for sharing.
Where to Add Logging Steps in Your Workflow
A log row does not have to be written just at the end of a workflow. It is often more useful to write it at specific moments throughout the run. Here are the five most important places to add a logging step.
At the start of the workflow. Write a row when the workflow begins processing a record. Include the record ID and a status of “Processing started.” This creates a trail even if the workflow crashes before it finishes — you will know it started, which helps narrow down where it stopped.
After a key action. When something important happens — a CRM record is created, an email is sent, an invoice is generated — write a log row immediately after. Status: “Success.” Action: what was done. This is the confirmation that the action actually happened.
When an item is skipped. If the workflow deliberately skips a record — because it is a duplicate, because it does not meet a condition, or because it was already processed — write a row explaining why. Status: “Skipped.” Action: “Duplicate email address — record already exists.” Without this, skipped records are invisible, and it looks like the workflow just ignored them.
After a validation failure. If your validation nodes (from Article 4) catch a bad record and stop it, write a log row with the details. Status: “Failed — Validation.” Action: “Email field was blank.” This is how you spot patterns — if you see fifty “Email field was blank” rows in one week, you know there is a problem with the form on your website.
On the error branch. When the error workflow catches a failure (from Article 6), it should also write a log row in addition to sending the alert. Status: “Failed — Error.” Error message: the raw error text. This creates a permanent record in your log table even if the execution history eventually gets cleared.
A Real Example: Lead Processing Workflow
Let’s say you have a live workflow called PRODUCTION - Lead Processor that runs every time a new lead submits a form. Here is what the log table would capture across a few different scenarios.
The workflow receives ten form submissions in one hour. Here is what the log looks like:
| Timestamp | Workflow | Environment | Record ID | Status | Action taken |
|---|---|---|---|---|---|
| 09:02:14 | Lead Processor | PRODUCTION | lead_4401 | Success | Lead created in HubSpot. Welcome email sent. |
| 09:07:33 | Lead Processor | PRODUCTION | lead_4402 | Skipped | Duplicate email address. Existing record updated. |
| 09:15:55 | Lead Processor | PRODUCTION | lead_4403 | Failed — Validation | Email field was blank. Record sent to review sheet. |
| 09:22:10 | Lead Processor | PRODUCTION | lead_4404 | Success | Lead created in HubSpot. Welcome email sent. |
| 09:31:44 | Lead Processor | PRODUCTION | lead_4405 | Failed — Error | HubSpot API timeout. Error alert sent. |
Five rows. Five different outcomes. In thirty seconds of reading, you can see exactly what happened, which records were affected, and what to follow up on. No opening n8n. No clicking through node outputs. Just a table.
When the client asks “did my form work this morning?” you can answer the question in thirty seconds.
A Privacy Warning Before You Build
Log tables are useful precisely because they capture data about real events and real records. That same quality makes them a privacy risk if you are not careful.
Do not log the following:
- Passwords, API keys, access tokens, or webhook secrets
- Full credit card numbers or payment details
- Government ID numbers, tax IDs, or social security numbers
- Medical or health information
- Any field that is covered by GDPR, HIPAA, or other privacy regulations under which your business operates
Be careful with:
- Customer email addresses — log them only if you have a clear business need, and your privacy policy allows it
- Customer names — use a record ID to identify the person rather than logging their full name in plain text if possible
- Financial amounts — logging invoice totals is usually fine, but avoid logging detailed transaction data in an insecure spreadsheet
A Google Sheet is not a secure database. It is shared, accessible to anyone with the link, and may be indexed by third-party tools. Log the minimum amount of personal data needed to make the log useful. Use record IDs to identify records rather than personal details where possible.
If your workflow handles sensitive data — health records, financial accounts, children’s data — consult your privacy policy and legal requirements before deciding what to log and where.
Common Mistakes Beginners Make
Logging too little. The most common mistake. A log with only “Success” or “Failed” and nothing else tells you almost nothing useful. Add enough detail to understand what happened without opening n8n. At minimum: what record was processed, what happened to it, and when.
Logging too much sensitive data. The second most common mistake. Copying the entire webhook payload into a log column means you may be storing customer emails, phone numbers, or other personal data in a plain spreadsheet. Log the record ID and a summary, not the raw data.
Not recording the status. Without a clear status field — Success, Skipped, Failed — the log is just a list of things that happened. The status field is what lets you filter by outcome, count failures, and spot patterns.
Not recording the record ID. Without a record ID, a log row tells you what happened but not to whom. If a failure occurred, you need to know which record to investigate or reprocess. Always log the ID.
Not logging dry-run mode. If you run the workflow in dry-run mode (from Article 5) and forget to include a Dry-run: true field in the log, those test rows will mix in with your real production rows. When you review the log later, you will not be able to tell which rows were real.
Not reviewing the logs. The most painful mistake: you build a beautiful log table, it collects data for three months, and nobody ever looks at it. A log table is only useful if someone reviews it regularly — at least once a week for production workflows. Set a reminder. Make it part of your workflow review habit.
Document Your Results
Use this template to document your log table setup. Fill it in when you create the log and update it whenever the table structure changes.
WORKFLOW LOG TABLE DOCUMENTATION
Workflow name: [Your Workflow Name]
Log table location: [Google Sheet URL / Airtable base name / Database name]
Log table name: [Sheet or table name — e.g. "Lead Processor Log"]
Created by: [Your name]
Date created: [Date]
Last updated: [Date]
---
COLUMNS IN THIS LOG TABLE:
Column: Timestamp
Type: Date/time
Source: n8n — added by logging node at each log point
Notes: [Any formatting details]
Column: Workflow name
Type: Text
Source: Hardcoded in the logging node
Notes: [e.g. "PRODUCTION - Lead Processor"]
Column: Environment
Type: Text — DEV / STAGING / PRODUCTION
Source: Hardcoded or pulled from Set node
Notes:
Column: Record ID
Type: Text
Source: [Field name from your workflow — e.g. lead_id]
Notes:
Column: Status
Type: Text — Success / Skipped / Failed / Dry-run
Source: Set by logging node based on branch taken
Notes:
Column: Action taken
Type: Text
Source: Short description written into logging node
Notes: [e.g. "Lead created in HubSpot" or "Skipped — duplicate"]
Column: Error message
Type: Text
Source: Error branch logging node
Notes: Only populated on failure rows
Column: Dry-run
Type: True / False
Source: dryRun field from Set node (Article 5)
Notes: Always log this — helps separate test rows from real ones
---
LOG POINTS IN THE WORKFLOW:
Log point 1: [Where in the workflow — e.g. "After trigger node"]
Status written: [e.g. "Processing started"]
Log point 2: [e.g. "After CRM create node"]
Status written: [e.g. "Success"]
Log point 3: [e.g. "On duplicate skip branch"]
Status written: [e.g. "Skipped — duplicate"]
Log point 4: [e.g. "On validation failure branch"]
Status written: [e.g. "Failed — Validation"]
Log point 5: [e.g. "On error branch"]
Status written: [e.g. "Failed — Error"]
---
Privacy check:
Does this log table store personal data? YES / NO
If yes, what data and why: [Describe]
Privacy policy covers this? YES / NO / NOT CHECKED
Reviewed with: [Name or "Self-reviewed"]
---
Review schedule:
How often is this log reviewed: [e.g. Weekly / After each production run]
Reviewed by: [Name]
Keep this alongside your other workflow documentation — the staging test log, the test case table, and the lifecycle document from Article 8. Together they give a complete picture of how the workflow was built, tested, and what it does every day.
Use AI to Help
Designing a log table from scratch can feel like guessing. You are not sure which fields to include, how to name the status values, or where to put the logging nodes. AI can help you think through all of this based on what your workflow actually does.
Here is a prompt you can use:
I have an n8n workflow that does the following:
[Describe your workflow step by step — what triggers it,
what it checks, what it creates or sends, and what
happens when something goes wrong.]
I want to create a simple log table for this workflow
to track every run in production.
Please:
1. Suggest the columns I should include in the log table,
with a brief explanation of why each one matters.
2. Suggest what status values I should use — for example,
Success, Skipped, Failed — and when each one should
be written.
3. Tell me where in the workflow I should add logging nodes
— which specific moments are worth capturing.
4. Write a sample log row for three scenarios:
- A successful run
- A skipped record (e.g. duplicate)
- A failed run with an error
5. Flag any fields I should NOT log for privacy reasons
given what this workflow handles.
This prompt gives the AI enough context to suggest a log structure that fits your workflow, not just a generic template. Point 5 — asking the AI to flag privacy risks — is particularly useful for workflows that handle customer data.
Zero to Hero Tip: Ask AI to Write Your Logging Node Messages
The “Action taken” column is the most human-readable part of your log. It should use plain English that anyone can understand at a glance. Writing consistent, clear log messages for every branch of your workflow takes time, but AI can draft them all at once.
My n8n workflow has the following branches and outcomes:
[List each branch. For example:
- Branch 1: New lead successfully created in CRM and
welcome email sent
- Branch 2: Lead already exists — record updated
- Branch 3: Email field was blank — record skipped
- Branch 4: CRM API timed out — error alert sent
- Branch 5: Dry-run mode — no real action taken]
For each branch, write a short log message (one sentence)
that I can hardcode into my logging node. The message
should:
- Start with what happened (not what failed to happen)
- Be clear to someone who does not know n8n
- Include a placeholder like [RECORD_ID] or [EMAIL] where
a field value should be inserted
This gives you ready-made log messages for every branch — consistent, plain-English, and immediately usable. Paste them into the text fields of your logging nodes and you are done.
Production Readiness Checklist
Go through this before you consider your logging setup complete.
- I have created a log table in Google Sheets, Airtable, or another tool
- The log table has at minimum: Timestamp, Workflow name, Environment, Record ID, Status, and Action taken
- I have a logging node after the main successful action
- I have a logging node on each skip branch with a reason for skipping
- I have a logging node on each validation failure branch
- I have a logging node on the error branch
- The Status field uses consistent values: Success / Skipped / Failed / Dry-run
- The log table includes a Dry-run field, so test rows are clearly marked
- I am not logging passwords, API keys, tokens, or sensitive personal data
- I have reviewed what personal data the log captures and confirmed it is appropriate
- I have a schedule for reviewing the log regularly
- I tested the logging by running the workflow in dry-run mode and confirming that rows appear
Production Readiness Question: If someone asked me right now to show them every record my workflow processed in the last seven days — could I answer that in under a minute using my log table?
If the answer is no, the log table needs more work.
Final Takeaway
A log table does not have to be complicated. One spreadsheet. Ten columns. A logging node at each key moment in your workflow.
What it gives you is something that n8n’s execution history alone cannot: a clean, readable, shareable record of what your workflow did every day.
When a client asks if their data was processed, you have an answer. When a record goes missing, you know exactly where to look. When something fails, you spot the pattern before it becomes a habit.
Build the log table when you build the workflow. Not after the first time someone asks you to prove it worked.