VPSలో n8n offline అవుతుంటే కారణం ఎలా గుర్తించాలి

n8n ఎందుకు offline అవుతూనే ఉంటుంది: నాలుగు వైఫల్యాలు, ఒకే లక్షణం

"n8n keeps going offline" అనే వాక్యం నాలుగు వేర్వేరు వైఫల్యాలను సూచించవచ్చు. ప్రతి వైఫల్యానికి వేర్వేరు పరిష్కారం అవసరం. Container సాధారణంగా నడుస్తున్నప్పటికీ editor లో connection lost banner కనిపించవచ్చు. Container స్వయంచాలకంగా restart కావచ్చు. అధిక memory వినియోగం కారణంగా kernel Node.js process ను terminate చేయవచ్చు. లేదా process లో అసలు సమస్య ఏదీ లేకపోవచ్చు; active workflow మాత్రం ఎప్పుడూ trigger కాకపోవచ్చు. తప్పు setting ను మార్చితే, మీకు అసలు లేని సమస్యపై మొత్తం వారాంతం వెచ్చించాల్సి రావచ్చు.

కాబట్టి configuration ను మార్చే ముందు మీకు ఏ వైఫల్యం ఎదురైందో నిర్ధారించండి. n8n సాధారణంగా ఒకే Docker container లో, TLS (transport layer security) ను terminate చేసే reverse proxy వెనుక, ఒకే Node.js process గా నడుస్తుంది. ఈ layers లో ప్రతి ఒక్కటి తనదైన విధంగా విఫలమవుతుంది. Browser మాత్రం వీటన్నింటినీ ఒకే message తో చూపిస్తుంది.

ఈ క్రమంలో నిర్ధారణ చేయండి

VPS (virtual private server) లో ఈ commands ను అమలు చేసి, మీ స్వంత machine చూపించే values ను చదవండి. Forum thread లోని numbers తో వాటిని పోల్చవద్దు. ఇక్కడ ముఖ్యమైన values మీ machine కు సంబంధించినవి, మరెవరినో machine కు సంబంధించినవి కావు.

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 నడుస్తూ ఉంటే, n8n ఎప్పుడూ offline కాలేదు. విఫలమైనది మీ browser మరియు backend మధ్య connection. ఇది తదుపరి section లో వివరించే websocket path.

RestartCount Docker ఈ container ను ఎన్ని సార్లు restart చేసిందో చూపిస్తుంది. ఆ number ను రాసి పెట్టి, ఒక నిమిషం వేచి, మళ్లీ చదవండి. మీరు గమనిస్తున్నప్పుడు number పెరుగుతుంటే, అది restart loop. ప్రతి restart కు కాస్త ముందు ఉన్న log lines కారణాన్ని చూపిస్తాయి.

OOMKilled true లేదా false flag. True అంటే memory limit దాటినందుకు Linux kernel process ను terminate చేసిందని అర్థం. ఈ limit container కు ఉన్నదైనా లేదా మొత్తం machine కు ఉన్నదైనా కావచ్చు. ఈ ఒక్క field memory kill ను ఇతర exit రకాలన్నిటి నుంచి వేరు చేస్తుంది. అందుకే ఊహించేముందు దీన్ని చదవాలి.

ExitCode మీ container చివరిసారి ఏ exit code తో ముగిసిందో చూపిస్తుంది. ప్రతి 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 progress ను canvas పై stream చేయవచ్చు. డిఫాల్ట్‌గా ఆ connection WebSocket గా ఉంటుంది. దీన్ని N8N_PUSH_BACKEND ఎంచుకుంటుంది. దీని default value 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 నిరంతరం reconnect అవుతూనే ఉంటుంది. మరో సందర్భంలో upgrade విజయవంతమైనా, కొంతకాలం ఎలాంటి traffic లేకపోతే proxy socket ను మూసివేయవచ్చు. సందేశాలు లేని WebSocket idle connection లాగానే కనిపిస్తుంది. రెండు సందర్భాల్లోనూ container ఆరోగ్యంగా ఉంటుంది. Banner కనిపించడం అంటే 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 తో default గా HTTP/1.0 ద్వారా మాట్లాడుతుంది. Connection మరియు Upgrade hop-by-hop headers కావడంతో nginx వాటిని మార్గమధ్యంలో తొలగిస్తుంది. మీరు ఈ రెండింటినీ మళ్లీ జోడించాలి. 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 ను చాలామంది మర్చిపోతారు. దీని default 60 seconds. Upgrade చేసిన WebSocket కు కూడా ఇది వర్తిస్తుంది. అందువల్ల నిశ్శబ్దంగా ఉన్న instance లో editor tab తెరిచి ఉంచితే, చివరి message దాని ద్వారా వెళ్లిన సుమారు ఒక నిమిషం తర్వాత connection కోల్పోతుంది. దీని విలువ పెంచితే, కొంతసేపు తెరిచి ఉంచిన 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 ను చూపిస్తుంది. అందువల్ల మీరు చేసిన edit వాస్తవంగా load అయిందని నిర్ధారించవచ్చు. ఏ include line కూడా ఎంచుకోని file లో ఉన్న configuration వల్ల సరైన fix చేసినా ప్రభావం కనిపించదు.

