Settings reference

Why you want a quick reference

n8n does not actually have that many settings. The problem is that they are split across several layers — you flip a switch and it turns out that switch only affects you; or you hunt through your own Settings for something only an admin or an environment variable can change. Cases we have really hit:

• "Switch the interface to Chinese for me" — that is not something Personal can change. n8n community has no UI language dropdown; it takes the instance's N8N_DEFAULT_LOCALE env var, so ask IT.
• "Set the Schedule node to local time for me" — that is the workflow-level Settings tab, or ask IT to change GENERIC_TIMEZONE.
• "The execution I ran last week is gone!" — that is the instance-level EXECUTIONS_DATA_MAX_AGE; the default of 336 hours (14 days) auto-purges it, you have no permission to change it, so ask IT.
• "I pressed Manual Execute but there is no record on the Executions page" — that is Save manual executions in the workflow Settings. The official n8n instance default is actually on (EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true), but plenty of company IT teams turn it off to save DB space, so not seeing it on your instance does not mean anything is broken — it has been overridden.

This appendix sorts settings by "can you change it / who does it affect" into two groups — Personal (your own screen, change it any time) and Workspace / Instance (shared across the company, admins or env vars only). Once that split is clear, you will know where to look and who to ask for 90% of the settings problems you hit.

Two layers of settings: Personal vs Workspace

Get the mental model up first. n8n settings come in two layers — one is your own screen preferences, the other is how the whole instance behaves. Change the wrong layer and nothing happens.

Personal settings: your account only

Click the avatar next to the three dots in the bottom-left corner → Settings, and n8n opens the Personal settings page. These settings are tied to your account (stored in the n8n DB) and have nothing to do with your colleagues.

Workflow-level settings: open the workflow and find the Settings tab

Open any workflow and you will see the tabs Editor / Executions / Evaluations / Settings across the top of the screen. Click Settings and you are in that workflow's own settings. These options affect this one workflow only and touch nothing else.

Instance-level settings: how the whole n8n behaves

These are written as environment variables (an .env file, or environment: in docker-compose) — you cannot see them in the UI and you cannot change them there, so moving one means asking IT or an admin. Knowing what they mean is what stops you asking IT about a pile of things that were never in the UI.

Execution retention: why your records disappear

The community edition auto-purges after 14 days (336 hours) by default, and this is the trap most people fall into. Every run of a workflow produces one execution record — along with each node's input / output data, if the Save options are on — sitting in PostgreSQL / SQLite. Over time the DB swells, so n8n's official default is 14 days; without it, a fresh instance running for three months turns up with a 20GB DB.

What that means:

• An execution from 15 days ago is simply gone, successful or failed — not in the UI, not in the DB.
• The execution's node input / output data goes with it — if you want to look back at what the API returned that day, it is not there.
• What you did to outside systems (the Slack messages, the Airtable rows) is of course still there — what got deleted is only n8n's own execution record.

Three ways to keep them longer:

1. Ask IT to change the environment variable

   Ask IT to move EXECUTIONS_DATA_MAX_AGE from 336 to whatever you need (the unit is hours, not days). 30 days is 720, 90 days is 2160.

2. Save the important data yourself

   Put a Google Sheets / Airtable / DB node at the end of the workflow and write the important parts of each run (input, time, result) somewhere outside — that way your audit trail is there however long n8n keeps executions. This is the most reliable approach for audit compliance.

3. Dump the whole DB on a schedule

   Have IT run a daily pg_dump backup of n8n's PostgreSQL. Once executions are purged you can still restore from a dump when you need to go back. Suits companies with strict audit requirements.

Timezone precedence, three layers: why schedules run at the wrong time

"I set it for 9 in the morning, so why does it run at 5 in the afternoon?" — nine times out of ten the Timezone was never set. n8n decides a workflow's timezone in three layers, highest first:

With none of them set you get America/New_York — that is the official n8n default for GENERIC_TIMEZONE (not UTC, which is what most people assume). So a fresh installation can run a schedule at the wrong local time unless you set the timezone deliberately; the offset varies by location and daylight saving. TZ (the Node.js process timezone) follows the base image default instead, and the official Docker image is UTC — the two variables end up out of step, log times and workflow times may not line up, so in practice set GENERIC_TIMEZONE and TZ to the same value.

Note: the English edition uses Europe/London only as a valid IANA example. Replace it with the timezone for your users. Recommended approach:

1. Set the instance floor first

   Ask IT to add both GENERIC_TIMEZONE=Europe/London and TZ=Europe/London to .env and restart. New workflows then default to local time and you do not have to set each one by hand.

