VPS वर n8n ऑफलाइन का होते? चार कारणे आणि उपाय

n8n ऑफलाइन का होत राहते: चार बिघाड, एकच लक्षण

"n8n ऑफलाइन होत राहते" हे चार वेगवेगळ्या बिघाडांसाठी वापरलेले एकच वाक्य आहे आणि प्रत्येकासाठी वेगळा उपाय आवश्यक असतो. कंटेनर सामान्यपणे चालू असताना editor मध्ये connection lost बॅनर दिसतो. कंटेनर स्वतःहून पुन्हा सुरू होतो. जास्त memory वापरल्यामुळे kernel Node.js process बंद करतो. किंवा process मध्ये कोणतीही समस्या नसते आणि सक्रिय workflow प्रत्यक्षात कधीच सुरू होत नाही. चुकीची setting बदलल्यास तुम्हाला नसलेल्या समस्येवर संपूर्ण weekend खर्च होईल.

त्यामुळे कोणती समस्या आहे हे configuration ला हात लावण्यापूर्वी निश्चित करा. n8n एकाच Node.js process म्हणून चालते आणि सामान्यतः एका Docker container मध्ये असते. त्याच्या पुढे TLS (transport layer security) समाप्त करणारा reverse proxy असतो. या प्रत्येक स्तरात वेगवेगळ्या प्रकारे बिघाड होतो आणि browser त्या सर्वांसाठी एकच संदेश दाखवतो.

या क्रमाने निदान करा

VPS (virtual private server) वर या commands चालवा आणि तुमच्या स्वतःच्या machine ने दाखवलेल्या values वाचा. त्या values forum thread मधील numbers शी compare करू नका. येथे महत्त्वाच्या असलेल्या values तुमच्या box चे वर्णन करतात, दुसऱ्या कोणाच्या box चे नाही.

docker ps -a --filter name=n8n
docker logs --tail 200 --timestamps n8n
docker inspect n8n | grep -iE 'Status|Running|RestartCount|OOMKilled|ExitCode'
docker stats --no-stream

docker ps -a मधील STATUS column container किती वेळेपासून त्याच्या सध्याच्या state मध्ये आहे ते सांगतो. तुमची problem कधी सुरू झाली त्या वेळेशी त्याची तुलना करा. banner दिसण्याच्या बराच आधीपासून container up असेल, तर n8n कधीच offline झालेले नाही. बिघाड browser आणि backend यांच्यातील connection मध्ये आहे. हा websocket path पुढील section मध्ये समजावला आहे.

RestartCount Docker ने या container ला किती वेळा restart केले आहे ते दाखवतो. ही number लिहून ठेवा, एक minute थांबा आणि ती पुन्हा वाचा. तुम्ही पाहत असताना number वाढत असेल, तर तो restart loop आहे. प्रत्येक restart च्या अगोदरच्या log lines मध्ये कारण असते.

OOMKilled हा true किंवा false flag आहे. True म्हणजे memory limit ओलांडल्यामुळे Linux kernel ने process kill केला. ही limit container ची स्वतःची किंवा संपूर्ण machine ची असू शकते. हा एकच field memory kill आणि इतर सर्व प्रकारच्या exit मध्ये फरक करतो. म्हणून अंदाज करण्यापूर्वी तो वाचा.

ExitCode मध्ये container शेवटच्या वेळी ज्या value सह exit झाला ती value असते. प्रत्येक code चा अर्थ लक्षात ठेवण्याची गरज नाही. तुमची value वाचा आणि त्याच timestamp पासून docker logs चा शेवटचा भाग वाचा. Log tail आणि out of memory flag एकत्रितपणे काय घडले ते सांगतात. मात्र त्यांपैकी कोणत्याही एका गोष्टीवरून चुकीचा निष्कर्ष निघू शकतो.

docker stats सध्याचा memory use आणि लागू असलेली limit शेजारी दाखवतो. तो दुसऱ्या terminal मध्ये सुरू ठेवा, बिघाड करणारा workflow trigger करा आणि failure होत असताना number कशी बदलते ते पाहा.

कनेक्शन तुटल्याचा बॅनर सहसा तुमच्या reverse proxy मुळे दिसतो

