n8n Schedule Trigger తప్పు సమయంలో ఎందుకు అమలవుతుంది?

మీ n8n schedule trigger తప్పు గంటలో ఎందుకు అమలవుతుంది

n8n మూడు వేర్వేరు ప్రదేశాల నుంచి timezone ను చదువుతుంది. అందువల్ల n8n schedule trigger తప్పు గంటలో అమలవుతుంది. ఈ మూడింటిలో ఒక్కదాన్ని మాత్రమే సరిచేస్తే సమస్యలో ఒక భాగమే పరిష్కారమవుతుంది. అవి container కు చెందిన TZ variable, instance default GENERIC_TIMEZONE, అలాగే individual workflow లో సెట్ చేసిన timezone. ఈ మూడింటినీ ఒకసారి సెట్ చేస్తే, ఆ తర్వాత మీరు రాసే ప్రతి schedule మీరు ఆశించిన సమయానికే అమలవుతుంది.

ముందుగా ఒక అపోహను సరిచేయాలి. కొత్త self-hosted n8n UTC (coordinated universal time)లో schedules అమలు చేయదు. Official image ఎటువంటి TZ సెట్ చేయదు కాబట్టి container clock UTCలో ఉంటుంది. అయితే scheduling వేరే layer. GENERIC_TIMEZONE కోసం n8n documentation లో పేర్కొన్న default America/New_York (August 2026 నాటికి). అందువల్ల మార్చని instance తన Schedule Triggers ను New York time ఆధారంగా అమలు చేస్తుంది. అందుకే వినియోగదారులు నివేదించే time offset, వారు UTCకు ఉన్న స్థానిక సమయ వ్యత్యాసంతో చాలా సార్లు సరిపోదు. Berlinలో ఉన్న owner 06:00కి schedule చేసినప్పుడు అది స్థానిక సమయం ప్రకారం 12:00కి అమలవుతుంది. Marchలో United States daylight saving time కు మారి, Europe ఇంకా మారని వారాల్లో అది 11:00కి అమలవుతుంది.

మూడు timezone పొరలు, వాటిలో ఏది ప్రాధాన్యం పొందుతుంది

TZ అనేది container లోని operating system timezone. Scripts మరియు date వంటి commands ఏ system timezone ను ఉపయోగించాలో నిర్ణయించే variable గా n8n documentation దీన్ని వివరిస్తుంది. Container లో date ఏమి చూపించాలి, container log line పై ఏ timestamp నమోదు కావాలి, Code node లో new Date() ఏమి return చేయాలి, అలాగే అక్కడ మీరు run చేసే ఏ shell script కు ఏ timezone కనిపించాలి అన్నది ఇది నిర్ణయిస్తుంది. Schedule Trigger ఎప్పుడు run అవుతుందనే దానిపై దీనికి ప్రభావం ఉండదు.

GENERIC_TIMEZONE అనేది n8n instance timezone. Documentation దీన్ని n8n instance timezone గా పేర్కొంటుంది. Cron వంటి schedule nodes కు ఇది ముఖ్యమని కూడా చెబుతుంది. ఇక్కడ Cron అంటే ప్రామాణిక time-based scheduling syntax. n8n లో ఇది Schedule Trigger యొక్క Custom (Cron) option గా అందుబాటులో ఉంటుంది.

Workflow timezone ప్రతి workflow కు విడిగా సెట్ చేయబడుతుంది. Canvas పై workflow ను తెరవండి. ఎగువ కుడి మూలలోని మూడు చుక్కలను ఎంచుకోండి. తరువాత Settings ఎంచుకుని, Timezone విలువను మార్చండి. ఇది ఆ ఒక్క workflow కోసం GENERIC_TIMEZONE ను override చేస్తుంది.