తర్వాత n8n కు అది proxy వెనుక ఉందని తెలియజేయాలి, ఎందుకంటే అది ఈ విలువల ఆధారంగా 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 గా 0 ఉంటుంది. అంటే n8n connection చేస్తున్న 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 డిఫాల్ట్‌గా 180 seconds‌కు, readTimeout డిఫాల్ట్‌గా 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 ఉంటే అది కూడా connection‌ను నిలిపివేస్తుంది. ఏ proxyని ఎంచుకోవాలనేది వేరే నిర్ణయం. nginx, Caddy మరియు Traefik పోలికలో ప్రతి proxyని నిర్వహించడానికి అయ్యే వ్యయం వివరించబడింది.

కంటైనర్ నిజంగానే పునఃప్రారంభమవుతున్నప్పుడు

RestartCount పెరుగుతుంటే, కంటైనర్ విఫలమవుతోంది మరియు Docker దాన్ని మళ్లీ ప్రారంభిస్తోంది. ప్రతి restart సమయంతో log timestamps ను సరిపోల్చి, దానికి వెంటనే ముందు ఏమి జరిగిందో చదవండి. దాదాపు అన్ని సందర్భాలను నాలుగు కారణాలు వివరిస్తాయి: startup ను ఆపేసే configuration error, n8n చేరుకోలేని database, నడుస్తున్న సమయంలో సంభవించే crash, మరియు memory kill.

ముందుగా volume ను పరిశీలించండి. Permissions సమస్య సాధారణంగా నిశ్శబ్దంగా ఉంటుంది. Official image ప్రత్యేక హక్కులు లేని user node గా నడుస్తుంది మరియు తన data ను /home/node/.n8n లో ఉంచుతుంది. root సృష్టించిన bind mount ను ఆ user write చేయలేడు. అందువల్ల 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 ownership ను chown చేయండి. Host మరియు container మధ్య ownership mapping ను ఒకసారి అర్థం చేసుకోవడం ఉపయోగకరం. ఈ images files ఎవరి user గా write చేస్తాయో PUID మరియు PGID వివరణ వివరిస్తుంది.

క్రాష్‌లా కనిపించే out-of-memory kill

n8n process పై రెండు వేర్వేరు memory పరిమితులు ఉంటాయి. అవి విభిన్నంగా విఫలమవుతాయి. Container control group పరిమితిని kernel అమలు చేస్తుంది. ఆ పరిమితిని దాటితే process వెంటనే kill అవుతుంది. ఏదీ రాయడానికి అవకాశం ఉండదు. అప్పుడు OOMKilled విలువ true గా ఉంటుంది. V8 heap పరిమితిని Node.js అంతర్గతంగా అమలు చేస్తుంది. ఆ పరిమితిని దాటితే Node stack trace తో heap error చూపించి స్వయంగా exit అవుతుంది. అందువల్ల OOMKilled విలువ false గా ఉంటుంది. Browser నుంచి ఇవి ఒకే విధంగా కనిపిస్తాయి. docker inspect లో ఇవి ఒక field తేడాతో కనిపిస్తాయి.