2. Set it again on the workflow, for safety

   For any workflow using Schedule / Cron, still go into the Settings tab and pick Europe/London explicitly — then even if IT later changes GENERIC_TIMEZONE, or you move to a different n8n, your schedule times do not move.

3. Only write it in an expression for cross-timezone data

   Use .setZone() in an expression only when you are handling data across timezones (for example, showing a UTC timestamp in local time) — do not write it in every node, that is a maintenance nightmare.

The settings you will change most often

Three checklists, one per role. Work through the one that fits and 90% of the day-to-day problems never happen.

A new user's first day (all of it is yours to do):

• Personal settings → check that First name / Last name / Email are right
• If you will use the API: Personal settings → API Keys → create one and store it safely
• Turn on 2FA alongside your password (if the instance has the feature enabled — see Chapter 2)
• Want a Chinese interface → you cannot change this yourself; ask IT to set the instance-level N8N_DEFAULT_LOCALE

Every time you build a workflow (3 minutes):

• Settings tab → set Timezone to Europe/London (or your local IANA zone; otherwise the workflow uses the instance setting, whose documented default is America/New_York)
• Point Error Workflow at your handler workflow (build one first if you do not have it — see Chapter 17)
• While building, confirm Save manual executions is Save (if IT turned the instance default off, force it on here)
• Turn on Timeout Workflow for anything long-running (one hour, say)
• Add Redact production execution data for PII or payment data

What IT / admins decide before deploying (once):

• Set GENERIC_TIMEZONE + TZ to Europe/London
• Set WEBHOOK_URL explicitly to the public domain (required behind a reverse proxy)
• Decide EXECUTIONS_DATA_MAX_AGE from your audit requirements (14 days / 30 days / 90 days)
• Generate a strong N8N_ENCRYPTION_KEY, the key that encrypts credentials, and back it up (replace it and no existing credential can be decrypted)
• Move the DB from the built-in SQLite to PostgreSQL (required in production)

Common pitfalls

1. The Schedule / Cron node runs at the wrong time

   99% of the time the workflow's Timezone was never set, so it ran on the instance default (officially America/New_York, not UTC). Open the workflow → Settings tab → set Timezone to Europe/London → Save. If the instance has no GENERIC_TIMEZONE either, ask IT to add it while you are at it. The new timezone applies from the next trigger; a run already scheduled still uses the old time.

2. Last week's records are gone from the Executions page

   The community edition auto-purges after 14 days by default — past that they are cleared and there is nothing to recover on the n8n side. To keep them longer, change EXECUTIONS_DATA_MAX_AGE (ask IT). The long-term fix: write the important data to a Google Sheet / DB and do not treat n8n executions as your audit trail.

3. I cannot see an Instance settings page or an admin page

   Most instance settings were never changeable in the UI in the first place; they are all environment variables. Not finding them is not a permissions problem, it is that they are not in the UI at all. Some admin-only pages (Users management, for example) are visible only to the owner / admin roles — ask IT, or whoever set this instance up.

4. I cannot find the "Personal → Language" dropdown

   In the official n8n community edition, Personal settings has no UI language dropdown — you are not going blind, it simply does not exist. The UI language comes from the instance's N8N_DEFAULT_LOCALE env var (and only base tags like en / zh, not zh-TW / zh-Hant); changing it means restarting the whole n8n, and it affects everyone in the company. Tutorials online that say "switch it to Simplified Chinese" are mostly older screenshots or a third-party fork.

5. I changed the workflow Settings but Executions still saves nothing

   Three things to check. (a) Did you actually press Save on the workflow Settings, rather than flipping the toggle and walking away? (b) Did you press Execute Workflow (manual), or did something outside trigger it? Manual runs go through Save manual executions and production runs through Save successful / failed production executions — three independent switches. (c) If the workflow Settings say "Default", they follow the instance's EXECUTIONS_DATA_SAVE_* env vars, so if IT turned the instance default off, Default means off. To force the save, pick Save explicitly in the workflow Settings.

6. The URL the Webhook node gives me is localhost and nothing outside can call it

   The instance has no WEBHOOK_URL set, so all n8n knows is its own host. Ask IT to add WEBHOOK_URL=https://n8n.your-company.example (protocol and domain included) and restart. After that, the URL the Webhook node shows is the one the outside world can actually reach.

7. The Error Workflow never fires

   A few common causes: (a) the Error Workflow itself is not switched to Active; (b) its trigger is not an Error Trigger node; (c) the failing workflow's Settings never named this Error Workflow. Check all three — see Chapter 17.

8. I changed an env var and nothing seems to have happened

   Environment variables do not hot reload — after editing .env or docker-compose you need docker compose down && docker compose up -d (or a system service restart) before the new values are read. restart is sometimes not enough (especially after editing docker-compose.yml), so do a full down and up.

FAQ