Server incidents, root causes, and resolutions
- Chatbot on maxshipping.info not responding
- Webhook requests timing out (HTTP exit code 28)
- N8N logs showed “Last session crashed” and “Database connection timed out”
- DNS check: max.lifeonroatan.net resolved to 139.59.54.90 — server reachable via SSH but not HTTP
- Port scan: Ports 80 and 443 closed externally, port 22 open
- On-server check: Caddy listening on 80/443, responding locally — confirmed external block
- OS firewall: UFW inactive, iptables INPUT policy ACCEPT with no rules
- Server IP mismatch: Actual public IP was 68.183.83.159, DNS pointed to 139.59.54.90 (both associated with droplet)
- Memory: 1.8 GB of 1.9 GB used, zero swap — server nearly OOM
- Containers: 10 running containers consuming ~1.3 GB total
- DigitalOcean cloud firewall blocking ports 80 and 443 inbound (SSH was allowed)
- Memory exhaustion causing N8N crashes and database connection timeouts
- Stopped non-essential containers (n8n, n8n-dev1, nocodb, portainer) — freed ~866 MB
- Added 1 GB swap file at /swapfile (persistent via /etc/fstab)
- Restarted
max container — “Max Chatbot Live” workflow activated
- DO cloud firewall updated to allow TCP 80 and TCP 443
- Chatbot confirmed working — webhook responding correctly
| Metric |
Before |
After |
| Free memory |
105 MB |
~900 MB |
| Swap |
0 |
1 GB |
| Running containers |
10 |
6 |
| Chatbot status |
Down |
Working |
- DigitalOcean cloud firewalls operate at the network level, invisible from inside the server (UFW/iptables won’t show them)
- A 1.9 GB server cannot run 4 N8N instances + NocoDB + PostgreSQL simultaneously
- Always check the DO firewall dashboard when ports are listening locally but unreachable externally
- Swap is essential on memory-constrained servers to prevent OOM crashes