VPS पर n8n offline क्यों हो जाता है? मुख्य कारण और समाधान

n8n के offline होने के चार कारण और एक लक्षण

"n8n keeps going offline" एक ऐसा वाक्य है जो चार अलग-अलग विफलताओं को दर्शाता है, और हर एक का समाधान अलग है। एडिटर में connection lost का बैनर दिखता है जबकि container सामान्य रूप से चल रहा होता है। container अपने आप restart हो जाता है। kernel, Node.js process को बहुत अधिक memory उपयोग करने के कारण kill कर देता है। या फिर process में कोई समस्या नहीं होती, लेकिन एक active workflow कभी trigger ही नहीं होता। गलत setting बदलने पर आप उस समस्या को सुलझाने में पूरा weekend बर्बाद कर देंगे जो वास्तव में थी ही नहीं।

इसलिए किसी भी configuration को बदलने से पहले यह पता लगाएँ कि आपको कौन सी विफलता का सामना करना पड़ रहा है। n8n एक single Node.js process के रूप में चलता है, आमतौर पर एक Docker container के अंदर, जो TLS (transport layer security) terminate करने वाले reverse proxy के पीछे होता है। इनमें से प्रत्येक layer अपने तरीके से विफल हो सकती है, और browser उन सभी के लिए एक ही संदेश दिखाता है।

इस क्रम में निदान करें

VPS (virtual private server) पर ये commands चलाएँ और अपनी मशीन द्वारा प्रिंट किए गए मानों को पढ़ें। उनकी तुलना किसी फ़ोरम थ्रेड के नंबरों से न करें। यहाँ जो मान मायने रखते हैं, वे आपके सर्वर के हैं, किसी और के नहीं।

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 कॉलम यह बताता है कि container अपनी वर्तमान स्थिति में कितनी देर से है। इसकी तुलना उस समय से करें जब आपकी समस्या शुरू हुई थी। यदि banner दिखाई देने से काफी पहले से container चल रहा है, तो n8n कभी offline नहीं हुआ। जो टूटा है वह आपके browser और backend के बीच का connection है, जो कि websocket path है और जिसे अगले भाग में कवर किया गया है।

RestartCount यह बताता है कि Docker ने इस container को कितनी बार restart किया है। नंबर नोट करें, एक मिनट प्रतीक्षा करें, फिर इसे दोबारा पढ़ें। यदि आपके देखते ही नंबर बढ़ रहा है, तो यह एक restart loop है, और प्रत्येक restart से ठीक पहले की log lines में इसका कारण मौजूद होता है।

OOMKilled एक true या false flag है। True का अर्थ है कि Linux kernel ने process को मार दिया है क्योंकि यह memory limit से बाहर चली गई थी, चाहे वह container की अपनी limit हो या पूरी मशीन की। यह अकेला field memory kill को बाकी सभी प्रकार के exit से अलग करता है, इसीलिए अनुमान लगाने से पहले आप इसे पढ़ते हैं।

ExitCode वह कोड है जिसके साथ आपका container आखिरी बार exit हुआ था। आपको यह याद रखने की आवश्यकता नहीं है कि प्रत्येक कोड का क्या अर्थ है। अपना कोड पढ़ें, फिर उसी timestamp से docker logs का अंत पढ़ें। log tail और out of memory flag मिलकर बताते हैं कि क्या हुआ था, और इनमें से कोई भी अकेला आपको गुमराह कर सकता है।

docker stats लागू limit के साथ-साथ live memory उपयोग दिखाता है। इसे दूसरे terminal में चलते रहने दें, वह workflow ट्रिगर करें जो चीजों को तोड़ता है, और देखें कि विफलता के समय नंबर क्या करता है।

Connection lost बैनर आमतौर पर आपके reverse proxy के कारण होता है

n8n editor backend के साथ एक long-lived push connection खुला रखता है ताकि वह execution progress को canvas पर stream कर सके। डिफ़ॉल्ट रूप से यह connection एक WebSocket होता है, जिसे N8N_PUSH_BACKEND चुनता है, और इसका डिफ़ॉल्ट मान websocket है। एक WebSocket सामान्य HTTP request के रूप में शुरू होता है जिसमें Connection: Upgrade और Upgrade: websocket headers होते हैं। सर्वर 101 Switching Protocols के साथ उत्तर देता है, और उसके बाद दोनों पक्ष एक ही TCP socket का उपयोग दोनों दिशाओं में करते हैं।

