المستوى: متوسط — للمطورين اللي بيكتبوا cron jobs على سيرفرات Linux ومش متأكدين هي شغّالة فعلاً ولا واقفة بصمت.

سكربت الـ backup اليومي بتاعك ممكن يكون فاشل من 9 أيام وانت ما تعرفش. ما فيش error في Sentry، ما فيش email، ما فيش حاجة. الكارثة بتكتشفها لما العميل يطلب استرجاع داتا الأسبوع اللي فات — وتلاقي آخر نسخة احتياطية عمرها أسبوعين.

Dead Man's Switch: تنبيه عكسي للسكربتات المنسية

في السطور الجاية، هتشوف الفرق بين الـ monitoring التقليدي و Dead Man's Switch، وهتركّب نظام تنبيه شغّال على Cron job في 7 دقايق باستخدام Healthchecks.io، وهتعرف الحالات اللي ما ينفعش تستخدمه فيها.

المشكلة باختصار

الـ monitoring اللي إنت متعوّد عليه — Sentry، Datadog، email alerting — كله بيفترض إن السكربت اشتغل أصلاً وحصلت فيه مشكلة. لكن لو السكربت ما اتشغّلش من البداية، ما فيش حاجة هتنبّهك. الأسباب الشائعة في الإنتاج:

• السيرفر اتعمله reboot وما رجعش الـ cron service بعد التحديث.
• المستخدم اللي شغّاله الـ cronjob اتشال أو الـ login shell بتاعه اتغيّر لـ /sbin/nologin.
• القرص امتلى فالـ log ما اتكتبش أصلاً والسكربت crashed قبل أي خطوة.
• الـ timezone في السيرفر اتغيّر فجأة، الجدول ابتدى يعدّي بدون تنفيذ.
• عدّلت في الـ crontab ونسيت سطر بحرف غلط، فالـ parser رفض الملف كله بصمت.

مثال بسيط: ساعة جدّك بتاعت الحائط

تخيّل ساعة حائط قديمة محتاجة كل 24 ساعة حد يلفّها بمفتاح. لو نسي أي حد يلفّها يوم، هتقف. الطريقة العادية إنك تشوفها كل صباح وتتأكد. لكن لو سافرت أسبوع، الساعة ممكن تقف 6 أيام وما تعرفش غير لما ترجع.

الحل العكسي: حط بجانبها جرس مربوط بسلك معلّق في يدك. كل 24 ساعة لازم تشدّ السلك. أول ما تنسى تشدّه، الجرس بيدق فوراً. ده بالظبط مبدأ Dead Man's Switch — مش بتستنى رسالة "في مشكلة"، إنت بتستنى غياب رسالة "أنا كويس".

التعريف العلمي

Dead Man's Switch هو نمط تصميم لآلية تنبيه عكسية. بدل ما الـ entity تبعت إشارة "في مشكلة" لما تفشل، الـ entity بتبعت إشارة "أنا شغّال" بشكل دوري. لو الإشارة ما وصلتش خلال نافذة زمنية محددة (الـ schedule + grace period)، النظام يفترض إن في خلل ويطلق التنبيه.

المبدأ ده أصله من قطارات السكة الحديد في القرن 19: لو السائق فقد وعيه، يده بتسيب الذراع، فالقطار يفرمل أوتوماتيكياً. Healthchecks.io بيطبّق نفس المبدأ على Cron jobs: كل سكربت عنده رابط ping خاص بـ UUID. السكربت بعد ما يخلّص شغله بنجاح بيعمل HTTP GET للرابط ده. لو الـ ping ما وصلش خلال الـ grace period، Healthchecks بيبعت تنبيه فوري على Telegram أو Slack أو email أو webhook مخصص.

الإعداد العملي في 4 خطوات

1. سجّل حساب مجاني على healthchecks.io. الـ free tier بيدّيك 20 check و SMS مدفوع، كافي لـ small team.
2. اعمل check جديد. حدد الـ schedule (مثلاً 0 3 * * * يعني كل يوم الساعة 3 فجر) و grace period (60 دقيقة لسكربت backup كبير معقول).
3. من تبويب Integrations اربط Telegram bot أو Slack webhook. التفعيل ثواني.
4. عدّل الـ cron line في السيرفر يبعت ping بعد نجاح السكربت.

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

0 3 * * * /usr/local/bin/backup.sh

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

# ping بعد نجاح السكربت فقط
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://hc-ping.com/UUID-بتاعك > /dev/null

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

#!/bin/bash
URL="https://hc-ping.com/UUID-بتاعك"

# علّم البداية
curl -fsS -m 10 --retry 3 "$URL/start" > /dev/null

# شغّل السكربت الفعلي وامسك exit code
if /usr/local/bin/backup.sh; then
  curl -fsS -m 10 --retry 3 "$URL" > /dev/null
else
  curl -fsS -m 10 --retry 3 "$URL/fail" > /dev/null
fi

الـ /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 صامت بدون ما تخسر داتا فعلية.