SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-30

VPSలో n8n ఎందుకు offline అవుతోంది? కారణాలు తెలుసుకోండి

n8n offlineలా కనిపించడానికి నాలుగు కారణాలు ఉన్నాయి: websocket banner, restart loop, out of memory kill, లేదా పనిచేయని schedule. వీటిని logsలో వేరు చేయండి.

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

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

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

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

VPS (virtual private server) పై ఈ commands ను అమలు చేసి, మీ స్వంత machine చూపించే values ను పరిశీలించండి. Forum thread లోని numbers తో వాటిని పోల్చవద్దు. ఇక్కడ ముఖ్యమైన values మీ box కు సంబంధించినవి, మరెవరి 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 up లో ఉంటే, n8n ఎప్పుడూ offline కాలేదు. విఫలమైనది మీ browser మరియు backend మధ్య connection. ఇది తరువాతి section లో వివరించే websocket path కు సంబంధించినది.

RestartCount Docker ఈ container ను ఎన్ని సార్లు restart చేసిందో చూపిస్తుంది. ఆ సంఖ్యను రాసుకుని, ఒక నిమిషం వేచి ఉండి, మళ్లీ చదవండి. మీరు గమనిస్తున్నప్పుడు సంఖ్య పెరుగుతుంటే, అది 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 అయినప్పుడు వచ్చిన value ను చూపిస్తుంది. ప్రతి code అర్థాన్ని కంఠస్థం చేసుకోవాల్సిన అవసరం లేదు. మీ value ను చదివి, అదే timestamp వద్ద docker logs చివర భాగాన్ని కూడా చదవండి. Log tail మరియు out of memory flag రెండింటినీ కలిపి పరిశీలిస్తే ఏమి జరిగిందో తెలుస్తుంది. ఒక్కదానిపై మాత్రమే ఆధారపడితే తప్పుదారి పట్టవచ్చు.

docker stats అమల్లో ఉన్న limit పక్కన ప్రస్తుత memory use ను చూపిస్తుంది. దీన్ని రెండవ terminal లో అమలులో ఉంచండి. సమస్య కలిగించే workflow ను trigger చేసి, failure జరుగుతున్నప్పుడు సంఖ్య ఎలా మారుతుందో గమనించండి.

n8n editor backend కు ఒక దీర్ఘకాలం తెరిచి ఉండే push connection ను నిర్వహిస్తుంది. దీని ద్వారా execution progress ను canvas పైకి పంపుతుంది. డిఫాల్ట్‌గా ఆ connection ఒక WebSocket. దీనినే N8N_PUSH_BACKEND ఎంపిక చేస్తుంది. దీని డిఫాల్ట్ విలువ websocket. WebSocket మొదట సాధారణ HTTP requestగా ప్రారంభమవుతుంది. అందులో Connection: Upgrade మరియు Upgrade: websocket headers ఉంటాయి. Server 101 Switching Protocols తో సమాధానం ఇస్తుంది. ఆ తరువాత రెండు వైపులూ ఒకే TCP socket ను రెండు దిశల్లో ఉపయోగిస్తాయి.

ఈ విధానాన్ని రెండు సమస్యలు భంగపరుస్తాయి. ఈ రెండూ n8n లో కాకుండా proxy లోనే ఉంటాయి. Proxy upstream కు HTTP/1.0 ఉపయోగించవచ్చు లేదా upgrade headers ను తొలగించవచ్చు. అప్పుడు upgrade జరగదు. Editor నిరంతరం మళ్లీ connect అవుతూనే ఉంటుంది. మరో సందర్భంలో upgrade విజయవంతమైనా, కొంత సమయం తర్వాత proxy socket ను మూసివేయవచ్చు. WebSocket పై messages లేకపోతే అది idle connection లాగే కనిపిస్తుంది. రెండు సందర్భాల్లోనూ container ఆరోగ్యంగా ఉంటుంది. Banner కనిపించడానికి కారణం browser తన channel ను కోల్పోయిందని తెలియజేయడమే.

ఏదైనా మార్చే ముందు browser లో దీన్ని నిర్ధారించండి. Developer tools తెరిచి, Network tab కు వెళ్లి, WS కు filter చేసి editor ను reload చేయండి. Push request 101 Switching Protocols కు చేరుకుని తెరిచి ఉండాలి. సాధారణ status code ను ఇచ్చే push request లేదా ప్రతి కొన్ని సెకన్లకు మళ్లీ కనిపించే request proxy సమస్యను సూచిస్తుంది.

