مولّد Cron Expressions

منذ ظهور Cron في نظام Unix أواخر السبعينيات وهو يُجدول مهام الخوادم: نسخ احتياطية في منتصف الليل، تنظيف ملفات مؤقتة كل ساعة، إرسال تقارير أسبوعية صباح الأحد. خمس خانات بسيطة فصلت بينها مسافات تختصر سنوات من الكود الذي لو كتبته بنفسك لاحتاج خيوطاً ومؤقّتات وحالات حواف لا تنتهي. ولأنّ كل بيئة حديثة — من خادم Linux صغير إلى AWS EventBridge و Kubernetes CronJob و GitHub Actions — تتحدّث «لغة Cron»، فإنّ إتقانها هو استثمار يدوم.

المشكلة الوحيدة: قراءة 0 */4 * * 1-5 ليست بديهية. هذه المقالة تشرح البنية الكاملة بالعربية، تفكّك كل خانة، تستعرض الأنماط الأكثر استخداماً، وتنبّهك للفروقات الخفيّة بين Linux و AWS و Spring قبل أن تكتشفها في الإنتاج.

تعبير Cron القياسي خمس خانات تفصلها مسافات، بالترتيب التالي من اليسار إلى اليمين: الدقيقة ثم الساعةثم اليوم في الشهر ثم الشهر ثم اليوم في الأسبوع. القاعدة الذهبية: لو وضعت نجمة * في خانة فأنت تقول «كل القيم المسموحة». ولو وضعت رقماً محدّداً فأنت تقول «هذه القيمة فقط».

مثال: 30 14 * * * يعني الدقيقة 30 من الساعة 14 (يعني 2:30 ظهراً)، في أي يوم من أي شهر من أي يوم في الأسبوع — أي يومياً 2:30 ظهراً. أمّا 0 0 1 * * فالدقيقة صفر من الساعة صفر (منتصف الليل)، في اليوم الأول من الشهر، في أي شهر، في أي يوم أسبوع — أي بداية كل شهر.

داخل كل خانة يمكنك استخدام عدة عوامل تجعل التعبير أقوى بكثير من مجرد رقم واحد. أولاً النجمة * وتعني «كل القيم». ثانياً الشرطة - وتمثل مدى: 1-5 في خانة اليوم الأسبوعي تعني من الإثنين إلى الجمعة (في Linux القياسي حيث الأحد = 0). ثالثاً الفاصلة , للقيم المتعدّدة المنفصلة: 0,15,30,45 في خانة الدقيقة يعني أربع مرات في الساعة.

رابعاً الشرطة-المائلة / وهي الأهم عملياً: تعني «كل n». */15 في خانة الدقيقة يعني كل 15 دقيقة، */6 في خانة الساعة يعني كل 6 ساعات. ويمكن دمجها مع مدى: 0-30/5 يعني كل 5 دقائق لكن فقط في النصف الأول من الساعة. خامساً وأخيراً L (آخر) و W (أقرب يوم عمل) وهما إضافتان غير قياسية يدعمها Quartz و AWS لكن ليس Linux. L في خانة اليوم يعني آخر يوم في الشهر — مفيد لمهام نهاية الشهر دون عدّ 28 أو 30.

ليس كل «Cron» متشابهاً. crontab في Linux يستخدم خمس خانات. AWS EventBridge و CloudWatch Events يستخدم ستّ خانات (يضيف خانة السنة في النهاية، ولا يقبل نجمة في كل من اليوم واليوم الأسبوعي معاً — يجب أن تضع? في إحداهما). Quartz (المستخدَم في Spring و ElasticSearch) يستخدم سبع خانات: الثانية + الدقيقة + الساعة + اليوم + الشهر + اليوم الأسبوعي + السنة، حيث الأحد = 1 وليس 0.