Node heap పరిమితిని container పరిమితికంటే తక్కువగా సెట్ చేయండి. Heap పరిమితి ఈ రెండింటిలో ఎక్కువగా ఉంటే, kernel జోక్యం చేసుకునే స్థాయిని దాటి కూడా V8 memory allocate చేస్తూనే ఉంటుంది. అందువల్ల దాని garbage collector తన పరిమితిని చేరుకోదు. ఫలితంగా log చదివే అవకాశం లేకుండా మరింత తీవ్రమైన failure ఎల్లప్పుడూ వస్తుంది.

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 చూపిస్తుంది. మీరు రాసిన పరిమితినే Docker వర్తింపజేసిందో లేదో దీనితో తనిఖీ చేయవచ్చు. Compose memory limits ఎలా వర్తిస్తాయి అనే విభాగంలో అనేక పరిమితులు సెట్ చేసినప్పుడు ఏ keyకి ప్రాధాన్యం వస్తుందో వివరించబడింది.

మీ కింద Execution data పెరుగుతూనే ఉంటుంది

ఒక execution అమలులో ఉన్నంతకాలం ప్రతి node యొక్క output ను కలిగి ఉంటుంది. తర్వాత n8n ఆ data ను నిల్వ చేస్తుంది. దీనివల్ల రెండు విషయాలు జరుగుతాయి. ఒక run కు అవసరమైన గరిష్ఠ memory, దాని ద్వారా పంపే అతిపెద్ద data batch పరిమాణంపై ఆధారపడి ఉంటుంది. కాబట్టి ఒకేసారి పది వేల rows ను నిర్వహించే workflow, ఒకేసారి రెండు వందల rows ను నిర్వహించే అదే workflow కంటే భిన్నమైన program. అలాగే, ఏదైనా తొలగించే వరకు నిల్వ చేసిన copy పెరుగుతూనే ఉంటుంది.

Pruning రెండవ సమస్యను పరిష్కరిస్తుంది. August 2026 నాటికి pruning enabled గా ఉంటుంది. EXECUTIONS_DATA_MAX_AGE విలువ 336 hours (14 days), EXECUTIONS_DATA_PRUNE_MAX_COUNT విలువ 10000. SQLite నడుస్తున్న చిన్న VPS కు ఇవి ఎక్కువకాలం నిల్వ చేసే పరిమితులు. అలాంటి వ్యవస్థలో ఒకే file లో మొత్తం data ఉంటుంది. Editor ను అందించే అదే process ఆ file ను 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 ను తొలగిస్తుంది. ఈ ఎంపికను ఉద్దేశపూర్వకంగా చేయాలి. Error రాకపోయినా workflow తప్పు output ను ఉత్పత్తి చేస్తే, పరిశీలించడానికి ఏ data మిగలదు. Pruning మొదట rows ను deleted గా mark చేస్తుంది. తరువాతి pass లో వాటిని తొలగిస్తుంది. అదనంగా, SQLite ఖాళీ అయిన pages ను తిరిగి ఇవ్వకుండా మళ్లీ ఉపయోగిస్తుంది. అందువల్ల setting మార్చిన వెంటనే disk లోని file పరిమాణం తగ్గదు.

నిల్వ చేసిన మొత్తం data ను కాకుండా peak data ను తగ్గించాలంటే, ప్రతి run లో తక్కువ data ను పంపండి. పెద్ద jobs ను చిన్న results ను parent కు తిరిగి ఇచ్చే sub-workflows గా విభజించండి. Loop Over Items node తో batches ఉపయోగించండి. మొత్తం datasets ను Code node లో ఉంచవద్దు.

బైనరీ ఫైళ్లు memory ద్వారా ప్రయాణించకూడదు

N8N_DEFAULT_BINARY_DATA_MODE డిఫాల్ట్‌గా default కు సెట్ అవుతుంది. దీని వల్ల బైనరీ డేటా నడుస్తున్న execution యొక్క memoryలోనే ఉంటుంది. node డౌన్‌లోడ్ చేసే ప్రతి ఫైల్, తదుపరి nodeకు పంపే ప్రతి copy, run ముగిసే వరకు అక్కడే ఉంటుంది. కొన్ని పెద్ద attachments ను fetch చేసే ఒక workflow, సాధారణ JSON పనికి ఎప్పుడూ చేరని memory పరిమితిని దాటేలా process ను నెట్టవచ్చు. అందుకే 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 ఖర్చును మీరు స్వీకరిస్తున్నారు.