n8n editor backend कडे एक दीर्घकाळ सुरू ठेवलेले push connection उघडे ठेवतो, त्यामुळे execution ची प्रगती canvas वर stream करता येते. डीफॉल्टनुसार ते connection WebSocket असते. ते निवडण्यासाठी N8N_PUSH_BACKEND वापरले जाते आणि त्याचे डीफॉल्ट मूल्य websocket आहे. WebSocket ची सुरुवात Connection: Upgrade आणि Upgrade: websocket headers असलेल्या सामान्य HTTP request ने होते. Server 101 Switching Protocols असे उत्तर देतो. त्यानंतर दोन्ही बाजू एकाच TCP socket चा दोन्ही दिशांनी वापर करतात.

ही प्रक्रिया दोन कारणांमुळे खंडित होऊ शकते. दोन्ही कारणे n8n ऐवजी proxy मध्ये असतात. Proxy upstream कडे HTTP/1.0 वापरतो किंवा upgrade headers काढून टाकतो. त्यामुळे upgrade होत नाही आणि editor सतत पुन्हा connect होत राहतो. किंवा upgrade यशस्वी होते, पण नंतर proxy socket बंद करतो. कारण त्या socket वर काही काळ संदेश नसल्यास WebSocket idle connection सारखा दिसतो. दोन्ही परिस्थितींमध्ये container निरोगी असतो. बॅनरचा अर्थ browser चे channel तुटले आहे, एवढाच असतो.

काहीही बदल करण्यापूर्वी browser मध्ये याची खात्री करा. Developer tools उघडा, Network tab वर जा, WS वर filter लावा आणि editor reload करा. Push request ने 101 Switching Protocols पर्यंत पोहोचून उघडे राहिले पाहिजे. Push request ला सामान्य status code मिळत असल्यास किंवा ती दर काही सेकंदांनी पुन्हा दिसत असल्यास समस्या proxy मध्ये आहे.

editor जोडलेले ठेवणाऱ्या nginx settings

nginx ला सांगितल्याशिवाय तो upgrade forward करत नाही. proxy_pass default ने backend शी HTTP/1.0 द्वारे संवाद साधतो आणि Connection व Upgrade हे hop-by-hop headers आहेत, जे nginx पुढे पाठवताना काढून टाकतो. त्यामुळे दोन्ही पुन्हा जोडावे लागतात. map block http context मध्ये असावा; तो server च्या आत नसावा. खालील उर्वरित server block परिचित नसल्यास, nginx server block मधील प्रत्येक line चे स्पष्टीकरण प्रत्येक directive काय करते हे स्पष्ट करते.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    http2 on;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

proxy_read_timeout हीच ती line आहे जी अनेकदा वगळली जाते. तिचे default value 60 seconds आहे आणि ते upgraded WebSocket वरही लागू होते. त्यामुळे शांत instance वर उघडा ठेवलेला editor tab शेवटचा message गेल्यानंतर सुमारे एक मिनिटाने connection गमावतो. हे value वाढवल्याने बराच वेळ उघडा ठेवलेल्या tab वर परतल्यावर दिसणारा banner दूर होतो.

sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | grep -iE 'proxy_http_version|upgrade|proxy_read_timeout'

nginx -T एका file ऐवजी पूर्ण running configuration दाखवते. त्यामुळे तुमचा बदल प्रत्यक्षात load झाला आहे हे सिद्ध होते. include line न उचलणाऱ्या file मध्ये configuration असल्यास, योग्य fix केल्यानंतरही काहीच बदल झालेला दिसत नाही.

यानंतर n8n ला ते proxy मागे चालत असल्याचे सांगा, कारण ते या values वरून URLs तयार करते.

environment:
  - N8N_HOST=n8n.example.com
  - N8N_PROTOCOL=https
  - N8N_PORT=5678
  - N8N_PROXY_HOPS=1
  - N8N_WEBHOOK_URL=https://n8n.example.com/

N8N_PROXY_HOPS चे default value 0 आहे. याचा अर्थ n8n connection करणारा address हा client address मानतो आणि X-Forwarded-For कडे दुर्लक्ष करतो. Container च्या पुढे असलेल्या proxies ची संख्या येथे सेट करा. August 2026 पर्यंत N8N_WEBHOOK_URL हे current name आहे आणि जुने WEBHOOK_URL अजूनही काम करते; मात्र startup वेळी deprecation warning दाखवते.

Traefik WebSocket forward करतो, त्यानंतर timeout होतो

Traefik कोणतेही middleware आणि अतिरिक्त labels नसतानाही WebSocket upgrade forward करतो. त्यामुळे हे banner दिसणाऱ्या Traefik वापरकर्त्याला सहसा header नसल्याची समस्या नसते, तर timeout होत असतो. यासाठी entryPoint वरील settings वापरल्या जातात. August 2026 पर्यंत Traefik v3 मध्ये, idleTimeout चे default मूल्य 180 seconds आणि readTimeout चे default मूल्य 60 seconds आहे.

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        idleTimeout: 3600s

