I see the same problems again and again when people ask me about n8n setup issues. The web UI will not load. Workflows fail to trigger. Nodes hang during execution. Credentials disappear after a restart. The editor times out. That usually means the install or the config is off. Note what fails, and when. That cuts out a lot of guesswork.
Read the errors and keep the exact text. Look for HTTP 500, 502 or 504. Watch for ECONNREFUSED, ENOTFOUND, database connection errors, or Rate limit exceeded messages from external APIs. Authentication failures often show as 401 or 403 at node runtime. Copy the message and timestamp before you start changing things.
Check CPU and memory spikes when workflows run. Look at queue lengths or backlog in the queue driver you use. Slow disk I/O or high swap use is a red flag. If workers keep dying or restarting, that points to stability or resource limits. Watch response time for the UI and execution duration for individual nodes.
n8n runs on Node.js, so check that the Node version sits within the supported range. You need a database: SQLite is fine for small tests, Postgres makes more sense for production. You also need a process manager, whether that is systemd, PM2, or Docker. If workflow history is heavy, storage with decent IOPS matters. Match the setup to the load you actually expect.
Check the environment variables: N8N_HOST, N8N_PORT, DB_TYPE, DB_POSTGRESDB_HOST, and the rest. If you use basic auth or JWT, verify the credentials and token lifetimes. Check NODE_ENV too. Mis-set variables are a common source of n8n setup problems. Keep one source of truth for the config, like an env file or a Docker Compose file.
Ports need to be open between n8n, the database, and any API endpoints it talks to. If it sits behind a reverse proxy, check the proxy headers and timeout values. TLS termination should forward X-Forwarded-For and X-Forwarded-Proto if you depend on them. Firewalls, DNS mistakes, and NAT all break connectivity in their own charming way.
Likely causes
A wrong env var, a forgotten host, or the wrong database URL will break things quietly. Common errors include pointing to SQLite in production or leaving temporary tokens enabled. Bad proxy settings also cause UI and webhook issues.
Running an unsupported Node or Postgres version causes runtime errors. Some n8n nodes depend on specific Node features. Check the version matrix before an upgrade. If you upgraded n8n and broke workflows, a newer version may have changed node behaviour.
Not enough RAM, CPU contention, or slow disk will make executions fail or time out. Running several heavy workflows on a small VM will exhaust resources fast. Container setups can hide limits, so check cgroup quotas and host metrics.
Commands to check status
Use the process manager tools:
- systemd:
sudo systemctl status n8n - Docker:
docker ps docker logs - PM2:
pm2 status pm2 logs
Check database connectivity with psql or a MySQL client. Test port reachability with curl or nc. These commands tell you whether the services are running and reachable.
Tail the n8n logs and look for stack traces and repeated warnings. Match timestamps to failed workflow runs. Look at the database logs for connection errors. If the logs are noisy, increase the log level to debug for a short period. Keep the exact error messages for each failing window.
From the n8n host, curl the external APIs used by your workflows. Test webhook endpoints from the public internet if you need to. Use traceroute for odd routing problems. If webhooks fail, check that the reverse proxy forwards requests and that any authentication headers still reach n8n.
Step-by-step resolution
- Reproduce the failure in a controlled way. Note the exact steps.
- Check the n8n process and logs for related errors.
- Verify database connectivity and credentials.
- Check environment variables and proxy settings.
- Free resources: stop non-essential services, increase memory or CPU as a temporary test.
- Retry the workflow or web UI.
After each step, check whether the error changes. If it does, write down what changed the behaviour.
Fix the environment variables first. For reverse proxies, set the right headers and raise timeout values if long-running workflows hit proxy limits. Move from SQLite to Postgres if you need concurrent access or better stability. Set EXECUTIONS_PROCESS to main or own depending on the isolation you want.
If the install is corrupt or broken after several changes, do a clean redeploy:
- Export workflow JSON and credentials.
- Stop the service and back up the database.
- Remove old containers or binaries.
- Reinstall the n8n version that matches your workflows.
- Import workflows and credentials.
Test imports in a staging instance first. Check the exported data before you delete anything.
Confirm it's fixed
Run the failing workflows. Watch the logs while they run. Use curl to hit the UI and webhook endpoints. Check that database connections stay active and that the errors no longer appear. Make sure node executions complete without new error codes.
Set up simple alerts for process uptime, CPU, memory, and database connection errors. Use basic dashboards that show execution success rate and queue depth. A sudden rise in retries or failures should trigger an alert and a look at the logs.
Keep screenshots or logs in one place. I use a single issue tracker or channel so reports do not get split across half a dozen places.
Prevent it happening again
Use a dedicated Postgres for production. Keep secrets out of version control. Pin n8n and Node.js versions in your deployment config. Run a staging instance and test upgrades there before touching production. Use health checks and a process manager to restart failed services.
Schedule backups of workflows and the database. Rotate logs and prune execution history you do not need. Review resource usage monthly. Rehearse restores so the backups are worth something.
Document the exact deploy steps, environment variables, and backup procedure.
Keep a short troubleshooting cheat sheet with common errors and fixes. Record the version matrix you tested against. Good documentation cuts debugging time.
I keep my notes blunt and focused so I can reproduce fixes quickly. That stops me going round in circles.