Schedule Trigger కోసం ప్రాధాన్యత క్రమం స్థిరంగా ఉంటుంది. Workflow కు timezone సెట్ చేసి ఉంటే n8n ముందుగా workflow timezone ను ఉపయోగిస్తుంది. లేకపోతే GENERIC_TIMEZONE లోని instance timezone ను ఉపయోగిస్తుంది. అది కూడా లేకపోతే, n8n లో అంతర్నిర్మితంగా ఉన్న America/New_York ను ఉపయోగిస్తుంది. ఈ నిర్ణయ ప్రక్రియలో ఏ దశలోనూ TZ ను పరిశీలించదు.

మీ nodes లోని dates కోసం సమాధానం code ఏ clock ను అడుగుతుందనే దానిపై ఆధారపడి ఉంటుంది. n8n expressions వెనుక పనిచేసే date library అయిన Luxon, n8n timezone ను ఉపయోగిస్తుంది. అందువల్ల $now మరియు $today, trigger అనుసరించే workflow-then-instance క్రమాన్నే అనుసరిస్తాయి. Code node లోని సాధారణ JavaScript new Date() operating system ను అడుగుతుంది. కాబట్టి అది TZ ను అనుసరిస్తుంది. ఇక్కడి గందరగోళానికి ప్రధాన కారణం ఈ విభజనే: trigger సరైన సమయంలో run కావచ్చు, కానీ workflow రాసే ప్రతి timestamp మాత్రం కొన్ని గంటలు తప్పుగా ఉండవచ్చు.

Compose ఫైల్‌లో ఈ మూడింటినీ సెట్ చేయండి

ఫైల్‌లో TZ మరియు GENERIC_TIMEZONE ను పక్కపక్కనే ఉంచండి. అప్పుడు ఒకదాన్ని సెట్ చేసి మరొకదాన్ని మర్చిపోయే అవకాశం ఉండదు. కింది భాగం పనిచేస్తున్న service లో timezone కు సంబంధించిన భాగం. మిగతా ఫైల్, reverse proxy మరియు certificate, HTTPS వెనుక VPSలో self-hosted n8n నుంచి వస్తాయి.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - GENERIC_TIMEZONE=Europe/Berlin
      - TZ=Europe/Berlin
      - N8N_RUNNERS_ENABLED=true
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

దీనిని docker compose up -d తో అమలు చేయండి, docker compose restart తో కాదు. restart చేసినప్పుడు, సృష్టించిన సమయంలో ఉన్న environment తో అదే container మళ్లీ ప్రారంభమవుతుంది. అందువల్ల ఫైల్ మార్పులు running process కు వర్తించవు. up -d మారిన environment ను గుర్తించి container ను మళ్లీ సృష్టిస్తుంది. ఈ విలువలను inline గా కాకుండా env file లో ఉంచినా, ఇదే recreate నియమం వర్తిస్తుంది. ఆ ఫైల్‌ను ఎక్కడి నుంచి చదువుతారో Compose env file మరియు secrets నిర్వహణ గైడ్‌లో వివరించారు.

Region/City రూపంలో IANA (Internet Assigned Numbers Authority) zone name ను ఉపయోగించండి. ఉదాహరణకు Europe/Berlin లేదా America/Sao_Paulo ఉపయోగించవచ్చు. ఆ పేర్లలో సంబంధిత ప్రాంతానికి సంబంధించిన daylight saving నియమాలు ఉంటాయి. అందువల్ల స్థానిక గడియారాలు మారినప్పుడు offset కూడా మారుతుంది. Etc/GMT+5 వంటి fixed-offset name ఋతువుల మార్పుతో ఎప్పుడూ మారదు. దాని sign కూడా మీరు ఊహించే దానికి విరుద్ధంగా ఉంటుంది. LC_ALL=C TZ=Etc/GMT+5 date +%z అమలు చేస్తే -0500 ముద్రించబడుతుంది. ఆ పేర్లను ఉపయోగించవద్దు.

వాటిలో ఒక్కదాన్ని మాత్రమే సెట్ చేస్తే సమస్య సగమే పరిష్కారమవుతుంది