दो चीजें इसे बाधित करती हैं, और वे दोनों n8n के बजाय proxy में होती हैं। या तो proxy upstream पर HTTP/1.0 का उपयोग करता है या upgrade headers को हटा देता है, जिससे upgrade कभी नहीं हो पाता और editor बार-बार reconnect करता रहता है। या फिर upgrade सफल हो जाता है और proxy बाद में socket को बंद कर देता है क्योंकि वह शांत रहा है, क्योंकि बिना किसी message वाला WebSocket बिल्कुल idle connection जैसा दिखता है। दोनों ही स्थितियों में container healthy होता है। यह बैनर ब्राउज़र द्वारा आपको यह बताने का तरीका है कि उसने अपना channel खो दिया है।

कुछ भी edit करने से पहले ब्राउज़र में इसकी पुष्टि करें। Developer tools खोलें, Network tab पर जाएं, WS के लिए filter करें, और editor को reload करें। Push request को 101 Switching Protocols तक पहुंचना चाहिए और खुला रहना चाहिए। एक push request जो सामान्य status code लौटाता है, या जो हर कुछ सेकंड में फिर से दिखाई देता है, वह proxy की ओर इशारा करता है।

nginx सेटिंग्स जो एडिटर को कनेक्टेड रखती हैं

nginx तब तक upgrade request को आगे नहीं भेजता जब तक आप उसे ऐसा करने के लिए न कहें। proxy_pass डिफ़ॉल्ट रूप से backend के साथ HTTP/1.0 का उपयोग करता है, और Connection तथा Upgrade hop-by-hop हेडर हैं जिन्हें nginx रास्ते में हटा देता है। आपको इन दोनों को वापस जोड़ना होगा। map ब्लॉक को http कॉन्टेक्स्ट में रखा जाना चाहिए, न कि 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 सेकंड है और यह अपग्रेड किए गए WebSocket पर भी लागू होता है। इसलिए, यदि कोई एडिटर टैब किसी शांत इंस्टेंस पर खुला छोड़ दिया जाए, तो अंतिम संदेश के एक मिनट बाद उसका कनेक्शन टूट जाता है। इसे बढ़ाने से वह बैनर हट जाता है जो आपको तब दिखता है जब आप किसी खुले छोड़े गए टैब पर वापस आते हैं।

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

nginx -T एक फाइल के बजाय पूरा रनिंग कॉन्फ़िगरेशन प्रिंट करता है, जिससे यह साबित होता है कि आपका बदलाव वास्तव में लोड हो गया है। यदि कोई कॉन्फ़िगरेशन किसी ऐसी फाइल में है जिसे कोई भी include लाइन पिक नहीं करती, तो सही सुधार करने के बावजूद कोई परिणाम नहीं दिखता।

इसके बाद n8n को बताएं कि यह एक प्रॉक्सी के पीछे है, क्योंकि यह इन्हीं मानों से URL बनाता है।

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 कनेक्ट करने वाले पते को ही क्लाइंट पता मानता है और X-Forwarded-For को अनदेखा कर देता है। इसे कंटेनर के सामने मौजूद प्रॉक्सी की संख्या पर सेट करें। अगस्त 2026 तक, N8N_WEBHOOK_URL वर्तमान नाम है और पुराना WEBHOOK_URL अभी भी काम करता है, हालांकि स्टार्टअप पर यह एक डेप्रिकेशन चेतावनी प्रिंट करता है।

Traefik websockets को forward करता है, फिर उनका समय समाप्त (timeout) कर देता है

Traefik बिना किसी middleware और अतिरिक्त labels के WebSocket upgrade को forward करता है। इसलिए, जो Traefik उपयोगकर्ता यह banner देखते हैं, वे आमतौर पर missing header के बजाय timeout का सामना कर रहे होते हैं। इसके नियंत्रण entryPoint पर होते हैं। अगस्त 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 को बिल्कुल भी नहीं बदल सकते, क्योंकि इसका स्वामित्व किसी और के पास है, तो N8N_PUSH_BACKEND=sse के साथ push channel को बदलें। SSE (server-sent events) एक सामान्य HTTP response है जिसे खुला रखा जाता है, इसलिए यह ऐसे proxy के साथ भी काम करता है जो upgrade को अस्वीकार करता है, हालांकि एक आक्रामक idle timeout इसे फिर भी काट सकता है। Proxy का चयन करना एक अलग निर्णय है, और nginx, Caddy और Traefik की तुलना इस बात को कवर करती है कि प्रत्येक को संचालित करने में आपकी क्या लागत आती है।