Caddy reverse_proxy मध्ये upgrade आपोआप हाताळतो आणि त्यासाठी कोणत्याही directive ची गरज नसते. Proxy वर अजिबात बदल करता येत नसल्यास, कारण त्याचे व्यवस्थापन दुसरी व्यक्ती करत असल्यास, push channel N8N_PUSH_BACKEND=sse ने बदला. SSE (server-sent events) हा उघडा ठेवलेला सामान्य HTTP response असतो. त्यामुळे upgrades नाकारणाऱ्या proxy मधूनही तो सुरू राहतो. मात्र अतिशय कमी idle timeout असल्यास तोही खंडित होतो. Proxy निवडणे हा स्वतंत्र निर्णय आहे. nginx, Caddy आणि Traefik ची तुलना यापैकी प्रत्येकाची व्यवस्थापनासाठी लागणारी किंमत स्पष्ट करते.

कंटेनर खरोखरच पुन्हा सुरू होत असेल

RestartCount वाढत असेल, तर कंटेनरमध्ये बिघाड झाला आहे आणि Docker तो पुन्हा सुरू करत आहे. प्रत्येक restart ची वेळ log मधील timestamps शी जुळवा आणि त्याच्या लगेच आधी काय घडले ते वाचा. जवळजवळ सर्व प्रकरणांसाठी चार कारणे पुरेशी असतात: startup थांबवणारी configuration error, n8n पोहोचू न शकणारा database, सुरू झाल्यानंतर होणारा crash आणि memory kill.

सुरुवात volume पासून करा, कारण permissions हा सहसा लक्षात न येणारा मुद्दा असतो. अधिकृत image unprivileged user node म्हणून चालते आणि आपला data /home/node/.n8n मध्ये ठेवते. root ने तयार केलेला bind mount त्या user कडून writable नसतो. त्यामुळे process प्रत्येक वेळी startup वेळीच बंद पडतो आणि restart policy ही समस्या loop मागे लपवते.

docker compose config
docker run --rm -it --entrypoint sh docker.n8n.io/n8nio/n8n -c 'id'
docker exec n8n ls -ld /home/node/.n8n

Named volume ही समस्या पूर्णपणे टाळतो, कारण Docker तो योग्य ownership सह तयार करतो. Bind mount आवश्यक असल्यास, पहिल्या command ने दाखवलेल्या numeric user id वर host directory ला chown करा. Host आणि container मधील ownership mapping एकदा समजून घेणे उपयुक्त ठरते. ही images files कोणत्या user कडून लिहिल्या जातील हे कशा ठरवतात, याचे स्पष्टीकरण PUID आणि PGID वरील स्पष्टीकरण येथे आहे.

क्रॅशसारखे दिसणारे out-of-memory kill

n8n प्रक्रियेवर दोन स्वतंत्र memory ceiling लागू असतात आणि ते वेगवेगळ्या प्रकारे अपयशी ठरतात. Container control group limit kernel लागू करतो: ती मर्यादा ओलांडल्यावर प्रक्रिया तात्काळ kill केली जाते, काहीही लिहिण्याची संधी मिळत नाही आणि OOMKilled चे मूल्य true असते. V8 heap limit Node.js अंतर्गत लागू करतो: ती मर्यादा ओलांडल्यावर Node stack trace सह heap error दाखवतो आणि स्वतःहून बंद होतो, त्यामुळे OOMKilled चे मूल्य false असते. Browser मधून हे दोन्ही प्रकार एकसारखे दिसतात. docker inspect मध्ये ते केवळ एका field मुळे वेगळे ओळखता येतात.

Node heap ceiling container limit पेक्षा कमी ठेवा. Heap ceiling या दोन्हीपैकी जास्त असल्यास V8 kernel हस्तक्षेप करण्याच्या बिंदूपलीकडेही allocation करत राहतो. त्यामुळे त्याचा garbage collector स्वतःच्या मर्यादेपर्यंत पोहोचत नाही आणि log वाचता न येणारे अधिक कठोर अपयश नेहमी दिसते.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - NODE_OPTIONS=--max-old-space-size=<MiB, below the container limit>
    deploy:
      resources:
        limits:
          memory: <your container limit>

