اعمل Uptime Monitor مجاني بتنبيه Telegram وGitHub Actions

مستوى القارئ: متوسط

هتطلع من المقال ده بمراقب uptime عملي: يفحص موقعك كل 5 دقائق، ويبعث لك رسالة Telegram لما الموقع يقع أو يرد ببطء.

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

لو عندك موقع صغير أو landing page أو API داخلي، غالبًا مش محتاج تبدأ بخدمة مراقبة مدفوعة. المشكلة إنك برضه محتاج تعرف بسرعة لو الموقع وقع. الانتظار لحد ما عميل يكلّمك هو أسوأ طريقة.

السيناريو الواقعي هنا: موقع بيزوره 20K زائر يوميًا، وصفحة الدفع فيه بتعمل timeout لمدة 12 دقيقة. لو متوسط الطلبات 14 طلب في الدقيقة، فأنت ممكن تخسر حوالي 168 محاولة شراء قبل ما تلاحظ المشكلة. مراقب بسيط ينبهك خلال 5 دقائق يقلل الخسارة بشكل واضح.

الافتراض إن عندك موقع واحد أو 3 مواقع، ومحتاج تنبيه سريع، مش نظام incident management كامل. لو عايز SLA رسمي، escalation، وon-call rotations، استخدم أداة متخصصة.

الفكرة بالظبط

بدل ما تشغّل سيرفر مخصوص للمراقبة، هنستخدم GitHub Actions كـ scheduler. الـ workflow يشتغل كل 5 دقائق. يشغّل سكربت Python. السكربت يعمل GET على الموقع بمهلة 10 ثواني. لو الرد مش 2xx أو الزمن أعلى من الحد اللي حددته، يبعت رسالة Telegram.

الـ trade-off هنا واضح: بتكسب حل مجاني وسريع الإعداد. بتخسر دقة أعلى في التوقيت، لأن GitHub Actions ممكن يتأخر وقت الضغط، وبتخسر تاريخ metrics طويل إلا لو خزّنته بنفسك.

الخطوات التنفيذية

1. اعمل Telegram bot من BotFather وخد التوكن.
2. ابعت رسالة للبوت من حسابك، ثم هات chat_id من تحديثات البوت أو من أداة موثوقة تعرضه لك.
3. في GitHub repo جديد، أضف secrets باسم TELEGRAM_BOT_TOKEN و TELEGRAM_CHAT_ID.
4. أضف secret ثالث باسم CHECK_URL وقيمته رابط الموقع، مثل https://example.com/health.
5. أنشئ ملف monitor.py في جذر المشروع.
6. أنشئ workflow داخل .github/workflows/uptime.yml.
7. اختبره يدويًا أول مرة من تبويب Actions قبل الاعتماد عليه.

سكربت الفحص

ركز في نقطتين: استخدم timeout صريح، ولا تعتبر أي status code ناجح. الأفضل إن endpoint الصحة يرجع 200 فقط عندما التطبيق والـ DB والخدمات الأساسية شغالة.

import os
import time
import requests

CHECK_URL = os.environ["CHECK_URL"]
BOT_TOKEN = os.environ["TELEGRAM_BOT_TOKEN"]
CHAT_ID = os.environ["TELEGRAM_CHAT_ID"]
MAX_MS = int(os.getenv("MAX_RESPONSE_MS", "1500"))

def send_telegram(message: str) -> None:
    url = f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage"
    requests.post(
        url,
        json={"chat_id": CHAT_ID, "text": message},
        timeout=10,
    ).raise_for_status()

def main() -> None:
    started = time.perf_counter()
    try:
        response = requests.get(CHECK_URL, timeout=10)
        elapsed_ms = int((time.perf_counter() - started) * 1000)

        if response.status_code < 200 or response.status_code >= 300:
            send_telegram(
                f"DOWN: {CHECK_URL} returned {response.status_code} in {elapsed_ms}ms"
            )
            raise SystemExit(1)

        if elapsed_ms > MAX_MS:
            send_telegram(
                f"SLOW: {CHECK_URL} took {elapsed_ms}ms, limit is {MAX_MS}ms"
            )
            raise SystemExit(1)

        print(f"OK: {CHECK_URL} responded in {elapsed_ms}ms")

    except requests.RequestException as exc:
        send_telegram(f"DOWN: {CHECK_URL} failed with {type(exc).__name__}: {exc}")
        raise SystemExit(1)

if __name__ == "__main__":
    main()

Workflow بتاع GitHub Actions

GitHub Actions بيدعم تشغيل workflow بجدول زمني باستخدام cron. في المثال ده التشغيل كل 5 دقائق. لو عايزه كل دقيقة، الطريقة دي مش مناسبة. خليك فاكر إن التوقيت الفعلي ممكن يتأخر، فاعتبرها مراقبة عملية لمشاريع صغيرة، مش نظام real-time.

name: uptime-monitor

on:
  workflow_dispatch:
  schedule:
    - cron: "*/5 * * * *"

jobs:
  check:
    runs-on: ubuntu-latest
    timeout-minutes: 2
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: pip install requests==2.32.3

      - name: Check website
        env:
          CHECK_URL: ${{ secrets.CHECK_URL }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
          MAX_RESPONSE_MS: "1500"
        run: python monitor.py

التحقق من أنه يعمل

اختبر 3 حالات بدل ما تثق في السكربت من أول مرة. الأولى: حط رابط صحيح، لازم تشوف OK في logs. الثانية: حط رابط غير موجود مؤقتًا، لازم توصلك رسالة DOWN. الثالثة: قلل MAX_RESPONSE_MS إلى 10، لازم توصلك رسالة SLOW.

رقم عملي: لو الجدول كل 5 دقائق والـ workflow بدأ خلال دقيقة إضافية، فزمن اكتشاف المشكلة غالبًا بين 1 و6 دقائق. ده كافي لموقع محتوى أو SaaS صغير. مش كافي لمنصة دفع كبيرة تحتاج تنبيه خلال ثواني.

Trade-offs وما يجب الانتباه له

• بتكسب إعداد سريع بدون سيرفر. بتخسر تحكم كامل في زمن التشغيل.
• بتكسب تنبيه Telegram مباشر. بتخسر قنوات escalation مثل PagerDuty أو Opsgenie.
• بتكسب كود واضح تملكه بالكامل. بتخسر dashboard جاهز لتاريخ الحوادث.
• بتكسب تكلفة شبه صفرية. بتخسر اعتمادية أعلى من خدمة مراقبة متخصصة.

أفضل تحسين لاحق هو تخزين نتيجة كل فحص في ملف JSON أو Google Sheet. لكن ابدأ بالإنذار الأول. اللي بيحصل فعلاً إن معظم الفرق تؤجل المراقبة لأنها عايزة حل كامل، فتفضل بلا تنبيه من الأساس.

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

لا تستخدمها لو عندك SLA رسمي، أو أكثر من 20 endpoint مهم، أو تحتاج تنبيه خلال أقل من دقيقة، أو تحتاج on-call schedule بين أعضاء الفريق. لا تستخدمها أيضًا لو الموقع نفسه بيحجب GitHub-hosted runners. في الحالات دي استخدم Uptime Kuma على VPS أو خدمة مثل Better Stack أو Pingdom.

المصادر

• GitHub Docs: schedule event في GitHub Actions
• Telegram Bot API: sendMessage
• Requests documentation: timeouts

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

الخطوة التالية: اعمل repository باسم uptime-monitor، ضيف الأسرار الثلاثة، وشغّل workflow_dispatch مرة واحدة يدويًا. لو وصلك تنبيه عند رابط خاطئ، يبقى الأساس شغال.