जब कंटेनर वास्तव में बार-बार रीस्टार्ट हो रहा हो

यदि RestartCount बढ़ता है, तो इसका मतलब है कि कंटेनर विफल हो रहा है और Docker उसे बार-बार चालू करने का प्रयास कर रहा है। लॉग के टाइमस्टैम्प को प्रत्येक रीस्टार्ट के साथ मिलाएं और देखें कि ठीक उससे पहले क्या हुआ था। लगभग सभी समस्याएं इन चार कारणों से होती हैं: स्टार्टअप को रोकने वाली कॉन्फ़िगरेशन त्रुटि, ऐसा डेटाबेस जिसे n8n एक्सेस नहीं कर पा रहा है, चलने के दौरान क्रैश होना, और मेमोरी की कमी के कारण प्रोसेस का बंद होना।

शुरुआत वॉल्यूम से करें, क्योंकि अनुमतियों (permissions) से जुड़ी समस्याएं अक्सर छिपी रहती हैं। आधिकारिक इमेज एक unprivileged user node के रूप में चलती है और अपना डेटा /home/node/.n8n में रखती है। root द्वारा बनाया गया bind mount उस user के लिए लिखने योग्य (writable) नहीं होता है, इसलिए प्रोसेस हर बार स्टार्टअप पर ही बंद हो जाती है और रीस्टार्ट पॉलिसी इसे एक लूप के पीछे छिपा देती है।

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 इसे सही ओनरशिप के साथ बनाता है। यदि आपको bind mount की आवश्यकता है, तो पहली कमांड द्वारा प्रिंट की गई numeric user id पर होस्ट डायरेक्टरी को chown करें। होस्ट और कंटेनर के बीच ओनरशिप मैपिंग को एक बार समझ लेना फायदेमंद है, और PUID और PGID की व्याख्या में यह बताया गया है कि ये इमेज कैसे तय करती हैं कि फाइलें कौन लिखेगा।

Out of memory (OOM) kill जो क्रैश जैसा दिखता है

n8n प्रोसेस के ऊपर दो अलग-अलग मेमोरी सीमाएं होती हैं, और वे अलग-अलग तरीके से विफल होती हैं। कंटेनर कंट्रोल ग्रुप की सीमा को कर्नल द्वारा लागू किया जाता है: यदि आप इसे पार करते हैं, तो प्रोसेस तुरंत समाप्त हो जाती है, बिना कुछ भी लिखने के अवसर के, और OOMKilled का मान true होता है। V8 हीप सीमा को Node.js के भीतर लागू किया जाता है: यदि आप इसे पार करते हैं, तो Node एक हीप एरर और स्टैक ट्रेस के साथ बाहर निकल जाता है, इसलिए OOMKilled का मान false होता है। ब्राउज़र से ये दोनों एक जैसे दिखते हैं। docker inspect में ये केवल एक फील्ड के अंतर पर होते हैं।

Node हीप सीमा को कंटेनर की सीमा से नीचे सेट करें। यदि हीप सीमा दोनों में से अधिक है, तो V8 उस बिंदु से आगे भी एलोकेशन जारी रखता है जहाँ कर्नल हस्तक्षेप करता है। इस कारण इसका गार्बेज कलेक्टर अपनी सीमा तक कभी नहीं पहुँच पाता और आपको हमेशा वह कठोर विफलता मिलती है जिसका कोई लॉग उपलब्ध नहीं होता।

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 की वास्तविक क्षमता के आधार पर करें, और डेटाबेस, प्रॉक्सी तथा ऑपरेटिंग सिस्टम के लिए जगह छोड़ें। docker stats --no-stream लागू सीमा के साथ वर्तमान उपयोग को प्रिंट करता है, ताकि आप यह जांच सकें कि जो सीमा आपने लिखी है, वही Docker द्वारा लागू की गई है। Compose मेमोरी सीमाएं कैसे लागू होती हैं में विस्तार से बताया गया है कि जब कई सीमाएं सेट की जाती हैं, तो कौन सी की (key) प्रभावी होती है।