النتيجة: 0 9 * * 1 في Linux يعني الإثنين 9 صباحاً، لكن في Quartz يعني الأحد 9 صباحاً. وحين تنسخ تعبيراً من Stack Overflow تأكّد من بيئته. أداتنا أعلاه تستخدم لهجة Linux/Unix القياسية ذات الخمس خانات، وهي ما يدعمه Node.js (node-cron) و Vercel Cron و GitHub Actions و Kubernetes CronJob.

أكثر التعابير استخداماً في الإنتاج أبسط ممّا تتخيّل. * * * * *كل دقيقة (مفيد للاختبار، خطر في الإنتاج). */5 * * * *كل خمس دقائق (مناسب لـ health checks). 0 * * * *أعلى كل ساعة. 0 */6 * * * كل ست ساعات في الدقيقة صفر. 0 0 * * * منتصف كل ليلة (وقت ذهبي للنسخ الاحتياطية لأنّ الحمل أقل).

0 9 * * 0-4 أيام العمل في السعودية (الأحد للخميس) الساعة 9 صباحاً — مفيد لتقارير الصباح. 0 0 * * 0منتصف ليل الأحد (بداية الأسبوع في كثير من الشركات). 0 0 1 * *أول كل شهر — مناسب للفواتير وتقارير الشهر. 0 2 1 1 *أول كل سنة الساعة 2 فجراً — مناسب لـ archiving سنوي. 30 23 L * * آخر يوم في الشهر 11:30 مساءً (يتطلّب Quartz أو AWS).

Cron نفسه لا يعرف المناطق الزمنية — يعرف فقط الوقت المحلّي للخادم. إذا كان خادمك يعمل بـ UTC وكتبت 0 9 * * *متوقّعاً أن تُرسَل التقارير 9 صباحاً بتوقيت الرياض، ستُرسَل الساعة 12 ظهراً. خادم AWS Lambda الافتراضي UTC. كثير من حاويات Docker كذلك. هذا أكثر مصدر «المهام تشتغل في وقت غريب».

الحل في ثلاث طبقات. أولاً: اضبط المنطقة الزمنية للخادم نفسه (TZ=Asia/Riyadh) — لكن هذا قد يكسر تطبيقات أخرى. ثانياً، الأفضل: استخدم مكتبة مثل node-cron أو cron-parser التي تقبل timezone كخيار مستقل عن وقت النظام. ثالثاً: في AWS EventBridge اضبط schedule_expression_timezone صراحة. الأداة أعلاه تتيح لك تجربة أي منطقة زمنية والاطّلاع على التشغيلات القادمة الفعلية.

نشر تعبير Cron مكسور في الإنتاج يعني واحداً من سيناريوهَين: إمّا أنّه لن يعمل أبداً (وقد تكتشف ذلك بعد أسابيع حين يسأل أحد عن التقارير المفقودة)، أو سيعمل كثيراً جداً (وستفاجأ بفاتورة AWS مضاعفة). كلا السيناريوهَين كلفته أعلى من خمس دقائق اختبار مسبق.

ثلاث خطوات قبل أي نشر: (1) ألصق التعبير في الأداة أعلاه وتأكّد أنّ الوصف بالعربية يطابق نيّتك. (2) راجع التشغيلات العشرة القادمة — هل تبدو منطقية؟ هل المسافات بينها صحيحة؟ (3) في البيئة الفعلية، اجعل المهمة تكتب سطراً في log عند كل تشغيل ولو لأيام قليلة قبل تفعيلها فعلياً. هذه الدقائق توفّر أسابيع من التحقيق لاحقاً.

أولاً: مهام طويلة بتكرار قصير. لو كتبت * * * * *لمهمة تستغرق 90 ثانية، ستبدأ النسخة الثانية قبل أن تنتهي الأولى — تراكم سريع وانهيار. استخدم قفلاً (flockأو سجلّ في قاعدة بيانات) أو زِد الفاصل. ثانياً: عدم تسجيل المخرجات. cron لا يطبع شيئاً افتراضياً؛ وجّه stdout و stderr إلى ملف log (>> /var/log/myjob.log 2>&1) وإلا ستفقد كل أثر للأخطاء.

