§

Cron expression टाका किंवा खाली preset निवडा.

त्वरित presets:
§

पुढील 10 run times

cron

Human-readable schedule येथे दिसेल...

    §

    Expression तयार करणारा

    पुण्या-बंगळुरूच्या DevOps आणि backend engineers ला cron syntax stack च्या प्रत्येक स्तरावर भेटतो: AWS EventBridge Lambda triggers साठी, Kubernetes CronJobs EKS clusters वर, आणि GitHub Actions `.github/workflows/*.yml` मध्ये. Flipkart, Zepto आणि Swiggy च्या data pipelines मध्ये nightly batch jobs UTC timezone मध्ये schedule होतात — IST मध्ये next 10 fire times preview केल्याशिवाय DST drift किंवा UTC/IST +5:30 offset चुका production मध्ये जातात. हे साधन expression field-by-field build करण्यास आणि ship करण्यापूर्वी plain Marathi मध्ये confirm करण्यास मदत करते.

    Cron expression म्हणजे काय?

    Cron expression हे compact scheduling string आहे जे job scheduler ला नक्की कधी task fire करायचे ते सांगते. हे format 1975 मध्ये Unix V7 cron daemon मध्ये जन्माला आले आणि तेव्हापासून क्वचितच बदलले — तोच पाच-field grammar आज Kubernetes CronJobs, AWS EventBridge, GitHub Actions workflows, Google Cloud Scheduler, GitLab CI, Jenkins pipelines आणि प्रत्येक Linux distribution सोबत ship होणाऱ्या crontab binary मध्ये दिसतो. Grammar तेरा किंवा त्याहून अधिक characters मध्ये खूप अर्थ पॅक करते, म्हणूनच ते plain English मध्ये convert करणारा parser confident deploy आणि 3 AM rollback मधील फरक आहे.

    Cron expression कसे कार्य करते?

    Standard cron expression मध्ये पाच space-separated fields असतात जे एकत्रितपणे repeating schedule define करतात. Engine प्रत्येक मिनिटाला current wall clock expression विरुद्ध तपासतो आणि सर्व पाच fields जुळल्यावर job fire करतो. Fields, डावीकडून उजवीकडे:

    1. Minute (0–59). तासात कोणत्या मिनिटाला job चालतो. 0 म्हणजे तासावर, 30 म्हणजे अर्ध्या वेळेला, */5 म्हणजे प्रत्येक पाच मिनिटांनी (00, 05, 10, ...) आणि 15,45 म्हणजे quarter past आणि quarter to.
    2. Hour (0–23). 24-तास घड्याळावर दिवसाचा कोणता तास. 0 म्हणजे मध्यरात्र, 9 म्हणजे सकाळी 9, 17 म्हणजे संध्याकाळी 5. Ranges (9-17 business hours साठी) आणि step values (*/2 प्रत्येक दुसऱ्या तासासाठी) minutes प्रमाणेच कार्य करतात.
    3. Day of month (1–31). कोणत्या calendar day ला चालवायचे. 1 म्हणजे महिन्याचा 1 तारीख, * म्हणजे प्रत्येक दिवस, 1,15 म्हणजे 1 आणि 15. 31 बद्दल सावध रहा — जे महिने 31 दिवसांचे नाहीत ते शांतपणे skip होतात.
    4. Month (1–12 किंवा JAN–DEC). कोणत्या महिन्यांत चालवायचे. * म्हणजे प्रत्येक महिना, 1,7 म्हणजे जानेवारी आणि जुलै, 1-3 म्हणजे फक्त Q1. तीन-अक्षरी महिना नावे बहुतेक implementations मध्ये case-insensitive आहेत.
    5. Day of week (0–7, जेथे 0 आणि 7 दोन्ही रविवार). Fire करणे specific weekdays पुरते मर्यादित करतो. 1-5 म्हणजे सोमवार ते शुक्रवार, 0,6 म्हणजे weekend, MON-FRI बहुतेक parsers मध्ये कार्य करते. जेव्हा day-of-month आणि day-of-week दोन्ही specific values वर सेट असतात, तेव्हा classic cron एकतर जुळण्यावर fire करतो (logical OR), जे प्रत्येक वेळी लोकांना आश्चर्यचकित करते.

    Cron expression parser का वापरावा?

    • Deploy आधी शांत misread पकडा. `0 2 */3 * *` हे expression प्रत्येक तीन मिनिटांनी नाही — प्रत्येक तिसऱ्या दिवशी रात्री 2 वाजता fire होते — येथे paste करा आणि production ला ship करण्यापूर्वी तुम्हाला plain भाषेत दिसेल.
    • बहुतेक cloud schedulers default म्हणून UTC मध्ये चालतात. तुमच्या local zone मध्ये पुढील दहा fire times preview केल्याने कोणाला रात्री 3 वाजता page येण्यापूर्वी off-by-one-hour DST drift surface होतो.
    • `@daily`, `@weekly` आणि `@monthly` सारखे shortcuts सोयीचे पण अस्पष्ट असतात. Parser तुम्हाला underlying five-field form दाखवतो जेणेकरून नक्की काय scheduled झाले ते तुम्हाला कळेल.
    • Field-by-field builder तुम्हाला एका वेळी एक column schedule compose करू देतो आणि human description live update होताना पाहू देतो, जे cron man page दहाव्यांदा पुन्हा वाचण्यापेक्षा खूप जलद आहे.

    Cron expressions कुठे वापरले जातात?

    Cron syntax सर्वत्र दिसतो जेथे job clock वर repeat होणे आवश्यक असते. तीन सर्वात सामान्य surfaces, प्रत्येकाच्या प्रसिद्ध gotcha सह:

    • Backup schedules. Classic `crontab -e` entry जी रात्री 2 AM ला database S3 वर dump करते, किंवा प्रत्येक महिन्याच्या 1 तारखेला `pg_dump` archive rotate करते. `0 2 * * * /usr/local/bin/backup.sh` सारखी ओळ इतिहासातील कोणत्याही cron ओळीपेक्षा जास्त Linux servers वर ship झाली आहे. Minute आणि hour बरोबर करा, stderr कुठेतरी durable redirect करा आणि तुम्ही manual checklist ची जागा fire-and-forget script ने घेतली आहे.
    • GitHub Actions `schedule` triggers. `.github/workflows/*.yml` मधील `on.schedule.cron` key standard five-field cron स्वीकारतो, परंतु job नेहमी UTC मध्ये चालतो आणि runner queue busy असल्यास GitHub शांतपणे fire-time skip करेल. Common pattern: `cron: '0 9 * * 1-5'` Monday-through-Friday digest UTC वेळी सकाळी 9 वाजता पाठवण्यासाठी. प्रथम येथे तुमच्या local zone मध्ये preview करा जेणेकरून BST मध्ये 10 AM ला landing होणारी 9 AM London digest तुम्ही promise करणार नाही.
    • AWS EventBridge Scheduler. EventBridge cron expressions year साठी सहावे field घेतात आणि day-of-month किंवा day-of-week field पैकी एकात `*` ऐवजी `?` अनिवार्य करतात — `cron(0 9 ? * MON-FRI *)` हे classic weekday 9 AM standard cron चे EventBridge translation आहे. Scheduled Lambda invocations, ECS task runs आणि Step Function state-machine starts साठी वापरले जाते; classic cron syntax शी misalignment CloudFormation deploys मध्ये `ValidationException` errors चे नंबर-एक source आहे.

    खरे cron expression कसे दिसते?

    0 9 * * 1-5 घ्या — प्रत्येक कामाच्या दिवशी सकाळी 9:00 वाजता fire होते. Fields डावीकडून उजवीकडे वाचताना: 0 म्हणजे तासाचे शून्यवे मिनिट, 9 म्हणजे 24-तास घड्याळावर सकाळी 9, day-of-month वर * म्हणजे प्रत्येक calendar day, month वर * म्हणजे प्रत्येक महिना, आणि day-of-week वर 1-5 firing सोमवार ते शुक्रवार पुरते मर्यादित करते (standard cron numbering मध्ये 1 = सोमवार). ते वरील input मध्ये paste करा आणि parser सोमवार ते शुक्रवार, सकाळी 09:00 वाजता confirm करतो तुम्ही निवडलेल्या IANA zone मध्ये पुढील दहा fire dates render करून. AWS EventBridge syntax मधील तोच intent cron(0 9 ? * MON-FRI *) आहे — शेवटी year field आणि standard cron जेथे * वापरेल तेथे ? लक्षात घ्या. Quartz expression (leading seconds सह six-field) म्हणून तोच intent 0 0 9 ? * MON-FRI आहे. तीन वेगळे platforms, तीन वेगळे surface forms, एक underlying schedule.

    Cron expressions नक्की एका प्रकारे unforgiving आहेत: typo तुम्हाला syntactically valid schedule देतो जे चुकीच्या वेळी fire होते, code review मध्ये कोणतीही error नाही. `0 0 1 * *` वाचून ते 1 जानेवारीला नाही — प्रत्येक महिन्याच्या 1 तारखेला मध्यरात्री चालते हे जाणणे practice लागते. वरील parser ती practice दहा-सेकंद sanity check मध्ये बदलतो — expression paste करा, भाषा वाचा, तुमच्या local zone मध्ये पुढील दहा fire times scan करा आणि YAML ship करा हे जाणून की cron line commit message काय म्हणतो ते खरोखर करते.

    5-field आणि 6-field cron मधील फरक काय आहे?

    Five-field cron हा one-minute resolution असलेला classic Unix grammar आहे. Six-field cron sub-minute scheduling साठी leading seconds column जोडतो — Quartz आणि Spring च्या @Scheduled द्वारे वापरला जातो. AWS EventBridge देखील six fields वापरते, परंतु त्याचा extra column leading seconds नाही — trailing year आहे.

    @hourly, @daily आणि @weekly चा अर्थ काय?

    1987 मध्ये Vixie-cron ने introduced केलेले nicknames. @hourly = 0 * * * *, @daily = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. @reboot boot वेळी एकदा fire होतो. GitHub Actions आणि EventBridge हे aliases नाकारतात.

    Cron मध्ये रविवार day 0 आहे की day 7?

    Classic Vixie cron मध्ये दोन्ही — 0 आणि 7 दोन्ही स्वीकारले जातात जेणेकरून 5-7 सारखे ranges Friday-to-Sunday म्हणून नैसर्गिकपणे वाचतात. सोमवार नेहमी 1, शनिवार नेहमी 6. Quartz आणि AWS EventBridge वेगळी convention वापरतात: 1-7 रविवार 1 सह. गृहीत धरण्यापूर्वी platform docs तपासा.

    Cron daylight saving time कसे हाताळतो?

    Engine च्या timezone वर अवलंबून आहे. UTC मध्ये (EventBridge, Kubernetes आणि GitHub Actions वर default) DST अस्तित्वात नाही. Local DST zone मध्ये, classic Vixie cron spring-forward gap दरम्यान jobs skip करतो आणि fall-back दरम्यान दोनदा चालवतो; systemd timers एकदाच fire होतात.