Execution data वह है जो आपके नीचे बढ़ता रहता है

एक single execution, run के दौरान हर node के output को hold करता है, और n8n फिर उस data को store करता है। इसके दो परिणाम होते हैं। एक run की peak memory उस data के सबसे बड़े batch से तय होती है जिसे आप उसके माध्यम से push करते हैं, इसलिए जो workflow एक बार में दस हजार rows को handle करता है, वह उसी workflow से अलग program है जो एक बार में दो सौ rows को handle करता है। और stored copy तब तक बढ़ती रहती है जब तक कोई उसे delete न कर दे।

Pruning दूसरी समस्या को संभालती है। अगस्त 2026 तक, defaults में pruning enabled है, EXECUTIONS_DATA_MAX_AGE 336 घंटे (14 दिन) पर है और EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000 पर है। SQLite चलाने वाले एक छोटे VPS के लिए ये काफी उदार हैं, जहाँ एक ही file सब कुछ hold करती है और वही process जो editor को serve करती है, उसे ही 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 को हटा देती है। इसे सोच-समझकर चुनें, क्योंकि यदि कोई workflow बिना error दिए गलत output देता है, तो आपके पास जाँचने के लिए कुछ नहीं बचेगा। Pruning पहले rows को deleted के रूप में mark करती है और उन्हें बाद के pass में हटाती है, और SQLite खाली हुए pages को वापस करने के बजाय उनका पुन: उपयोग (reuse) करता है, इसलिए setting बदलने के तुरंत बाद disk पर file का size कम नहीं होता।

Stored total के बजाय peak को कम करने के लिए, प्रति run कम data move करें। बड़े jobs को sub-workflows में विभाजित करें जो parent को छोटे results लौटाते हैं, Loop Over Items node के साथ batching करें, और पूरे datasets को Code node से बाहर रखें।

Binary files को memory के माध्यम से नहीं गुजरना चाहिए

N8N_DEFAULT_BINARY_DATA_MODE डिफ़ॉल्ट रूप से default पर सेट होता है, जो binary data को चल रहे execution की memory में रखता है। एक node जो भी फ़ाइल डाउनलोड करता है, और जो भी copy अगले node को दी जाती है, वह run समाप्त होने तक वहीं रहती है। एक workflow जो कुछ बड़ी attachments फ़ेच करता है, वह process को उस सीमा से आगे धकेल सकता है जहाँ सामान्य JSON कार्य कभी नहीं पहुँचते। यही कारण है कि crash किसी विशिष्ट workflow के बाद होता है, न कि समय के अनुसार।

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem के साथ, binary data को N8N_BINARY_DATA_STORAGE_PATH के अंतर्गत लिखा जाता है, जो डिफ़ॉल्ट रूप से n8n user folder के अंदर रहता है और इसलिए अन्य सभी चीज़ों के साथ उसी volume पर स्थित होता है। स्विच करने से पहले जाँच लें कि volume में पर्याप्त जगह है या नहीं। N8N_PAYLOAD_SIZE_MAX सबसे बड़े incoming webhook payload को MiB (mebibytes) में सेट करता है और इसका डिफ़ॉल्ट मान 16 है। इसे बढ़ाने से बड़ी requests अंदर आ सकती हैं, और यह एक memory लागत है जिसे आप स्वीकार करने का विकल्प चुन रहे हैं।

जो कुछ भी उस box को साझा करता है, वह उसी RAM के लिए प्रतिस्पर्धा करता है। यदि OOM kills तब शुरू हुए जब आपने एक database container जोड़ा, तो database को Docker में या host पर चलाना वह trade-off है जो आप अब कर रहे हैं।

Restart policy और reboot के बाद वापसी

बिना restart policy वाला container exit होने के बाद बंद रहता है, और host के reboot होने पर भी वह start नहीं होता। restart: unless-stopped इन दोनों स्थितियों में उसे वापस ले आता है, जबकि आपके द्वारा मैन्युअल रूप से बंद किए गए container का यह सम्मान करता है। restart: always आपके द्वारा जानबूझकर बंद किए गए container को भी Docker के अगली बार start होने पर पुनः चालू कर देता है।