ثالثاً: الاعتماد على متغيّرات بيئة المستخدم — Cron يعمل بـ PATH مبسّط جداً. استخدم مسارات مطلقة أو حدّد PATH في بداية الـ crontab. رابعاً: نسيان منطقة الخادم الزمنية (راجع القسم السابق). خامساً: تعابير معقّدة لا تحتاجها — لو احتجت «كل ثلاثاء وخميس» اكتب 0 9 * * 2,4، لا تعقّد الأمر. سادساً: عدم اختبار نهاية الشهر — فبراير 30 غير موجود؛ 0 0 30 * * سيتخطّى فبراير تماماً.

Cron عبقري في ما صُمّم له: مهام دورية على فواصل زمنية ثابتة. لكنّه ليس الأداة الصحيحة لكل شيء. لو احتجت تشغيلاً مرّة واحدة في المستقبل، استخدم at في Linux أو setTimeout في Node أو SQS Delayed Messages في AWS. لو احتجت مهام موزّعة عبر عدة خوادم مع ضمان «مرّة واحدة فقط»، استخدم نظام طوابير حقيقي (Sidekiq, BullMQ, Celery) لا Cron على كل خادم — وإلا ستُنفَّذ المهمة مرّات بعدد الخوادم.

ولو احتجت جدولة مرنة معقّدة (مهام تعتمد على نتائج مهام أخرى، إعادة محاولة بسياسة backoff، رسوم بيانية اعتمادية)، انتقل إلى أدوات workflow حقيقية مثل Airflow أو Temporal. Cron يبدأ يصبح عبئاً حين يتجاوز عددك مئات المهام أو حين تحتاج رؤية مركزية لها. القاعدة: ابدأ بـ Cron، انتقل لغيره حين يبدأ يؤلمك.

خمس خانات صغيرة، خمسة عوامل، وعشرة أنماط — هذا 90% ممّا ستحتاجه من Cron طوال حياتك المهنية. الباقي مجرد تنويعات على نفس الموضوع. القاعدة الأهم: لا تنشر تعبيراً لم تختبره مسبقاً، ولا تثق بالمنطقة الزمنية الافتراضية. الأداة أعلاه تتيح لك بناء أي تعبير بصرياً، قراءة وصفه بالعربية، ورؤية التشغيلات العشرة القادمة قبل أن تلمس crontab -e.

في الـ 2026، قلّ ما تَجد فريقاً يَكتب في crontabمباشرةً على خادم إنتاجيّ. الأسباب: الخادم الواحد نقطة فشل، و تتبّع الفشل في /var/log/syslog مؤلم، و إعادة المحاولة عند الانقطاع غير مدمجة. البدائل السحابيّة الشائعة:

• AWS EventBridge Scheduler — يَستقبل تعابير cron قياسيّة، يُشغّل Lambda أو ECS أو Step Functions، و يَدعم المناطق الزمنيّة و إعادة المحاولة المُكوّنة.
• Google Cloud Scheduler — أرخص الخيارات (ثلاث وظائف مجّانيّة شهريّاً)، يُشغّل HTTP endpoints أو Pub/Sub أو Cloud Run.
• Vercel Cron Jobs — جدولة API routes في Next.js مباشرةً عبر vercel.json. مثالي لمواقع ثابتة تحتاج تحديثاً يوميّاً.
• GitHub Actions schedule — مجّاني للمستودعات العامّة، يَكفي لمهام DevOps الخفيفة (تنظيف branches، تحديث dependencies).

ميزة هذه الخدمات أنّها تُخزّن نتيجة كلّ تشغيل، تُرسل تنبيهات عند الفشل، و تُعيد المحاولة تلقائيّاً وفق سياسة backoff. تَعبير cron الذي بَنيته هنا يَنتقل كما هو — لكن خلفه بنية تحتيّة كاملة بدل خادم وحيد. للفرق السعوديّة على Vercel أو AWS الرياض، هذه الطبقة تَختصر ساعات من تجهيز systemd timers و monitoring.