तुमच्या VPS मध्ये प्रत्यक्ष उपलब्ध असलेल्या memory नुसार दोन्ही संख्या निवडा. Database, proxy आणि operating system साठी पुरेशी memory राखून ठेवा. docker stats --no-stream सध्याचा वापर लागू मर्यादेसोबत दाखवते. त्यामुळे तुम्ही लिहिलेली limit Docker ने लागू केलेली limit आहे का ते तपासता येते. अनेक limits सेट असल्यास त्यापैकी कोणती key लागू होते, हे Compose memory limits कशा लागू होतात येथे स्पष्ट केले आहे.

तुमच्या खाली साठणारा execution data

एक execution चालू असताना प्रत्येक node चे output साठवतो आणि n8n नंतर तो data जतन करतो. याचे दोन परिणाम होतात. एका run ची कमाल memory वापर त्या run मधून पाठवलेल्या सर्वात मोठ्या data batch वर ठरते. त्यामुळे एकाच वेळी दहा हजार rows हाताळणारा workflow आणि एका वेळी दोनशे rows हाताळणारा तोच workflow हे प्रत्यक्षात वेगळे programs आहेत. तसेच, काहीतरी तो data delete करेपर्यंत जतन केलेली copy वाढत राहते.

Pruning दुसरी समस्या हाताळते. August 2026 पर्यंत default settings मध्ये pruning enabled आहे, EXECUTIONS_DATA_MAX_AGE 336 hours (14 days) आणि EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000 वर सेट आहे. SQLite वापरणाऱ्या छोट्या VPS साठी ही values मोठ्या आहेत. अशा setup मध्ये एका file मध्ये सर्व data असतो आणि editor सेवा देणाऱ्या त्याच process ला तो read आणि write करावा लागतो.

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=72
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none ही अधिक आक्रमक setting आहे. ती debugging साठी failed executions ठेवते आणि successful executions हटवते. हा निर्णय जाणीवपूर्वक घ्या. कारण error न दाखवता चुकीचा output तयार करणारा workflow नंतर तपासण्यासाठी कोणताही data ठेवणार नाही. Pruning मध्ये rows आधी deleted म्हणून mark केल्या जातात आणि पुढील pass मध्ये हटवल्या जातात. तसेच SQLite मोकळी झालेली pages पुन्हा वापरते; त्या operating system कडे परत करत नाही. त्यामुळे setting बदलल्यानंतर disk वरील file लगेच लहान होत नाही.

जतन केलेल्या एकूण data ऐवजी peak कमी करायचा असल्यास, प्रत्येक run मध्ये कमी data हलवा. मोठी jobs parent कडे small results परत करणाऱ्या sub-workflows मध्ये विभागा, Loop Over Items node वापरून batching करा आणि संपूर्ण datasets Code node मध्ये ठेवू नका.

बायनरी फाइल्सनी मेमरीमधून जाऊ नये

N8N_DEFAULT_BINARY_DATA_MODE चे default मूल्य default आहे. त्यामुळे चालू execution मधील बायनरी डेटा मेमरीमध्येच ठेवला जातो. एखादा node डाउनलोड करत असलेली प्रत्येक फाइल आणि पुढील node कडे पाठवली जाणारी प्रत्येक प्रत run संपेपर्यंत तिथेच राहते. काही मोठे attachments आणणारा एक workflow अशा मर्यादेपेक्षा process पुढे नेऊ शकतो, जिच्याजवळ सामान्य JSON कामकाज कधीच पोहोचत नाही. त्यामुळे crash ठरावीक workflow नंतर होतो; ठरावीक वेळेनंतर नाही.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem वापरल्यास बायनरी डेटा N8N_BINARY_DATA_STORAGE_PATH अंतर्गत लिहिला जातो. हे स्थान default ने n8n user folder मध्ये असते आणि त्यामुळे डेटा इतर सर्व गोष्टींसोबत त्याच volume वर साठवला जातो. हे setting बदलण्यापूर्वी volume मध्ये पुरेशी जागा आहे का ते तपासा. N8N_PAYLOAD_SIZE_MAX incoming webhook payload ची कमाल मर्यादा MiB (mebibytes) मध्ये ठरवते आणि default मूल्य 16 आहे. ही मर्यादा वाढवल्यास मोठ्या requests स्वीकारल्या जातात. त्यासाठी लागणारी अतिरिक्त memory cost तुम्ही स्वीकारत आहात.

सर्व्हरवर चालणाऱ्या इतर सर्व गोष्टी त्याच RAM साठी स्पर्धा करतात. database container जोडल्यापासून OOM kills सुरू झाले असतील, तर database Docker मध्ये किंवा host वर चालवणे हा आता तुम्ही स्वीकारत असलेला trade-off आहे.

