Dead Man's Switch لـ Cron: ازاي تعرف لما السكربت اليومي بيفشل بصمت

الـ cron line القديم:

بعد التعديل (ping pass فقط لما السكربت ينجح):

لو عايز تتبّع الفشل والبدء كمان (مش بس الغياب):

الـ /start بيقول للسيرفر "ابتديت"، الـ URL الأساسي بيقول "نجحت"، والـ /fail بيقول "فشلت". ده بيدّيك تايم لاين كامل لكل run مع مدة التنفيذ الفعلية.

أرقام من الإنتاج

على سيرفر Hetzner CX22 صغير بيشغّل 14 cronjob يومي (backups، certbot، rotation، sitemap، إلخ):

• زمن curl للـ pingback من فرانكفورت لـ Healthchecks: 180 إلى 320 مللي ثانية. مش هيأثر على السكربت.
• حجم الترافيك الإضافي: أقل من 2 كيلوبايت لكل ping.
• نسبة الـ false positives بـ grace period 60 دقيقة لـ backup طوله ساعتين: صفر في 90 يوم.
• متوسط زمن اكتشاف فشل صامت قبل Healthchecks: 3 إلى 9 أيام (لو في حد لاحظ أصلاً). بعدها: أقل من ساعة و 5 دقايق.
• وقت الإعداد الأولي للـ check الأول: 7 دقائق. كل check إضافي بعد كده: 90 ثانية.

الـ trade-offs

بتكسب: تنبيه فوري على فشل صامت + تايم لاين تاريخي لكل run + ما عملتش push لأي infra جديدة على السيرفر. بتخسر: dependency خارجي على service تالت. لو Healthchecks نفسه down (نادر، uptime معلن 99.95%)، مش هتلاقي ping history لحد ما يرجع.

الحل لو الـ dependency ده مزعجك: الـ self-hosted version مفتوحة المصدر على GitHub. التكلفة: container صغير + Postgres + 256MB RAM. الافتراض هنا إن عندك أقل من 50 cron job. أكتر من كده، فكّر في job orchestrator زي Airflow أو Prefect — Healthchecks ما اتصمّمش لإدارة DAGs ولا dependencies بين الجوبز، اتصمّم لإجابة سؤال واحد: "هل ده اشتغل ولا لا".

متى لا تستخدم هذه الطريقة

ما تستخدمهاش لما:

• السكربت بيشتغل بفترات غير منتظمة (event-driven مثلاً). الـ schedule مش هيكون deterministic، والـ grace period هيبقى صعب يتضبط بدون false positives.
• محتاج تتبّع متغيرات داخل السكربت — عدد rows اتعملها backup، حجم الملف الفعلي، dropped queries. دي شغلانة metrics مش uptime. استخدم Prometheus Pushgateway أو StatsD.
• الجوب بيشتغل على edge device بدون internet ثابت. الـ ping هيفشل لأسباب شبكة مش لأسباب السكربت، فالتنبيهات هتفقد معناها.
• السكربت بيشتغل آلاف المرات في الدقيقة (queue worker مثلاً). Healthchecks ما اتعملش لـ high-frequency pings، استخدم heartbeat metric في Prometheus.

مصادر

• Healthchecks.io Documentation — Cron Job Monitoring: healthchecks.io/docs/
• Healthchecks Self-Hosted (مفتوح المصدر): github.com/healthchecks/healthchecks
• Linux cron(8) و crontab(5) man pages.
• NIST SP 800-92 — Guide to Computer Security Log Management، قسم "absence of expected events" كأساس نظري للـ Dead Man's Switch في الأنظمة.
• Google SRE Book — الفصل الخاص بـ Monitoring Distributed Systems، مبدأ "alert on symptoms, not causes".

الخطوة التالية

افتح أول crontab عندك دلوقتي بـ crontab -l. اختار سكربت واحد بس — يفضّل الأهم (backup أو certbot renewal أو DB dump). سجّل حساب على healthchecks.io، اعمل check واحد، عدّل السطر بإضافة && curl -fsS https://hc-ping.com/...، واستنى 24 ساعة. لو وصلك ping أخضر، الموضوع شغّال. لو جالك تنبيه فشل، يبقى اكتشفت أول bug صامت بدون ما تخسر داتا فعلية.