ఎడిటర్ కనెక్ట్‌గా ఉండేలా చేసే nginx సెట్టింగ్‌లు

nginx ను ప్రత్యేకంగా అడగకపోతే అది upgrade ను forward చేయదు. డిఫాల్ట్‌గా proxy_pass backend తో HTTP/1.0 ద్వారా మాట్లాడుతుంది. Connection మరియు Upgrade hop-by-hop headers కావడంతో nginx వాటిని మార్గమధ్యంలో తొలగిస్తుంది. మీరు ఈ రెండింటినీ మళ్లీ జోడించాలి. map block ను http context లో ఉంచాలి; server లోపల కాదు. క్రింద ఉన్న మిగిలిన server block మీకు పరిచయం లేకపోతే, nginx server block లోని ప్రతి పంక్తి వివరణ ప్రతి 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 ను చాలామంది మర్చిపోతారు. దీని default 60 seconds. ఇది upgraded 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 వెనుక నడుస్తోందని దానికి తెలియజేయాలి. ఎందుకంటే n8n ఈ విలువల ఆధారంగా 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 కనెక్ట్ అవుతున్న 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 సమస్యను ఎదుర్కొంటున్నారు. సంబంధిత నియంత్రణలు entryPoint లో ఉంటాయి. August 2026 నాటికి Traefik v3 లో, idleTimeout డిఫాల్ట్‌గా 180 seconds కు, readTimeout డిఫాల్ట్‌గా 60 seconds కు సెట్ అయి ఉంటాయి.

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

Caddy upgrade ను reverse_proxy లో స్వయంచాలకంగా నిర్వహిస్తుంది. దానికి ప్రత్యేక directive అవసరం లేదు. Proxy పై మీకు ఎలాంటి మార్పులు చేయలేకపోతే, దాన్ని మరొకరు నిర్వహిస్తున్నందున, push channel ను N8N_PUSH_BACKEND=sse తో మార్చండి. SSE (server-sent events) అనేది open గా ఉంచబడే సాధారణ 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 unprivileged user node గా నడుస్తుంది మరియు దాని data ను /home/node/.n8n లో ఉంచుతుంది. root సృష్టించిన bind mount ను ఆ user రాయలేడు. అందువల్ల 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 ను ఎవరి పేరుతో రాస్తాయో PUID మరియు PGID వివరణ వివరిస్తుంది.

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

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

Node heap ceiling ను container limit కంటే తక్కువగా సెట్ చేయండి. ఈ రెండు పరిమితుల్లో heap ceiling ఎక్కువగా ఉంటే, kernel జోక్యం చేసుకునే స్థాయిని దాటి కూడా V8 allocation కొనసాగిస్తుంది. అందువల్ల garbage collector తన స్వంత limit ను చేరుకోదు. చివరికి 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 అమలు చేసిందో లేదో దీనితో తనిఖీ చేయవచ్చు. అనేక limits సెట్ చేసినప్పుడు ఏ key ప్రాధాన్యం పొందుతుందో Compose memory limits ఎలా వర్తిస్తాయి వివరిస్తుంది.

మీపై పెరుగుతూ ఉండేది execution data

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

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 ఆ 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 లేకుండా తప్పు output ఇచ్చిన workflowను పరిశీలించడానికి తరువాత ఏ data కూడా మిగలకపోవచ్చు. Pruning మొదట rowsను deletedగా mark చేస్తుంది. తరువాతి passలో వాటిని remove చేస్తుంది. అలాగే SQLite ఖాళీ అయిన pagesను తిరిగి ఉపయోగిస్తుంది; వాటిని operating systemకు తిరిగి ఇవ్వదు. అందువల్ల setting మార్చిన వెంటనే diskపై ఉన్న file పరిమాణం తగ్గదు.

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

బైనరీ ఫైళ్లు మెమరీ ద్వారా వెళ్లకూడదు

