VPS वर n8n offline का होते? चार कारणे ओळखा

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

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

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

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

VPS (virtual private server) वर या commands चालवा आणि तुमच्या स्वतःच्या machine ने दाखवलेली values वाचा. Forum thread मधील numbers शी त्यांची तुलना करू नका. येथे महत्त्वाच्या 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 मध्ये किती वेळ आहे ते सांगतो. तुमची समस्या सुरू झालेल्या वेळेशी त्याची तुलना करा. Banner दिसण्याच्या बराच आधीपासून container up असेल, तर n8n कधीही offline झालेले नाही. तुमच्या browser आणि backend मधील connection मध्ये बिघाड झाला आहे. पुढील section मध्ये websocket path चे वर्णन केले आहे.

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 चा अर्थ पाठ करण्याची गरज नाही. तुमचा code वाचा आणि त्याच timestamp वरील docker logs चा शेवटचा भाग वाचा. Log tail आणि out of memory flag एकत्रितपणे काय घडले ते सांगतात. यांपैकी कोणत्याही एका value वरच अवलंबून राहिल्यास चुकीचा निष्कर्ष निघू शकतो.

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

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

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

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

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

संपादकाचे कनेक्शन टिकवून ठेवणाऱ्या nginx सेटिंग्ज

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

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 हीच ती ओळ आहे जी अनेकदा वगळली जाते. तिचे डीफॉल्ट मूल्य 60 seconds आहे आणि ते upgraded WebSocket वरही लागू होते. त्यामुळे शांत instance वर उघडा ठेवलेला editor tab शेवटचा message गेल्यानंतर सुमारे एक मिनिटाने कनेक्शन गमावतो. हे मूल्य वाढवल्याने बराच वेळ उघडा ठेवलेल्या tab वर परतल्यावर दिसणारा banner नाहीसा होतो.

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

nginx -T एका file ऐवजी संपूर्ण चालू configuration दाखवते. त्यामुळे तुमचा बदल प्रत्यक्षात load झाला आहे हे सिद्ध होते. include line ज्या configuration file ला वाचत नाही, त्या 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 चे डीफॉल्ट मूल्य 0 आहे. याचा अर्थ n8n कनेक्ट होणारा address हा client address मानते आणि X-Forwarded-For कडे दुर्लक्ष करते. Container च्या समोर असलेल्या proxies ची संख्या येथे सेट करा. August 2026 पर्यंत N8N_WEBHOOK_URL हे सध्याचे नाव आहे आणि जुने WEBHOOK_URL अजूनही कार्य करते; मात्र startup वेळी deprecation warning दाखवते.

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

Traefik कोणतेही middleware किंवा अतिरिक्त labels नसतानाही WebSocket upgrade forward करतो. त्यामुळे हे banner दिसणारा Traefik वापरकर्ता सहसा missing header ऐवजी timeout ला सामोरा जात असतो. ही settings entryPoint वर असतात. 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 ची तुलना प्रत्येक proxy चालवण्यासाठी लागणारा खर्च स्पष्ट करते.

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

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

सर्वप्रथम volume तपासा, कारण permissions ही अनेकदा शांतपणे समस्या निर्माण करणारी बाब असते. Official 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 फाइल्स कोणत्या 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 शेजारी शेजारी दाखवते. त्यामुळे तुम्ही लिहिलेली limit Docker ने लागू केली आहे का ते तपासता येते. Compose memory limits कशा लागू केल्या जातात अनेक limits सेट केल्यावर कोणती key लागू होते हे स्पष्ट करते.

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

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

दुसरी समस्या pruning मुळे हाताळली जाते. August 2026 पर्यंत defaults म्हणजे pruning enabled, EXECUTIONS_DATA_MAX_AGE 336 hours (14 days) आणि EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000. SQLite वापरणाऱ्या छोट्या VPS साठी ही मूल्ये मोठी आहेत. अशा ठिकाणी सर्व data एका file मध्ये असतो आणि editor serve करणाऱ्या त्याच 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 ही aggressive setting आहे. ती debugging साठी failed executions ठेवते आणि successful executions delete करते. हा निर्णय जाणीवपूर्वक घ्या. कारण एखाद्या workflow ने error न दाखवता चुकीचे output तयार केले, तर तपासणीसाठी काहीही उरणार नाही. Pruning प्रथम rows deleted म्हणून mark करते आणि नंतरच्या pass मध्ये त्या remove करते. तसेच SQLite मोकळी झालेली pages पुन्हा वापरते; त्या operating system कडे परत करत नाही. त्यामुळे setting बदलल्यानंतर disk वरील file लगेच लहान होत नाही.

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

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

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

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

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

त्या मशीनवरील इतर सर्व सेवा त्याच 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 सुरळीत असताना workflow कधीच चालू होत नाही

यामध्ये कोणताही banner दिसत नाही आणि restart देखील होत नाही. container सुरू आहे, editor कार्यरत आहे, पण अपेक्षित run executions list मध्ये दिसत नाही. यामागे बहुतेक वेळा खालील चार कारणे असतात.

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

executions list उघडा आणि त्या workflow नुसार filter करा. failed entry असल्यास समस्या workflow मध्ये आहे. कोणतीही entry नसल्यास समस्या trigger मध्ये आहे. अशा वेळी वरील चार कारणे तपासा.

पहिल्यांदा काय बदलावे

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

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

FAQ

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

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 timeout सेट करा, जेणेकरून शांत tab connection तोडणार नाही. तुम्ही संपादित केलेली 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 साठी चिन्हांकित करते आणि EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL ने निश्चित केलेल्या schedule नुसार नंतरची प्रक्रिया त्या delete करते. SQLite मध्ये file मोकळी झालेली pages filesystem कडे परत देण्याऐवजी पुन्हा वापरते. त्यामुळे rows delete झाल्यानंतर काही काळ disk वरील size तसाच राहतो. EXECUTIONS_DATA_MAX_AGE आणि EXECUTIONS_DATA_PRUNE_MAX_COUNT तुमच्या system साठी योग्य values वर सेट करा. त्यानंतर लगेच नव्हे, तर पुढील दिवशी पुन्हा तपासा.

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

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

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

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