GENERIC_TIMEZONE ను మాత్రమే సెట్ చేస్తే Schedule Trigger మీరు కోరిన గంటకు అమలవుతుంది. అయితే ఆపరేటింగ్ సిస్టమ్ నుంచి సమయాన్ని చదివే ప్రతిదీ UTCలోనే ఉంటుంది. new Date().toString() ను పిలిచే Code node UTC string ను తిరిగి ఇస్తుంది. Container log పంక్తులపై UTC సమయం నమోదవుతుంది. System clock ఆధారంగా రూపొందించిన file name తప్పు అర్ధరాత్రి సమయంలో మారుతుంది.

TZ ను మాత్రమే సెట్ చేస్తే దీనికి విరుద్ధంగా జరుగుతుంది. docker compose exec n8n date మీ local time ను చూపిస్తుంది. అందువల్ల సరిగ్గా పనిచేస్తున్నట్లు కనిపిస్తుంది. కానీ Schedule Trigger ఇప్పటికీ America/New_York ఆధారంగానే ఉంటుంది. మీరు కోరిన సమయం కంటే ఆరు గంటల తేడాతో అది అమలవుతుంది. ఈ పరిస్థితి ఎక్కువ సమయాన్ని వృథా చేస్తుంది. ఎందుకంటే చాలామంది ముందుగా చేసే తనిఖీ ఇప్పుడు విజయవంతమవుతుంది.

Workflow timezone ను సెట్ చేసిన తర్వాత GENERIC_TIMEZONE ను మార్చినా, ఆ workflow ఆ మార్పును పరిగణించదు. Workflow లోని విలువకే ప్రాధాన్యం ఉంటుంది. ఆ workflow settings ను ఎవరైనా తెరిచి మార్చే వరకు అదే కొనసాగుతుంది. పక్క workflows అన్నీ సరిగ్గా నడుస్తుండగా, ఒక workflow మాత్రమే అసాధారణ సమయంలో నడిస్తే, కారణం దాదాపు ఎల్లప్పుడూ ఇదే.

అంచనా వేయకుండా clocks ను తనిఖీ చేయండి

host మరియు container ను నేరుగా పోల్చండి.

date
docker compose exec n8n date
docker compose exec n8n printenv TZ GENERIC_TIMEZONE

TZ సెట్ చేసిన తర్వాత మొదటి రెండు commands ఒకే wall-clock సమయాన్ని చూపాలి. ఉన్న ప్రతి variable కు printenv ఒక్కో line ను చూపుతుంది. అందువల్ల output లో రెండు lines ఉంటే రెండూ set అయి ఉన్నాయి. ఒక line మాత్రమే ఉంటే మీరు సగం సరిచేసిన స్థితిని చూస్తున్నారు.

ఇప్పుడు workflow లోపల నుంచే n8n ను అడగండి. Container shell ద్వారా workflow-level timezone ఏమిటో తెలుసుకోలేరు. తప్పుగా పనిచేస్తున్న workflow కు ఒక Code node ను జోడించి, Execute Workflow తో దాన్ని ఒకసారి run చేయండి.

return [
  {
    json: {
      n8n_time: $now.toISO(),
      n8n_zone: $now.zoneName,
      system_time: new Date().toString(),
    },
  },
];

n8n_zone అనేది ఈ workflow యొక్క Schedule Trigger ఉపయోగించే zone. ఇది workflow-then-instance క్రమం ద్వారా ఇప్పటికే resolve అయి ఉంటుంది. అందువల్ల ఇది ప్రశ్నకు నేరుగా సమాధానం ఇస్తుంది. system_time, TZ నుంచి container యొక్క స్వంత zone ను తీసుకువస్తుంది. దీన్ని కొత్త workflow లో కాకుండా తప్పుగా పనిచేస్తున్న workflow లో run చేయండి. Workflow-level setting workflow తోనే కొనసాగుతుంది. ఆ రెండు values వేర్వేరుగా ఉంటే ఒక్క config file కూడా తెరవకుండానే సమస్యను గుర్తించారు.

Schedule Trigger node లో Cron expressions