అదే serverలో నడిచే ఇతర సేవలన్నీ అదే RAM కోసం పోటీ పడతాయి. database container జోడించిన తర్వాత OOM kills ప్రారంభమైతే, databaseను Dockerలో లేదా hostపై నడపడం అనేది మీరు ఇప్పుడు చేస్తున్న trade-off.

పునఃప్రారంభ విధానం మరియు reboot తర్వాత మళ్లీ ప్రారంభం

restart policy లేని container exit అయిన తర్వాత, host reboot అయిన తర్వాత కూడా ఆగిపోయిన స్థితిలోనే ఉంటుంది. restart: unless-stopped రెండు సందర్భాల్లోనూ దాన్ని మళ్లీ ప్రారంభిస్తుంది. అయితే మీరు చేతితో ఆపిన container ను ఇది మళ్లీ ప్రారంభించదు. మీరు ఉద్దేశపూర్వకంగా ఆపిన container ను Docker తదుపరి సారి ప్రారంభమైనప్పుడు కూడా మళ్లీ ప్రారంభించడానికి restart: always ఉపయోగించాలి.

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 container ను unhealthy గా గుర్తించి అక్కడితో ఆగిపోతుంది. అందువల్ల healthcheck ప్రభావం చూపాలంటే దానికి restart policy లేదా దాని పక్కన పనిచేసే external watcher అవసరం. నిజంగా చర్య తీసుకునే healthcheck రాయడం మరియు reboot తర్వాత stack ను మళ్లీ ప్రారంభించడం ఈ రెండు అంశాలను వివరిస్తాయి.

n8n సరిగ్గా పనిచేస్తున్నా workflow ఎప్పుడూ ప్రారంభం కాకపోవడం

ఈ సందర్భంలో banner కనిపించదు, restart కూడా జరగదు. Container up లో ఉంటుంది, editor పనిచేస్తుంది, కానీ మీరు ఆశించిన run executions list లో కనిపించదు. దీనికి సాధారణంగా ఈ నాలుగు కారణాల్లో ఒకటి ఉంటుంది.

• Workflow active గా లేదు. Schedule Trigger production path లో మాత్రమే నడుస్తుంది. అందువల్ల canvas లో test చేస్తే ఏ schedule కూడా నమోదు కాదు.
• Timezone మీది కాదు. GENERIC_TIMEZONE కు default విలువ America/New_York. కాబట్టి GENERIC_TIMEZONE మరియు TZ ను మీ timezone కు సెట్ చేసే వరకు 09:00 కు సెట్ చేసిన schedule ఆ timezone లో 09:00 కే run అవుతుంది.
• Downtime తర్వాత missed run తిరిగి అమలు కాదు. n8n ప్రారంభమైనప్పుడు triggers register అవుతాయి. అందువల్ల container restart అవుతున్న సమయంలో due అయిన schedule ఆలస్యంగా run కాదు. Startup తర్వాత వచ్చే తదుపరి due time లోనే next run జరుగుతుంది.
• Workflow స్వయంచాలకంగా deactivate అయింది. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED default గా off లో ఉంటుంది. దాన్ని on చేస్తే, పదేపదే crash అవుతున్న workflow unpublish అవుతుంది. ఆ తర్వాత అది ఎప్పుడూ activate చేయని workflow లాగానే కనిపిస్తుంది.

Executions list తెరిచి, ఆ workflow కు filter చేయండి. Failed entry కనిపిస్తే సమస్య workflow లో ఉంది. Entry ఏదీ కనిపించకపోతే సమస్య trigger లో ఉంది. పరిశీలించాల్సిన మొదటి ప్రదేశాలు పై నాలుగు కారణాలే.

ముందుగా ఏం మార్చాలి

1. ఏ ఫైల్‌ను సవరించే ముందు, మీ స్వంత container లో STATUS, RestartCount మరియు OOMKilled చదవండి.
2. container ఎప్పుడూ ఆగకపోతే, proxy upgrade headers మరియు idle timeout ను సరిచేయండి.
3. OOMKilled true అయితే, మీరు ఉద్దేశపూర్వకంగా ఎంచుకున్న container limit ను సెట్ చేయండి, దాని కంటే తక్కువగా Node heap ceiling ను ఉంచండి, అలాగే binary data ను filesystem కు మార్చండి.
4. ఏదీ trigger కాకపోతే, workflow active గా ఉందో, instance timezone మీ timezone కే సెట్ అయిందో తనిఖీ చేయండి.