रीस्टार्ट धोरण आणि रीबूटनंतर पुन्हा सुरू होणे

रीस्टार्ट धोरण नसलेला कंटेनर बंद झाल्यानंतर तसाच बंद राहतो. Host रीबूट झाल्यानंतरही तो पुन्हा सुरू होत नाही. restart: unless-stopped दोन्ही परिस्थितींमध्ये तो पुन्हा सुरू करते आणि तुम्ही हाताने थांबवलेल्या कंटेनरचा आदर करते. restart: always तुम्ही जाणूनबुजून थांबवलेला कंटेनरही पुन्हा सुरू करते, मात्र Docker पुढच्या वेळी सुरू झाल्यानंतर.

n8n एक health endpoint उपलब्ध करून देते. त्याचे नाव N8N_ENDPOINT_HEALTH आहे आणि त्याचे default मूल्य healthz आहे. तुमच्या instance वर path योग्य आहे याची खात्री करण्यासाठी प्रथम तो host वरून तपासा.

curl -fsS http://127.0.0.1:5678/healthz
docker exec n8n which wget curl
sudo systemctl is-enabled docker

फक्त healthcheck असल्याने काहीही आपोआप पुन्हा सुरू होत नाही. Compose कंटेनरला unhealthy म्हणून चिन्हांकित करते आणि त्यानंतर पुढील कृती करत नाही. त्यामुळे healthcheck चा परिणाम होण्यासाठी त्यासोबत restart policy किंवा बाह्य watcher आवश्यक आहे. प्रत्यक्ष कृती करणारा healthcheck लिहिणे आणि रीबूटनंतर stack पुन्हा सुरू होईल अशी रचना करणे या दोन्ही बाबी स्पष्ट करतात.

n8n व्यवस्थित असतानाही कार्यप्रवाह कधीच चालू होत नाही

यामध्ये कोणताही बॅनर दिसत नाही आणि रीस्टार्टही होत नाही. कंटेनर सुरू आहे, editor कार्यरत आहे आणि अपेक्षित run executions यादीत दिसत नाही. यामागे प्रामुख्याने चार कारणे असतात.

• कार्यप्रवाह active नाही. Schedule Trigger फक्त production path वर चालतो. त्यामुळे canvas मध्ये त्याची चाचणी केल्यास कोणतेही schedule तयार होत नाही.
• timezone तुमच्या स्थानिक timezone नुसार सेट केलेला नाही. GENERIC_TIMEZONE चे default मूल्य America/New_York आहे. त्यामुळे GENERIC_TIMEZONE आणि TZ मध्ये तुमचा timezone सेट करेपर्यंत 09:00 साठी सेट केलेले schedule त्या timezone मधील 09:00 वाजता चालते.
• downtime नंतर सुटलेली वेळ भरून काढली जात नाही. n8n सुरू होताना triggers register होतात. त्यामुळे container restart होत असताना schedule ची वेळ झाल्यास ते उशिरा चालत नाही. startup नंतरची पुढील निर्धारित वेळ आल्यावरच पुढील run होतो.
• कार्यप्रवाह आपोआप deactivated झाला आहे. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED हे default ने बंद असते. ते सुरू असल्यास वारंवार crash होणारा workflow unpublished केला जातो. त्यानंतर तो कधीही activate न केलेल्या workflow सारखाच दिसतो.

Executions यादी उघडा आणि त्या workflow वर filter लावा. अयशस्वी झालेली entry असल्यास समस्या workflow मध्ये आहे. त्याच server वर चालणाऱ्या दुसऱ्या सेवेला विनंती करताना 429 error मिळाला असल्यास limit n8n ची नसून त्या सेवेची आहे. SearXNG 429 वरील मार्गदर्शक त्या सेवेचा स्वतःचा rate limiter तुमच्या server चा IP block करणाऱ्या engines पासून कसा वेगळा ओळखायचा हे दाखवते. कोणतीही entry नसल्यास समस्या trigger मध्ये आहे. अशा वेळी वरील चार कारणे तपासा.

प्रथम काय बदलावे