n8n एक health endpoint प्रदान करता है, जिसे N8N_ENDPOINT_HEALTH द्वारा नामित किया गया है, जो डिफ़ॉल्ट रूप से healthz पर होता है। इसे पहले host से जांचें ताकि आप सुनिश्चित हो सकें कि आपके instance पर path सही है।

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

Healthcheck अपने आप में किसी चीज़ को restart नहीं करता है। Compose container को unhealthy के रूप में चिह्नित करता है और वहीं रुक जाता है, इसलिए किसी भी प्रभाव के लिए healthcheck को एक restart policy या उसके साथ एक external watcher की आवश्यकता होती है। वास्तव में कार्य करने वाला healthcheck लिखना और reboot के बाद stack को फिर से शुरू करना इन दोनों पहलुओं को कवर करते हैं।

वह वर्कफ़्लो जो कभी ट्रिगर नहीं होता जबकि n8n ठीक चल रहा है

इसमें न तो कोई बैनर दिखता है और न ही कोई रीस्टार्ट होता है। कंटेनर चल रहा है, एडिटर काम कर रहा है, और जिस रन की आप उम्मीद कर रहे थे वह निष्पादन (executions) सूची में गायब है। इसके अधिकांश मामलों के लिए चार कारण जिम्मेदार होते हैं।

• वर्कफ़्लो सक्रिय (active) नहीं है। एक Schedule Trigger केवल प्रोडक्शन पाथ पर चलता है, इसलिए कैनवास में इसे टेस्ट करने पर कुछ भी शेड्यूल नहीं होता।
• टाइमज़ोन आपका नहीं है। GENERIC_TIMEZONE डिफ़ॉल्ट रूप से America/New_York पर सेट होता है, इसलिए 09:00 के लिए सेट किया गया शेड्यूल उस ज़ोन में 09:00 बजे ही ट्रिगर होगा, जब तक कि आप GENERIC_TIMEZONE और TZ को अपने अनुसार सेट नहीं कर लेते।
• डाउनटाइम के बाद रन की भरपाई नहीं होती। ट्रिगर तब रजिस्टर होते हैं जब n8n स्टार्ट होता है, इसलिए यदि कंटेनर रीस्टार्ट होने के दौरान कोई शेड्यूल समय निकल गया है, तो वह बाद में नहीं चलेगा। अगला रन स्टार्टअप के बाद आने वाला निर्धारित समय होगा।
• वर्कफ़्लो आपके लिए डीएक्टिवेट कर दिया गया था। N8N_WORKFLOW_AUTODEACTIVATION_ENABLED डिफ़ॉल्ट रूप से बंद रहता है, और जब यह चालू होता है, तो बार-बार क्रैश होने वाला वर्कफ़्लो अनपब्लिश हो जाता है, जिसके बाद वह बिल्कुल वैसा ही दिखता है जैसे उसे किसी ने कभी सक्रिय ही न किया हो।

निष्पादन सूची (executions list) खोलें और उस वर्कफ़्लो के लिए फ़िल्टर करें। यदि कोई एंट्री विफल (failed) दिखाई देती है, तो यह वर्कफ़्लो की समस्या है। यदि कोई एंट्री नहीं है, तो यह ट्रिगर की समस्या है, और ऊपर दिए गए चार कारणों की जाँच करें।

सबसे पहले क्या बदलें

1. किसी भी फाइल को एडिट करने से पहले अपने कंटेनर पर STATUS, RestartCount और OOMKilled को पढ़ें।
2. यदि कंटेनर कभी डाउन नहीं हुआ है, तो प्रॉक्सी अपग्रेड हेडर और आइडल टाइमआउट को ठीक करें।
3. यदि OOMKilled true है, तो अपनी इच्छा अनुसार कंटेनर लिमिट सेट करें, नोड हीप सीलिंग को उससे नीचे रखें और बाइनरी डेटा को filesystem पर स्विच करें।
4. यदि कुछ भी काम नहीं कर रहा है, तो जांचें कि वर्कफ़्लो सक्रिय है और इंस्टेंस का टाइमज़ोन आपका ही है।