Schedule Trigger, seconds నుంచి months వరకు fixed intervals ను అందిస్తుంది. ఇవి సరిపోని సందర్భాల్లో Custom (Cron) ఉపయోగించవచ్చు. cron expression workflow లో resolved timezone ప్రకారం చదవబడుతుంది. అందువల్ల 0 6 * * * అంటే UTC ప్రకారం 06:00 కాదు, ఆ timezone లో 06:00 అని అర్థం. crontab guru నుంచి తీసుకున్న five-field expression ను అలాగే paste చేయవచ్చు. n8n optional seconds field ను కూడా అంగీకరిస్తుంది. Documentation లోని field table ప్రకారం దాని క్రమం ఇలా ఉంటుంది: second, minute, hour, day of month, month, day of week.

Offset ను చేతితో ఎప్పుడూ encode చేయవద్దు. UTC instance లో Berlin సమయానికి 06:00 చేరుకోవడానికి 0 4 * * * రాయడం శీతాకాలంలో సరైనదే. కానీ వేసవికాలం మొత్తం అది ఒక గంట తేడాతో ఉంటుంది. కారణం, Berlin శీతాకాలంలో UTC+1, వేసవిలో UTC+2 ఉపయోగిస్తుంది. Zone ను సెట్ చేసి, మీకు కావలసిన స్థానిక గంటను రాయండి.

02:30కు నిర్ణయించిన job పై daylight saving ప్రభావం

స్థానిక wall-clock సమయం ఎల్లప్పుడూ ఖచ్చితమైన instant ను సూచించదు. సంవత్సరానికి రెండుసార్లు ఒక గంట కనిపించకుండా పోతుంది, మరో గంట మళ్లీ వస్తుంది. ఆ సమయాల్లో నిర్ణయించిన ఏ job అయినా ప్రభావితమవుతుంది. n8n అవసరం లేకుండా, ఏ Linux box లోనైనా date తో ఇది ఎలా జరుగుతుందో చూడవచ్చు.

LC_ALL=C TZ=Europe/Berlin date -d '2027-03-28 02:30'

date: invalid date '2027-03-28 02:30'

ఇది command లోని typo కాదు. 2027-03-28న Berlin clock 02:00 నుంచి నేరుగా 03:00కు మారుతుంది. అందువల్ల ఆ రోజున స్థానిక 02:30 సమయం ఉండదు. date దాన్ని instant గా మార్చడానికి నిరాకరిస్తుంది. స్థానిక 02:30కు ఆధారపడిన job కు అమలు కావడానికి ఏ సమయ క్షణమూ ఉండదు. దాని సమీపంలోని సమయాలు మాత్రం సరైనవే: date -d '2027-03-28 01:30' ను CETగా, date -d '2027-03-28 03:30' ను CESTగా పరిష్కరిస్తుంది.

శరదృతువు మార్పు దీనికి విరుద్ధంగా ఉంటుంది. 2027-10-31న Berlin clock 03:00 నుంచి వెనక్కి 02:00కు వస్తుంది. అందువల్ల 02:30 సమయం రెండుసార్లు వస్తుంది.

LC_ALL=C TZ=Europe/Berlin date -d '2027-10-31 02:30 CEST' '+%s'
LC_ALL=C TZ=Europe/Berlin date -d '2027-10-31 02:30 CET' '+%s'

1824942600
1824946200

రెండు వేర్వేరు instants ఉంటాయి. రెండింటినీ స్థానిక 02:30 అని పిలుస్తారు. వాటి మధ్య 3600 seconds వ్యత్యాసం ఉంటుంది. ఆ సమయానికి ఖచ్చితంగా నిర్ణయించిన job రెండుసార్లు అమలవవచ్చు లేదా ఎవరూ ఎంచుకోని గంటలో ఒక్కసారి అమలవవచ్చు. billing run లేదా backup rotation కు ఈ రెండు ఫలితాల్లో ఏదీ అనుకూలం కాదు. schedule ను ఆ సమయ పరిధి వెలుపలికి మార్చండి. యూరప్ మరియు North America లోని చాలా time zoneలలో ప్రమాదకరమైన పరిధి స్థానికంగా 00:00 నుంచి 03:00 వరకు ఉంటుంది.