1. कोणतीही फाइल संपादित करण्यापूर्वी आपल्या container मधील STATUS, RestartCount आणि OOMKilled स्वतः वाचा.
2. container कधीही बंद झाला नसेल, तर proxy upgrade headers आणि idle timeout दुरुस्त करा.
3. OOMKilled सत्य असल्यास, जाणीवपूर्वक निवडलेली container limit सेट करा, Node heap ceiling तिच्यापेक्षा कमी ठेवा आणि binary data filesystem वर हलवा.
4. काहीही कार्यान्वित झाले नसेल, तर workflow सक्रिय आहे का आणि instance timezone आपला आहे का ते तपासा.

यातील बहुतांश configuration कार्यरत install वर एकदाच सेट करून नंतर बदलण्याची गरज नसते. तो install अजून तयार करत असाल, तर HTTPS सह Docker वर n8n चालवण्याचे मार्गदर्शन हे या settings साठीचे मूलभूत आधार आहे.

FAQ

n8n कंटेनर चालू असताना editor मध्ये connection lost संदेश का दिसतो?

Execution चा progress पाठवण्यासाठी editor WebSocket connection खुली ठेवतो. तुमचा reverse proxy Connection: Upgrade आणि Upgrade: websocket headers forward करत नसेल किंवा upstream साठी HTTP/1.1 वापरत नसेल, तर upgrade पूर्ण होत नाही. त्यामुळे n8n व्यवस्थित असतानाही browser सतत reconnect करत राहतो. nginx मध्ये proxy_http_version 1.1 आणि दोन्ही proxy_set_header lines आवश्यक आहेत. तसेच default 60 seconds पेक्षा जास्त कालावधीचा proxy_read_timeout आवश्यक आहे, जेणेकरून शांत tab बंद होणार नाही. तुम्ही संपादित केलेली file नव्हे, तर चालू configuration sudo nginx -T वापरून तपासा.

out of memory kill आणि सामान्य crash यांमध्ये फरक कसा ओळखायचा?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' चालवा आणि OOMKilled flag वाचा. True असल्यास memory limit ओलांडल्यामुळे kernel ने process बंद केला आहे. Container log मध्ये उपयुक्त माहिती नसेल, कारण process ला काही लिहिण्याची संधीच मिळाली नाही. docker logs च्या शेवटी heap error आणि stack trace सह False असल्यास Node.js ने स्वतःची V8 heap ceiling गाठली आणि process स्वतः बंद झाला. NODE_OPTIONS=--max-old-space-size तुमच्या container limit पेक्षा कमी ठेवा. त्यामुळे दुसऱ्या प्रकारचे failure मिळेल आणि त्यात पुरावे उपलब्ध राहतात.

execution data prune केल्याने disk space लगेच मोकळी होते का?

नाही. EXECUTIONS_DATA_PRUNE जुन्या executions deletion साठी चिन्हांकित करते आणि नंतरच्या pass मध्ये ती हटवली जातात. हा pass EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL ने ठरवलेल्या schedule नुसार चालतो. SQLite मध्ये file मोकळी झालेली pages filesystem ला परत देण्याऐवजी पुन्हा वापरते. त्यामुळे rows हटवल्यानंतर काही काळ disk वरील size तसाच राहतो. EXECUTIONS_DATA_MAX_AGE आणि EXECUTIONS_DATA_PRUNE_MAX_COUNT तुमच्या system ला योग्य अशा values वर सेट करा. त्यानंतर लगेच नव्हे, तर पुढील दिवशी पुन्हा तपासा.

n8n restart होत असताना माझा scheduled workflow का चालला नाही?

Process सुरू होताना n8n triggers register करते. बंद असताना due झालेल्या schedules ती पुन्हा चालवत नाही. त्यामुळे restart loop मध्ये catch-up runs चा burst न होता शांतता दिसते. Startup नंतरची पुढील execution ही पुढील due time ला होते. चुकवता न येणाऱ्या runs आवश्यक असल्यास, webhook ला request करणाऱ्या external caller कडून workflow चालवा. त्यामुळे retry logic n8n च्या बाहेर राहते.

healthcheck प्रतिसाद देणे थांबवल्यावर n8n restart करेल का?

आपोआप नाही. Compose healthcheck फक्त container ला healthy किंवा unhealthy म्हणून चिन्हांकित करते. Restart करणे हे restart policy चे काम आहे. त्यामुळे container exit झाल्यानंतर restart: unless-stopped तो पुन्हा सुरू करते. Docker service enabled असल्यास host reboot नंतरही ती container पुन्हा सुरू करते. sudo systemctl is-enabled docker वापरून याची खात्री करा. फक्त unhealthy स्थितीवर कृती करायची असल्यास, Docker च्या बाहेरील watcher आवश्यक आहे. तो status वाचून service restart करतो.