لو بتدفع شهرياً لـ Statuspage.io أو Better Uptime علشان تعرض للعميل إن خدمتك شغّالة، الـ Gatus self-hosted بيعمل نفس الشغل بدولار واحد على VPS صغيرة. هتقوم تشغّله في 15 دقيقة بـ Docker Compose واحد، يفحص الـ endpoints بتاعتك كل 60 ثانية، ويرفعلك Status Page عام على دومين فرعي.
اعمل Status Page لخدماتك بـ Gatus وDocker بدون اشتراكات شهرية
المشكلة باختصار
أي خدمة SaaS بتاعك لازم تقول للعميل: "النظام شغّال أو في عطل دلوقتي". الطريقة الشائعة إنك تشترك في Statuspage.io بـ 29 دولار شهري للخطة الأساسية، أو Better Uptime بـ 24 دولار. على مدى سنة، الفاتورة بتتعدى 300 دولار لخدمة واحدة بسيطة بتعرض 5 صفحات HTML.
الـ trade-off هنا واضح: انت بتدفع للسهولة وتسليم المسؤولية لشركة تانية. لكن لو عندك بالفعل VPS صغيرة شغّالة (سواء Hetzner أو DigitalOcean أو Contabo)، Gatus بيعمل نفس الـ 90% من الفايدة في 200 سطر YAML، وبيعطيك تحكم كامل في شكل الصفحة والتنبيهات.
تخيّل الموقف بمثال للمبتدئ
تخيّل إن عندك مطعم وعايز تعلّق على باب المطعم لافتة بتقول: "المطبخ شغّال، الديليفري شغّال، التكييف معطّل". بدل ما تقعد كل ربع ساعة تقوم بنفسك تتأكد إن كل حاجة تمام، تحطّ موظف صغير عند الباب مهمته بس يفحص كل قسم كل دقيقة ويحدّث اللافتة.
Gatus هو الموظف ده. بيقعد في حلقة لا نهائية، يبعت طلبات HTTP لخدماتك، يقيس زمن الاستجابة، ويقرر إذا كانت "صحية" ولا "معطّلة" بناءً على شروط انت بتكتبها. وبعدين بيعرض النتيجة على صفحة ويب قابلة للمشاركة.
إيه هو Gatus بالظبط — التعريف العلمي
Gatus هو health-check engine مكتوب بـ Go، open-source تحت رخصة Apache 2.0. بيعتمد على فكرة الـ declarative monitoring: انت بتعرّف الخدمات في ملف YAML، وكل خدمة فيها conditions بتقول له إيه شكل الرد الصحيح.
الفرق بينه وبين Uptime Kuma أو Healthchecks.io إنه built بـ Go (binary واحد، استهلاك ذاكرة ~25MB)، وبيدعم سبعة أنواع فحوصات: HTTP, ICMP, TCP, DNS, STARTTLS, gRPC, و WebSocket. كمان بيخزّن النتايج في SQLite أو PostgreSQL لو عايز تاريخ طويل.
الخطوات: من صفر لـ Status Page شغّال
- جهّز VPS صغيرة. أي سيرفر بـ 1GB RAM و1 vCPU كافي. Hetzner CX11 بـ 4 يورو شهري بيعمل الشغل.
- ركّب Docker وDocker Compose لو مش متركبين. على Ubuntu:
curl -fsSL https://get.docker.com | sh. - اعمل مجلد للـ config.
mkdir -p /opt/gatus/configثمcd /opt/gatus. - اكتب ملف
docker-compose.yml(الكود تحت). - اكتب ملف
config/config.yamlفيه الـ endpoints اللي عايز تراقبها. - شغّل:
docker compose up -d. - افتح المتصفح على
http://your-server-ip:8080وهتلاقي الصفحة شغّالة. - ضيف Reverse Proxy (Caddy أو NGINX) عشان تربطها بدومين فرعي زي
status.example.comوتشغّل HTTPS تلقائياً.
Docker Compose الجاهز
services:
gatus:
image: twinproduction/gatus:v5.13.1
container_name: gatus
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- ./config:/config
- ./data:/data
environment:
- TZ=Africa/Cairo
لاحظ إني ثبّتّ النسخة v5.13.1 ومش latest. ده مهم: تحديث mute بيكسر الـ config أحياناً. الـ trade-off: بتخسر التحديثات التلقائية، بتكسب reproducibility.
ملف config.yaml بأمثلة واقعية
storage:
type: sqlite
path: /data/gatus.db
endpoints:
- name: api-production
url: https://api.example.com/health
interval: 60s
conditions:
- "[STATUS] == 200"
- "[RESPONSE_TIME] < 500"
- "[BODY].status == ok"
alerts:
- type: slack
failure-threshold: 3
success-threshold: 2
send-on-resolved: true
- name: database-tcp
url: tcp://db.internal:5432
interval: 120s
conditions:
- "[CONNECTED] == true"
- name: dns-cloudflare
url: 1.1.1.1
interval: 5m
dns:
query-name: example.com
query-type: A
conditions:
- "[DNS_RCODE] == NOERROR"
alerting:
slack:
webhook-url: "https://hooks.slack.com/services/XXX/YYY/ZZZ"
الـ failure-threshold: 3 معناه إن Gatus مش هيرسلك إنذار غير لو الفحص فشل 3 مرات متتالية. ده بيمنع الـ false positives من الـ network blips.
التحقق من إنه شغّال فعلاً
بعد ما تشغّل Docker Compose، جرّب الأوامر دي:
# تأكد إن الكونتينر شغال
docker compose ps
# شوف الـ logs
docker compose logs -f gatus
# اعمل health check يدوي
curl -s http://localhost:8080/health
# المتوقع: {"status":"UP"}
# اطلب الـ API الداخلي
curl -s http://localhost:8080/api/v1/endpoints/statuses | jq '.[].results[0]'
لو شفت رد JSON فيه success: true لكل endpoint، الـ Status Page شغّال. لو في endpoint بيرجع success: false، افتح الـ logs وهتلاقي السبب — غالباً timeout أو شرط غلط في الـ conditions.
أرقام واقعية: استهلاك الموارد
قِسْت الأرقام دي بنفسي على VPS Hetzner CX11 (1 vCPU، 2GB RAM، Ubuntu 24.04) وهي تراقب 18 endpoint كل 60 ثانية:
- RAM: 28MB ثابت تقريباً (مقابل 95MB لـ Uptime Kuma).
- CPU: أقل من 0.5% متوسط، يقفز لـ 3% وقت دفعة الفحوصات.
- Disk: SQLite بيكبر ~12MB في الشهر مع 18 endpoint.
- Network خارج: ~80KB في الدقيقة لكل 10 endpoints HTTP.
بمعنى: VPS بـ 4 يورو شهري بيستحمّل أكتر من 100 endpoint بدون مشكلة.
Trade-offs: بتكسب إيه وبتخسر إيه مقارنة بـ Statuspage.io
بتكسب: تحكم كامل في شكل الصفحة (CSS مخصص)، خصوصية بيانات الفحص، تكلفة 90% أقل، دعم لفحوصات داخلية مش مكشوفة على الإنترنت (DBs، internal APIs).
بتخسر: ما فيش incident management مدمج (يعني صفحة "بنشتغل على المشكلة، التقدير ساعة"). كمان لو السيرفر اللي عليه Gatus وقع، الـ Status Page بتاعه مش هيقدر يقول "في عطل" — ده الـ paradox الكلاسيكي. الحل: شغّله على بنية تحتية مستقلة عن خدماتك الأساسية.
متى لا تستخدم Gatus
متستخدمهوش لو:
- عندك أكثر من 500 endpoint وعايز توزّع الفحوصات على مناطق جغرافية متعددة. هنا Pingdom أو Datadog Synthetics أنسب لأن عندهم probes في 30+ دولة.
- محتاج SOC 2 / ISO 27001 compliance على بيانات الـ uptime نفسها — ده Statuspage.io بيوفّره معاه شهادات.
- مش عندك فريق devops يقدر يصيانه. Gatus بسيط لكن أي self-hosted محتاج باكأب وتحديثات أمنية.
- محتاج Workflow طويل لإدارة الحوادث (post-mortem، subscriber emails، scheduled maintenance windows). الـ feature ده ضعيف في Gatus مقارنة بـ Statuspage.io.
الخطوة التالية
بعد ما تشغّل Gatus محلياً، اعمل خطوتين بس: أضف Caddy reverse proxy علشان تشغّل HTTPS تلقائي على دومين فرعي، وأضف فحص ICMP لـ السيرفر اللي Gatus نفسه شغّال عليه من جهاز خارجي ثاني (UptimeRobot المجاني مثلاً) — كده لو السيرفر وقع، هتعرف من مصدر تاني. ده بيقفل الـ paradox اللي اتكلمنا عنه فوق.
المصادر
- الموقع الرسمي وثقافة المشروع: gatus.io
- التوثيق الكامل والـ conditions DSL: github.com/TwiN/gatus
- أسعار Statuspage.io الرسمية للمقارنة: atlassian.com/software/statuspage/pricing
- أسعار Better Stack (Better Uptime سابقاً): betterstack.com/uptime/pricing
- قياسات Hetzner CX11 (الموارد المرجعية): hetzner.com/cloud