మౌలిక సదుపాయాల షెడ్యూల్‌ను UTCలో ఉంచి, వినియోగదారులకు స్థానిక సమయాన్ని చూపించండి

Timezone చేసే రెండు పనులను వేరు చేయడం ప్రామాణిక విధానం. యంత్రాలకు స్థిరమైన కాలవ్యవధి అవసరం. వ్యక్తులకు చదవగలిగే సమయం అవసరం.

• ఎవరూ పర్యవేక్షించని పనుల కోసం workflow timezone ను UTCగా సెట్ చేయండి. Backups, cache warming, log shipping, report generation ఈ వర్గంలోకి వస్తాయి. UTCలో daylight saving ఉండదు. అందువల్ల సంవత్సరంలోని ప్రతి రోజూ, రెండు runs మధ్య విరామం మీరు నిర్వచించిన విరామంతో ఖచ్చితంగా సమానంగా ఉంటుంది.
• వ్యక్తి చదివే పనుల కోసం schedule ను UTCలోనే ఉంచి, చూపించే సమయంలో మార్చండి. దీనికి ఒక expression చాలు: {{ $now.setZone('Europe/Berlin').toFormat('yyyy-MM-dd HH:mm') }} message bodyలో స్థానిక సమయాన్ని ఉంచుతుంది, trigger మాత్రం స్థిరంగా ఉంటుంది.

n8n వెలుపల కూడా ఇదే విభజన వర్తిస్తుంది. మీ automationలో కొంత భాగం VPSపై systemd service మరియు timerగా నడిస్తే, దాని OnCalendar line system timezoneలో చదవబడుతుంది. ఇది తన స్వంత setting కలిగిన నాలుగో clock అవుతుంది. ప్రతి schedulerను UTCలో ఉంచితే, నాలుగు నియమాలను గుర్తుంచుకోవాల్సిన బదులు ఒకే నియమాన్ని గుర్తుంచుకోవచ్చు. కాలవ్యవధిని సారాంశం చేసే పనులకు ఇది ముఖ్యమైనది. ఎందుకంటే n8n AI agent workflow నిన్నటి సంఖ్యలను అడిగినప్పుడు, ఏ timezone ఉపయోగించబడిందో దాని ఆధారంగా వేర్వేరు 24 గంటలను నిశ్శబ్దంగా పరిగణించవచ్చు.

విఫల స్థితులు మరియు మీరు చూసే అవుట్‌పుట్

అన్నీ సుమారు ఆరు గంటల తేడాతో అమలవుతున్నాయి. GENERIC_TIMEZONE ఎప్పుడూ సెట్ చేయలేదు, కాబట్టి అంతర్నిర్మిత డిఫాల్ట్ America/New_York వర్తిస్తుంది. docker compose exec n8n printenv GENERIC_TIMEZONE ఎలాంటి అవుట్‌పుట్‌ను ముద్రించదు. దాన్ని సెట్ చేసి, container ను మళ్లీ సృష్టించండి.

మీరు Compose file ను సవరించినా ఎలాంటి మార్పు కనిపించలేదు. మీరు docker compose restart అమలు చేశారు, కాబట్టి container దాని అసలు environment ను అలాగే ఉంచుకుంది. docker compose up -d అమలు చేసి, తరువాత docker compose exec n8n printenv TZ తో నిర్ధారించండి.

Trigger సరైనదే, timestamps మాత్రం తప్పుగా ఉన్నాయి. GENERIC_TIMEZONE మాత్రమే సెట్ అయింది. Code node లోని new Date() operating system నుంచి ఇప్పటికీ UTC ను చదువుతుంది. TZ ను అదే విలువకు సెట్ చేసి, container ను మళ్లీ సృష్టించండి.

ఒక workflow instance setting ను పట్టించుకోవడం లేదు. ఆ workflow తన settings లో స్వంత timezone ను కలిగి ఉంది. అది GENERIC_TIMEZONE కంటే ప్రాధాన్యత పొందుతుంది. Canvas తెరిచి, three dots, Settings, Timezone ఎంచుకోండి.

