Step by Step Guide to Resolve n8n Session Timeout Authentication Issues
Who this is for: n8n administrators and DevOps engineers who need a reliable, production‑grade login experience without unexpected log‑outs. We cover this in detail in the n8n Authentication Errors Guide.
Quick Fix for Unexpected Log‑outs
- Open the n8n configuration (
.envfile or Docker environment). - Set a longer timeout, e.g.:
N8N_SESSION_TIMEOUT=86400 # 24 h (seconds)
- Restart n8n (
docker restart <container>ornpm run start). - Confirm the new value in the UI: Settings → General → Session timeout (shows “24 h”).
Result: Users stay logged in for the configured period; the automatic logout disappears.
1. Why n8n Logs Users Out – The Underlying Mechanism
If you encounter any csrf token missing resolve them before continuing with the setup.
n8n stores the authenticated user’s JWT in a server‑side session store (memory, Redis, or a database). The N8N_SESSION_TIMEOUT variable (default 3600 s = 1 h) defines how long the session cookie stays valid. When the timer expires, middleware clears the JWT, forcing a redirect to the login page.
| Component | Default Timeout | Typical Use‑Case |
|---|---|---|
| In‑memory (single‑node) | 3600 s | Small teams, dev environments |
| Redis / DB store | 3600 s (inherits) | Scaled clusters, production |
| “Remember me” (refresh token) | N/A | API‑only access (basic auth) |
EEFA note: A 1‑hour timeout is often too short for long‑running workflows or users who step away. Extending the timeout improves usability but widens the attack window for stolen cookies. Balance accordingly (see § 5).
2. Configuring a Custom Session Timeout
If you encounter any rate limit exceeded resolve them before continuing with the setup.
2.1. Using an .env File (most common)
Add or update the variable in the file that n8n reads at start‑up.
# Example: 12‑hour timeout (43200 seconds) N8N_SESSION_TIMEOUT=43200
Save the file and restart the service.
2.2. Docker‑Compose Override
When n8n runs via Docker‑Compose, edit the environment: section.
Snippet 1 – Service definition
services:
n8n:
image: n8nio/n8n
ports:
- "5678:5678"
Snippet 2 – Environment variables
environment:
- N8N_SESSION_TIMEOUT=86400 # 24 h
- DB_TYPE=postgresdb
# …other vars…
Apply the changes with docker-compose up -d.
2.3. Kubernetes (Helm)
Add the timeout to the Helm values.yaml.
env:
- name: N8N_SESSION_TIMEOUT
value: "259200" # 72 h
Upgrade the release:
helm upgrade my-n8n n8n/n8n -f values.yaml
3. Verifying the Effective Timeout
| Method | How to check |
|---|---|
| UI | Settings → General → Session timeout (read‑only). |
| API | GET /rest/v1/settings (admin auth) → look for sessionTimeout. |
| CLI | n8n config get N8N_SESSION_TIMEOUT (requires n8n CLI). |
If the displayed value differs from your configuration, remember the precedence order: Docker env > .env > OS env.
4. Troubleshooting Unexpected Log‑outs
| Symptom | Likely Cause | Diagnostic Steps | Fix |
|---|---|---|---|
Log‑out after exactly 1 h, despite N8N_SESSION_TIMEOUT=86400 |
Variable not exported (wrong .env path) |
Exec into container: echo $N8N_SESSION_TIMEOUT |
Mount the correct .env (e.g., -v $(pwd)/.env:/home/node/.env). |
| Random log‑outs after minutes | Browser cookie blocked or SameSite policy | DevTools → Application → Cookies → n8n-session expiration |
Set SameSite=None; Secure in reverse proxy. |
| Log‑out after server restart | Session store is **in‑memory** and not persisted | Check N8N_SESSION_STORE env var |
Switch to Redis or DB store (N8N_SESSION_STORE=redis). |
| Users still logged out after extending timeout | Multiple n8n instances using different env files | Compare env vars across pods/containers | Centralise config via ConfigMap/Secret; redeploy uniformly. |
EEFA warning: In‑memory stores in multi‑node deployments cause session loss on any pod restart. Use Redis or a DB‑backed store for production.
5. Best Practices & Security Considerations
- Set the minimum viable timeout – 8 h for most teams, 24 h for 24/7 operations.
- Enable “Remember me” for API users to avoid long‑lived cookies.
N8N_BASIC_AUTH_ACTIVE=true N8N_BASIC_AUTH_USER=admin N8N_BASIC_AUTH_PASSWORD=strongpassword N8N_JWT_EXPIRES_IN=31536000 # 1 year (refresh token)
- Lock down the session cookie in your reverse proxy.
proxy_cookie_path / "/; HttpOnly; Secure; SameSite=Strict";
- Audit session duration quarterly – shorter windows reduce risk if a cookie is compromised.
6. Frequently Asked Questions
| Question | Answer |
|---|---|
| Can I set different timeouts per user role? | n8n does not support role‑based session TTL out of the box. You’d need custom middleware or a proxy that rewrites the Set-Cookie header per user. |
| Does increasing the timeout affect workflow execution time? | No. Session timeout only governs UI authentication. Workflow execution uses its own EXEC_TIMEOUT setting. |
| Will changing the timeout require users to log in again? | Yes – the current session cookie is invalidated on restart. Notify users of a brief forced re‑login. |
| Is the timeout “sliding” (reset on activity)? | n8n’s built‑in handling does reset the expiry on each request, but the maximum lifetime is still capped by N8N_SESSION_TIMEOUT. No extra configuration needed. |
Conclusion
Extending N8N_SESSION_TIMEOUT to a value that matches your team’s workflow cadence eliminates the frustrating, automatic log‑outs caused by the default 1‑hour limit. Implement the change via .env, Docker‑Compose, or Helm, then verify through the UI, API, or CLI. Remember to pair a longer timeout with hardened cookie settings and, for production clusters, a persistent session store (Redis or DB). This balanced approach preserves usability while keeping the attack surface under control, ensuring a smooth, secure n8n experience in real‑world deployments.