इसमें से अधिकांश कॉन्फ़िगरेशन ऐसे हैं जिन्हें आप एक बार सेट करते हैं और भूल जाते हैं, जो एक वर्किंग इंस्टॉलेशन के ऊपर होते हैं। यदि आप अभी भी उस इंस्टॉलेशन को असेंबल कर रहे हैं, तो HTTPS के साथ Docker पर n8n का वॉकथ्रू वह आधार है जिसमें ये सेटिंग्स संबंधित हैं।

FAQ

n8n editor container के चलने के बावजूद 'connection lost' banner क्यों दिखाता है?

Editor execution progress को stream करने के लिए एक WebSocket खुला रखता है। यदि आपका reverse proxy Connection: Upgrade और Upgrade: websocket headers को forward नहीं करता है, या upstream में HTTP/1.1 का उपयोग नहीं करता है, तो upgrade कभी पूरा नहीं होता और browser बार-बार reconnect करता रहता है जबकि n8n सही ढंग से चल रहा होता है। Nginx में आपको proxy_http_version 1.1 के साथ-साथ दोनों proxy_set_header लाइनों की आवश्यकता होती है, और एक ऐसा proxy_read_timeout चाहिए जो default 60 seconds से अधिक हो ताकि inactive tab disconnect न हो। चल रही configuration को जांचने के लिए sudo nginx -T का उपयोग करें, न कि उस file का जिसे आपने edit किया है।

मैं 'out of memory' kill और सामान्य crash के बीच अंतर कैसे करूँ?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' चलाएं और OOMKilled flag को पढ़ें। 'True' का अर्थ है कि kernel ने memory limit पार होने के कारण process को kill कर दिया है, और container log में कुछ भी उपयोगी नहीं मिलेगा क्योंकि process को लिखने का मौका ही नहीं मिला। 'False' के साथ, यदि docker logs के अंत में heap error और stack trace है, तो इसका मतलब है कि Node.js अपनी V8 heap सीमा तक पहुँच गया और खुद ही exit हो गया। NODE_OPTIONS=--max-old-space-size को अपने container limit से नीचे सेट करें ताकि आपको दूसरा वाला failure मिले, जिसमें सबूत मौजूद रहते हैं।

क्या execution data को prune करने से disk space तुरंत खाली हो जाता है?

नहीं। EXECUTIONS_DATA_PRUNE पुरानी executions को deletion के लिए mark करता है और बाद में एक pass उन्हें हटा देता है, जो EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL द्वारा निर्धारित schedule पर होता है। SQLite के मामले में, file freed pages को filesystem को वापस करने के बजाय उन्हें फिर से उपयोग करती है, इसलिए rows हटने के बाद भी disk पर size कुछ समय तक स्थिर रहता है। EXECUTIONS_DATA_MAX_AGE और EXECUTIONS_DATA_PRUNE_MAX_COUNT को अपनी आवश्यकतानुसार सेट करें, और तुरंत जांचने के बजाय अगले दिन देखें।

n8n के restart होने के दौरान मेरा scheduled workflow क्यों नहीं चला?

n8n process शुरू होने पर triggers को register करता है, और यह उन schedules को replay नहीं करता जो down time के दौरान due हो गए थे। इसलिए restart loop के कारण catch-up runs के बजाय silence रहती है, और अगली execution startup के बाद के अगले due time पर होती है। यदि आपको ऐसी runs चाहिए जिन्हें miss नहीं किया जा सकता, तो workflow को एक external caller से webhook के जरिए चलाएं, ताकि retry logic n8n के बाहर रहे।

क्या healthcheck के कारण n8n प्रतिक्रिया न देने पर restart हो जाएगा?

अपने आप नहीं। Compose healthcheck केवल container को healthy या unhealthy के रूप में mark करता है। Restart करना restart policy का काम है, इसलिए restart: unless-stopped वह है जो exit होने के बाद container को वापस लाता है, और यह host reboot के बाद भी उसे वापस लाता है बशर्ते Docker service enabled हो। इसे sudo systemctl is-enabled docker के साथ confirm करें। विशेष रूप से unhealthy status पर कार्रवाई करने के लिए, आपको Docker के बाहर एक watcher की आवश्यकता होगी जो status को पढ़े और service को restart करे।