ఇవన్నీ పనిచేస్తున్న install పై ఒకసారి సెట్ చేసి మర్చిపోవచ్చే configuration అంశాలే. మీరు ఇంకా ఆ install ను సిద్ధం చేస్తుంటే, HTTPS తో Docker పై n8n walkthrough ఈ settings కు ఆధారం.

FAQ

n8n container నడుస్తున్నప్పటికీ editor లో connection lost banner ఎందుకు కనిపిస్తుంది?

Execution progress ను stream చేయడానికి editor ఒక WebSocket connection ను తెరిచి ఉంచుతుంది. మీ reverse proxy Connection: Upgrade మరియు Upgrade: websocket headers ను forward చేయకపోతే, లేదా upstream కోసం HTTP/1.1 ఉపయోగించకపోతే, upgrade పూర్తి కాదు. అప్పుడు n8n సక్రమంగా నడుస్తున్నప్పటికీ browser ఎల్లప్పుడూ మళ్లీ connect అవుతూనే ఉంటుంది. nginx లో proxy_http_version 1.1 తో పాటు రెండు proxy_set_header lines అవసరం. అలాగే quiet tab timeout కాకుండా default 60 seconds కంటే ఎక్కువగా ఉండే proxy_read_timeout అవసరం. మీరు మార్చిన file ను కాకుండా, అమలులో ఉన్న config ను sudo nginx -T తో తనిఖీ చేయండి.

Out of memory kill ను సాధారణ crash నుంచి ఎలా గుర్తించాలి?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' అమలు చేసి OOMKilled flag ను చూడండి. విలువ True అయితే memory limit మించిందని kernel process ను terminate చేసింది. Process ఏదీ రాయడానికి అవకాశం పొందలేదు కాబట్టి container log లో ఉపయోగకరమైన సమాచారం ఉండదు. docker logs చివరలో heap error మరియు stack trace తో విలువ False కనిపిస్తే, Node.js తన V8 heap ceiling ను తాకి స్వయంగా exit అయిందని అర్థం. మీ container limit కంటే తక్కువగా NODE_OPTIONS=--max-old-space-size సెట్ చేయండి. అప్పుడు రెండవ రకం failure వస్తుంది. దానిలో ఆధారాలు మిగులుతాయి.

Execution data ను prune చేస్తే disk space వెంటనే ఖాళీ అవుతుందా?

లేదు. EXECUTIONS_DATA_PRUNE పాత executions ను deletion కోసం గుర్తిస్తుంది. తరువాత EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL నిర్దేశించిన schedule ప్రకారం జరిగే pass వాటిని తొలగిస్తుంది. SQLite తో file ఖాళీ అయిన pages ను filesystem కు తిరిగి ఇవ్వకుండా మళ్లీ ఉపయోగిస్తుంది. అందువల్ల rows తొలగించిన తర్వాత కొంతకాలం disk పై file size మారకుండా ఉంటుంది. మీ system కు సరిపోయే values గా EXECUTIONS_DATA_MAX_AGE మరియు EXECUTIONS_DATA_PRUNE_MAX_COUNT సెట్ చేయండి. వెంటనే కాకుండా మరుసటి రోజు మళ్లీ తనిఖీ చేయండి.

n8n restart అవుతున్న సమయంలో నా scheduled workflow ఎందుకు run కాలేదు?

Process ప్రారంభమైనప్పుడు n8n triggers ను register చేస్తుంది. అది down గా ఉన్న సమయంలో due అయిన schedules ను మళ్లీ replay చేయదు. అందువల్ల restart loop సమయంలో catch-up runs ఒక్కసారిగా రావు. బదులుగా startup తర్వాత వచ్చే తదుపరి due time లోనే execution జరుగుతుంది. తప్పక జరగాల్సిన runs ఉంటే, webhook ను call చేసే external caller నుంచి workflow ను నడపండి. అప్పుడు retry logic n8n వెలుపల ఉంటుంది.

n8n స్పందించడం ఆపితే healthcheck దాన్ని restart చేస్తుందా?

స్వయంగా 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 వెలుపల status చదివి service ను restart చేసే watcher అవసరం.