ఈ సంవత్సరం ఒకసారి daily job రెండుసార్లు అమలైంది లేదా ఒక రోజును దాటేసింది. దాని scheduled hour daylight saving transition సమయంలో ఉంది. ఆ hour ను మార్చండి లేదా ఆ workflow ను UTC కు మార్చండి.

FAQ

నా n8n schedule trigger తప్పు గంటలో ఎందుకు fire అవుతోంది?

Workflow మీరు అనుకున్నదానికంటే వేరే timezone ను ఉపయోగిస్తోంది. Workflow కు timezone సెట్ చేసి ఉంటే n8n ముందుగా దానినే ఉపయోగిస్తుంది. లేకపోతే GENERIC_TIMEZONE లోని instance timezone ను ఉపయోగిస్తుంది. అవి రెండూ లేకపోతే America/New_York అనే built-in default ను ఉపయోగిస్తుంది. GENERIC_TIMEZONE ను ఎవరూ సెట్ చేయని self-hosted instance New York సమయంతో schedules నడుపుతుంది, UTCతో కాదు. అందుకే offset, మీ స్వంత UTC వ్యత్యాసానికి సాధారణంగా సరిపోదు. docker compose exec n8n printenv GENERIC_TIMEZONE ను run చేయండి. Output లేకపోతే అది ఎప్పుడూ సెట్ చేయబడలేదు.

n8nలో TZ మరియు GENERIC_TIMEZONE మధ్య తేడా ఏమిటి?

TZ అనేది container లోని operating system timezone. ఇది container లో date ఏమి return చేస్తుందో, container log lines లో ఏ timestamps కనిపిస్తాయో, Code node లో new Date() ఏమి return చేస్తుందో, అలాగే మీరు అక్కడ run చేసే ఏ script కు ఏ timezone కనిపిస్తుందో నియంత్రిస్తుంది. GENERIC_TIMEZONE అనేది n8n instance timezone. Schedule nodes మరియు $now వంటి Luxon expressions దీనినే ఉపయోగిస్తాయి. ఒకదాన్ని మాత్రమే సెట్ చేస్తే trigger సరైనదిగా ఉండి timestamps తప్పుగా ఉండవచ్చు, లేదా timestamps సరైనవిగా ఉండి trigger గంటల తేడాతో fire కావచ్చు. రెండింటినీ ఒకే విలువకు సెట్ చేయండి.

Workflow timezone లేదా GENERIC_TIMEZONE ను సెట్ చేయాలా?

మొత్తం instance కు default గా GENERIC_TIMEZONE ను సెట్ చేయండి. ఒక workflow నిజంగా వేరే timezone కు చెందినప్పుడు మాత్రమే per-workflow setting ను ఉపయోగించండి. Workflow విలువ instance విలువపై ప్రాధాన్యం పొందుతుంది. GENERIC_TIMEZONE లో తరువాత చేసే మార్పులను అది అనుసరించదు. అందువల్ల మర్చిపోయిన per-workflow override ను కొన్ని నెలల తరువాత గుర్తించడం కష్టం.

Clocks మారినప్పుడు 02:30కి schedule చేసిన job కు ఏమవుతుంది?

ఆ local time కనిపించకపోవచ్చు లేదా రెండు సార్లు రావచ్చు. ఆ రోజు Berlin clock 02:00 నుంచి 03:00కి మారుతుంది కాబట్టి LC_ALL=C TZ=Europe/Berlin date -d '2027-03-28 02:30', date: invalid date '2027-03-28 02:30' ను return చేస్తుంది. 2027-10-31న అదే wall-clock reading ఒక గంట వ్యత్యాసం ఉన్న రెండు instants కు సరిపోతుంది. Scheduled work ను 00:00 నుంచి 03:00 వరకు ఉన్న local time band లో ఉంచకండి. లేదా workflow ను UTCకు సెట్ చేసి, వ్యక్తి చదివే చోట మాత్రమే local timeకు convert చేయండి.