N8N_DEFAULT_BINARY_DATA_MODE డిఫాల్ట్‌గా default కు సెట్ అయి ఉంటుంది. ఇది నడుస్తున్న execution యొక్క మెమరీలో బైనరీ డేటాను ఉంచుతుంది. node డౌన్‌లోడ్ చేసే ప్రతి ఫైల్, తదుపరి node కు పంపే ప్రతి copy, run ముగిసే వరకు అక్కడే ఉంటుంది. కొన్ని పెద్ద attachments ను fetch చేసే ఒక workflow, సాధారణ JSON పనిలో ఎప్పుడూ చేరని memory limit ను దాటేలా 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 అయిన తర్వాత కూడా stopped స్థితిలోనే ఉంటుంది. restart: unless-stopped రెండు సందర్భాల్లోనూ దాన్ని మళ్లీ ప్రారంభిస్తుంది. అయితే మీరు చేతితో stop చేసిన container ను అది మళ్లీ ప్రారంభించదు. మీరు ఉద్దేశపూర్వకంగా stop చేసిన 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 ఒక్కటే ఏదీ restart చేయదు. Compose container ను unhealthy గా గుర్తించి అక్కడితో ఆగిపోతుంది. అందువల్ల healthcheck ప్రభావం చూపాలంటే దానికి restart policy లేదా దాని పక్కన పనిచేసే external watcher అవసరం. నిజంగా చర్య తీసుకునే healthcheck రాయడం మరియు reboot తర్వాత stack ను మళ్లీ ప్రారంభించడం ఈ రెండు అంశాలను వివరిస్తాయి.

n8n సరిగ్గా ఉన్నప్పటికీ workflow ఎప్పుడూ అమలు కాకపోవడం

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

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

Executions జాబితాను తెరిచి, ఆ workflow కు filter చేయండి. Failed అయిన entry కనిపిస్తే అది workflow సమస్య. అదే box పై మీరు host చేస్తున్న మరో service కు request పంపేటప్పుడు 429 తో విఫలమైతే, limit n8n కు కాకుండా ఆ service కు సంబంధించినది. SearXNG 429 walkthrough లో దాని స్వంత 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. ఏదీ trigger కాకపోతే, workflow active గా ఉందో, instance timezone మీ timezone కు సరిపోతుందో తనిఖీ చేయండి.

ఇవన్నీ పనిచేస్తున్న install పై ఒకసారి సెట్ చేసి సాధారణంగా మళ్లీ మార్చాల్సిన అవసరం లేని configuration అంశాలే. మీరు ఇంకా ఆ install ను సిద్ధం చేస్తుంటే, HTTPS తో Dockerలో n8n ఉపయోగించే మార్గదర్శిని ఈ 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 పూర్తికాదు. అప్పుడు browser నిరంతరం reconnect అవుతూనే ఉంటుంది, అయితే n8n సక్రమంగా నడుస్తుంది. nginxలో proxy_http_version 1.1 తో పాటు రెండు proxy_set_header lines కూడా అవసరం. Quiet tab అనుకోకుండా disconnect కాకుండా ఉండేందుకు default 60 seconds కంటే ఎక్కువగా ఉండే proxy_read_timeout కూడా అవసరం. మీరు సవరించిన 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 ను terminate చేసింది. Process log రాయడానికి అవకాశం లేకపోవడంతో container logలో ఉపయోగకరమైన సమాచారం ఉండదు. docker logs చివరలో heap error మరియు stack traceతో పాటు విలువ False ఉంటే, Node.js తన V8 heap ceiling ను తాకి స్వయంగా exit అయిందని అర్థం. మీ container limit కంటే తక్కువగా NODE_OPTIONS=--max-old-space-size సెట్ చేయండి. అప్పుడు రెండవ రకం failure వస్తుంది. దానికి సంబంధించిన ఆధారాలు logలో మిగులుతాయి.

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కు సరిపోయే విలువలుగా EXECUTIONS_DATA_MAX_AGE మరియు EXECUTIONS_DATA_PRUNE_MAX_COUNT సెట్ చేయండి. వెంటనే కాకుండా మరుసటి రోజు మళ్లీ తనిఖీ చేయండి.

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

Process ప్రారంభమైనప్పుడు n8n triggers ను register చేస్తుంది. అది downగా ఉన్న సమయంలో due అయిన schedules ను మళ్లీ అమలు చేయదు. అందువల్ల restart loop సమయంలో catch-up runs వరుసగా అమలు కాకుండా నిశ్శబ్దంగా ఉంటుంది. Startup తరువాత వచ్చే తదుపరి due time వద్దనే next execution జరుగుతుంది. తప్పక అమలు కావాల్సిన runs ఉంటే, webhookను పిలిచే 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 అవసరం.

#n8n#troubleshooting#docker#websockets#memory#reverse-proxy