Uptime Kuma کو Docker میں self-host کر کے monitoring کریں

آپ کیا بنا رہے ہیں

ایک چھوٹا سا container جو آپ کے دوسرے servers اور websites کو باہر سے monitor کرتا ہے اور جیسے ہی کوئی جواب دینا بند کرے، آپ کو email، Telegram، Discord یا webhook کے ذریعے فوراً مطلع کرتا ہے۔ Uptime Kuma ایک Node process ہے جو SQLite file استعمال کرتا ہے، اس لیے یہ 256-512 MB RAM میں آسانی سے چلتا ہے اور آپ کو live dashboard، history graphs اور public status page فراہم کرتا ہے۔ انسٹالیشن کے لیے دس سطروں پر مشتمل Compose file کافی ہے؛ اصل اہمیت اس بات کی ہے کہ آپ اسے کہاں چلاتے ہیں اور آیا test کے دوران آپ کے alerts کبھی فعال ہوئے ہیں یا نہیں، کیونکہ ایسا monitor جس کے آپ تک پہنچنے کی صلاحیت آپ نے کبھی ثابت نہ کی ہو، بالکل monitor نہ ہونے سے بھی بدتر ہے: یہ آپ کو تحفظ کا احساس دیتا ہے، جبکہ حقیقت میں کسی چیز کی نگرانی نہیں کر رہا ہوتا۔

مانیٹر کو ایسی جگہ چلائیں جہاں outage اس تک نہ پہنچ سکے

یہ فیصلہ پورے انتظام کو کامیاب یا ناکام بنا سکتا ہے، اس لیے اسے پہلے بیان کیا جا رہا ہے۔ Uptime Kuma کو اسی سرور پر نہ چلائیں جس کی services یہ monitor کرتا ہے۔ اگر monitor اسی سرور پر موجود ہو جسے یہ monitor کر رہا ہے، تو وہی واقعہ جس کا آپ کو پتا چلنا ہے، یعنی سرور کا بند ہو جانا یا memory ختم ہو جانا، monitor کو بھی بند کر دے گا۔ نتیجتاً کوئی alert نہیں ملے گا۔ بند monitor کی خاموشی بالکل ایسی ہی دکھائی دیتی ہے جیسے "سب کچھ ٹھیک ہے۔" ایک زیادہ باریک مسئلہ سرور کے فعال رہنے کی صورت میں بھی ہو سکتا ہے۔ localhost کی طرف اشارہ کرنے والا monitor workload کے ساتھ CPU شیئر کرتا ہے، اس لیے load بڑھنے پر اس کا اپنا check timeout ہو سکتا ہے اور target کو down قرار دے سکتا ہے۔ یہ false alarm ہوگا، جبکہ حقیقی users کو service معمول کے مطابق مل رہی ہوگی۔

اس لیے Uptime Kuma کو اس سرور سے مختلف VPS پر چلائیں جسے یہ monitor کرتا ہے۔ بہتر ہے کہ VPS مختلف provider یا region میں ہو، اور آپ کی services تک اسی طرح پہنچے جیسے users پہنچتے ہیں: public internet کے ذریعے، hostname سے۔ اس کے لیے سستا instance کافی ہے، اور ایک چھوٹا monitoring VPS آپ کے تمام servers کو monitor کر سکتا ہے۔ یہ علیحدگی ان heavy apps کے لیے خاص طور پر اہم ہے جو آپ host کرتے ہیں، کیونکہ PhotoPrism یا Immich کی photo library جیسی service نئی import کو index کرتے وقت گھنٹوں CPU کو مکمل طور پر مصروف رکھ سکتی ہے۔ اسی hardware پر چلنے والا monitor ایسی service کو down قرار دے سکتا ہے جو صرف مصروف ہو۔ خود Kuma کے بند ہونے کا پتا چلانے کے لیے کسی دوسرے سرور سے cron کے ذریعے push heartbeat شامل کریں۔

شرائطِ تیاری اور وسائل کا تعین

• ایک نیا Ubuntu 24.04 VPS، جس پر Docker Engine اور Compose v2 plugin، Docker کے اپنے apt repository سے نصب ہوں، نہ کہ docker.io distro package سے، کیونکہ اس میں عموماً پرانا ورژن ہوتا ہے۔
• 256 MB RAM سے چند monitors چل جاتے ہیں۔ درجنوں monitors کے ساتھ reverse proxy کے لیے 512 MB سے 1 GB RAM موزوں ہے، جبکہ checks کے درمیان CPU کا استعمال تقریباً نہ ہونے کے برابر رہتا ہے۔
• ایک domain اور DNS A record، مثلاً status.example.com جو VPS کی طرف point کرے، صرف اس صورت میں درکار ہے جب آپ TLS اور public status page چاہتے ہوں۔ Private instance میں DNS چھوڑ کر VPN یا SSH tunnel استعمال کیا جا سکتا ہے۔
• ان مقامات تک outbound network رسائی جہاں alerts بھیجے جائیں گے: آپ کے mail provider کو SMTP، یا Telegram اور Discord کو HTTPS۔

Compose فائل

اسے /srv/uptime-kuma/compose.yaml میں رکھیں۔

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

اسے شروع کریں اور پہلی boot کے logs دیکھیں:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

درست آغاز پر logs میں Listening on 3001 آتا ہے اور اس کے بعد خاموشی رہتی ہے۔ اس فائل میں تین چیزیں جان بوجھ کر ایسی رکھی گئی ہیں۔

127.0.0.1:3001:3001، 3001:3001 نہیں۔ Docker ports کو DNAT rules کے ذریعے publish کرتا ہے۔ یہ rules packet کو ufw تک پہنچنے سے پہلے evaluate ہوتے ہیں۔ اس لیے سادہ 3001:3001 آپ کے dashboard کو firewall سے قطع نظر public internet پر دستیاب کر دیتا ہے۔ loopback سے bind کرنے پر یہ private رہتا ہے اور صرف reverse proxy exposed رہتا ہے؛ private instance میں proxy کو چھوڑ کر self-hosted WireGuard VPN کے ذریعے 3001 تک رسائی حاصل کی جا سکتی ہے۔

/app/data پر named volume۔ Uptime Kuma کی محفوظ کی ہوئی تمام معلومات، SQLite database، monitors، notification settings اور status-page logos وہیں رہتے ہیں۔ volume ضائع ہونے پر admin screen خالی حالت سے شروع ہوتی ہے؛ backup کے لیے صرف اسی volume کو محفوظ کرنا ضروری ہے۔

Image کو major tag، :2 پر pin کیا گیا ہے۔ یہ موجودہ stable line ہے۔ اسے copy کرنے سے پہلے Docker Hub پر تازہ ترین major version دیکھیں، اور latest جیسے بدلتے ہوئے tag کو کبھی track نہ کریں، کیونکہ project اسے deprecated کر دیتا ہے۔ اس image پر major-version jump یک طرفہ database migration ہے۔ اسے routine pull کے دوران غیر ارادی طور پر شروع نہیں ہونا چاہیے؛ migration جان بوجھ کر trigger کریں۔

ایک اہم شرط یہ ہے کہ /app/data ایسے filesystem پر ہونا چاہیے جو POSIX file locks کو support کرتا ہو۔ مقامی Docker volume درست ہے، لیکن NFS پر SQLite database corrupt ہو جاتا ہے اور SQLITE_BUSY اور database disk image is malformed حاصل ہوتے ہیں۔ اس لیے network share استعمال نہ کریں۔

پہلی بار چلائیں: administrator account بنائیں

اپنے proxy کے ذریعے https://status.example.com پر instance کھولیں، یا SSH tunnel استعمال کریں: ssh -L 3001:127.0.0.1:3001 user@your-vps چلائیں اور http://localhost:3001 کھولیں۔ پہلا صفحہ administrator username اور password کے لیے setup form ہے؛ کوئی default login موجود نہیں۔ مضبوط اور حقیقی password منتخب کریں: یہ dashboard ان تمام چیزوں کے internal addresses اور tokens دیکھتا ہے جن کی آپ monitoring کرتے ہیں۔ بعد میں password بھول جائیں؟ اسے browser سے نہیں، host سے reset کریں:

sudo docker compose exec uptime-kuma npm run reset-password

اپنے notification channels پہلے شامل کریں اور ان کی جانچ کریں

Monitors شامل کرنے سے پہلے alerts ترتیب دیں، تاکہ ہر monitor بناتے وقت اس کے ساتھ ایک channel منسلک کیا جا سکے۔ Settings پھر Notifications پھر Setup Notification پر جائیں، اور ہر channel کے Test بٹن سے تصدیق کریں کہ message پہنچ رہا ہے۔ غیر آزمودہ notification وہ دوسرا عام سبب ہے جس کی وجہ سے setup خاموشی سے ناکام ہو جاتا ہے۔

Email (SMTP)۔ host، port، encryption، username، password، From اور To درج کریں۔ کام کرنے والے دو combinations 465 ہیں، جس میں "Secure" کو TLS/SSL پر set کیا جاتا ہے، یا 587 ہے، جس میں STARTTLS استعمال ہوتا ہے۔ Gmail اور two-factor auth والے زیادہ تر providers کے لیے app password بنانا ضروری ہے؛ عام account password Error: Invalid login: 535-5.7.8 Username and Password not accepted واپس کرتا ہے۔

Telegram۔ @BotFather کو message کریں، /newbot بھیجیں، اور bot token copy کریں۔ اپنے chat ID کے لیے نئے bot کو ایک بار message کریں، https://api.telegram.org/bot<token>/getUpdates کھولیں، اور JSON میں chat.id پڑھیں۔ جس bot کو آپ نے پہلے کبھی message نہ کیا ہو، اس کا getUpdates خالی ہوتا ہے اور اس کے پاس message بھیجنے کی کوئی جگہ نہیں ہوتی۔

Discord۔ channel میں Edit Channel پھر Integrations پھر Webhooks پھر New Webhook کھولیں، URL copy کریں، اور اسے Discord notification کے طور پر paste کریں۔

Generic webhook۔ دیگر تمام صورتوں کے لیے، مثلاً Slack incoming webhook، custom endpoint یا home-automation hook، Webhook type آپ کے فراہم کردہ URL پر JSON payload کو POST کرتا ہے۔ فہرست میں موجود تقریباً نوّے دیگر services میں سے زیادہ تر کے لیے bundled Apprise integration کافی ہے۔ اگر آپ outage اور اپنے phone کے درمیان کسی third party کو شامل نہیں کرنا چاہتے تو built-in ntfy type منتخب کریں اور اسے اپنے زیرِ انتظام ntfy server کی طرف point کریں۔ یہ آپ کے مکمل کنٹرول والے channel کے ذریعے handset تک notifications push کرتا ہے۔

مانیٹرز شامل کریں، ہر بار ایک قسم

Add New Monitor پر کلک کریں، ایک قسم منتخب کریں، پھر Friendly Name، Check Interval (60 سیکنڈ مناسب ہے)، Retries ("down" قرار دینے سے پہلے مسلسل ناکامیوں کی تعداد؛ 2 یا 3 رکھیں تاکہ ایک dropped packet پر page نہ ہو) اور فعال کی جانے والی notifications مقرر کریں۔ آپ درج ذیل اقسام استعمال کریں گے:

• HTTP(s). مکمل URL۔ سروس تب up سمجھی جاتی ہے جب status code منظور شدہ ہو (پہلے سے 200-299؛ اگر 301 یا 401 آپ کے لیے معمول کی بات ہے تو Accepted Status Codes میں حد وسیع کریں)۔ Websites اور APIs کے لیے یہ بنیادی monitor ہے۔
• HTTP(s) - Keyword. یہی request بھیجی جاتی ہے، لیکن "up" ہونے کے لیے body میں کوئی string موجود ہونا بھی ضروری ہے، یا Invert فعال نہ ہونے کی صورت میں وہ string غیر موجود ہونی چاہیے۔ اس سے ایسی صورت پکڑی جاتی ہے جب site 200 OK واپس کرے لیکن body میں "Error establishing a database connection" دکھا رہی ہو، جسے عام HTTP check صحت مند سمجھتا ہے۔ یہ اس browser front end کے لیے بھی درست check ہے جو الگ backend سے رابطہ کرتا ہے، مثلاً Jellyfin پر چلنے والی Halcyon video-store skin، جس کا page shell 200 اطمینان سے واپس کر دیتا ہے جبکہ اس کے پیچھے media server ناقابل رسائی ہو۔
• TCP Port. کسی host اور port سے بنیادی TCP connection۔ ان سروسز کے لیے جو HTTP استعمال نہیں کرتیں: 22 پر SSH، 5432 پر Postgres، 25 پر SMTP server، یا game server۔
• Ping. ICMP echo: کم لاگت میں reachability اور latency کی جانچ۔ لیکن بہت سے networks اور cloud firewalls ICMP کو drop کرتے ہیں، اس لیے سرخ ping monitor کا مطلب "host down" بھی ہو سکتا ہے یا "provider blocks ping" بھی؛ TCP monitor سے تصدیق کریں۔
• DNS. آپ کے نامزد کردہ resolver کے ذریعے record (A، AAAA، MX، TXT وغیرہ) resolve کرتا ہے اور answer کی تصدیق کر سکتا ہے۔ اس سے registrar یا DNS outage کا جلد پتا چل جاتا ہے۔
• Push. یہ inside-out monitor ہے، جس کی وضاحت اگلے حصے میں ہے۔

push (heartbeat) مانیٹر کے ذریعے cron job کی نگرانی

اوپر بیان کیا گیا ہر مانیٹر باہر سے آپ کی service تک رسائی حاصل کرتا ہے۔ push مانیٹر اس کے برعکس کام کرتا ہے: Uptime Kuma انتظار کرتا ہے، اور آپ کی job اسے اطلاع دیتی ہے کہ "میں چل چکی ہوں۔" Backup یا cron کی نگرانی کا یہ واحد قابلِ اعتماد طریقہ ہے۔ HTTP check صرف یہ بتاتا ہے کہ URL جواب دے رہا ہے، لیکن job ہی جانتی ہے کہ وہ مکمل ہوئی ہے۔

Push قسم کا مانیٹر بنائیں۔ Uptime Kuma ایک منفرد URL تیار کرتا ہے، مثلاً:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Heartbeat Interval کو job کے چلنے کے وقفے کے مطابق مقرر کریں اور اس میں تھوڑا اضافی وقت شامل کریں۔ پھر script کے آخر میں ایک سطر شامل کریں، تاکہ یہ صرف کامیابی کی صورت میں چلائی جائے:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

اگر job ناکام ہو جائے تو set -e curl سے پہلے abort ہو جاتا ہے۔ اگر server بند ہو تو job چلتی ہی نہیں۔ دونوں صورتوں میں heartbeat رک جاتی ہے، اور interval اور retries کی مدت گزرنے کے بعد Uptime Kuma مانیٹر کو down کر دیتا ہے اور آپ کو alert بھیجتا ہے۔ اس push token کو secret سمجھیں: جس کے پاس یہ token ہو، وہ جعلی healthy beat بھیج سکتا ہے۔

ایک public status page بنائیں

Status page صارفین کے لیے سامنے آنے والا view ہے۔ اس میں دکھایا جاتا ہے کہ کون سی services دستیاب ہیں اور ان کی حالیہ history کیا ہے، جبکہ آپ کا dashboard ظاہر نہیں ہوتا۔ Status Pages پھر New Status Page پر جائیں، اسے ایک نام اور slug دیں، یعنی public path، مثلاً /status/main۔ مطلوبہ monitors کو کھینچ کر "Websites" اور "APIs" جیسے groups میں رکھیں، logo اور مختصر description شامل کریں، پھر Save کریں۔ آپ page کو اس کے اپنے domain سے بھی bind کر سکتے ہیں، تاکہ status.example.com اسے براہِ راست serve کرے۔

دو احتیاطیں ضروری ہیں: صرف وہی monitors شامل کریں جنہیں public کرنے پر آپ آمادہ ہوں، کیونکہ status page سے ظاہر ہوتا ہے کہ کوئی service موجود ہے اور وہ دستیاب ہے یا نہیں؛ اور dashboard آپ کے login کے پیچھے رہتا ہے، جبکہ status page جان بوجھ کر public ہوتا ہے اور اسے authentication درکار نہیں ہوتی۔

اسے TLS کے ساتھ reverse proxy کے پیچھے رکھیں، اور websockets کا خیال رکھیں

Public instance کے لیے loopback-bound container کے سامنے reverse proxy رکھیں تاکہ TLS اور hostname فراہم کیے جا سکیں۔ وہ تفصیل جس میں اکثر غلطی ہوتی ہے یہ ہے: Uptime Kuma کا UI ایک live Socket.IO app ہے، اس لیے proxy کو WebSocket connection upgrade کرنا ضروری ہے۔ اگر یہ رہ جائے تو page load ہو جاتا ہے، لیکن connection قائم نہیں ہوتا؛ dashboard "Connecting..." پر رکا رہتا ہے، live heartbeats update نہیں ہوتے، اور browser console میں WebSocket connection to 'wss://.../socket.io/...' failed دکھائی دیتا ہے۔

nginx اور certbot install کریں، پھر وہ vhost لکھیں جو loopback port پر proxy کرے۔ فی الحال اسے port 80 پر رکھیں اور بعد میں certbot سے TLS شامل کروائیں؛ challenge، renewal timer اور اس کی failure modes کی وضاحت certbot اور nginx کے ساتھ Let's Encrypt certificates جاری کرنا میں موجود ہے۔

sudo apt install -y nginx certbot python3-certbot-nginx

اسے /etc/nginx/sites-available/status.example.com کے طور پر save کریں؛ WebSocket کی یہ دو lines اہم ہیں:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

Site enable کریں، configuration test کریں، پھر certbot کو block میں تبدیلی کرنے دیں تاکہ وہ 443 پر listen کرے، certificate شامل کرے اور HTTP-to-HTTPS redirect بھی بنائے:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Upgrade اور Connection "upgrade" کا جوڑا بنیادی حصہ ہے، جبکہ proxy_read_timeout 3600s nginx کو long-lived socket بند کرنے سے روکتا ہے؛ certbot اپنے تیار کردہ 443 block میں دونوں شامل کر دیتا ہے۔ اگر آپ پہلے ہی ایک proxy کے پیچھے متعدد containers چلا رہے ہیں تو automatic TLS کے ساتھ انہیں Traefik کے ذریعے route کرنا یہی کام container labels کے ذریعے کرتا ہے اور WebSocket upgrades کو default طور پر forward کرتا ہے۔

پورے vhost پر basic-auth نہ لگائیں، کیونکہ اس سے public status page اور /api/push endpoint بھی بند ہو جائیں گے۔ Uptime Kuma کا built-in login برقرار رکھیں، اور اگر یہ internet-facing ہے تو بار بار ناکام logins کو fail2ban کے ذریعے monitor کرنا شامل کریں۔ اگر dashboard کو کبھی public کرنے کی ضرورت نہیں تو proxy ہٹا دیں اور VPN کے ذریعے اس تک رسائی حاصل کریں۔

Certificate-expiry monitoring درست طریقے سے

ایک HTTP(s) monitor آپ کو TLS certificate کے expire ہونے سے پہلے بھی خبردار کر سکتا ہے۔ Certificate Expiry Notification منتخب کریں، پھر Uptime Kuma مقررہ تعداد دن پہلے alert دے گا۔ دو غلطیوں کی وجہ سے یہ غلط certificate پڑھ سکتا ہے۔ IP کے بجائے hostname کے ذریعے monitor کریں، کیونکہ SNI کے بغیر بھیجی گئی request کو server کا default certificate ملتا ہے، اور آپ کو Hostname/IP does not match certificate's altnames نظر آتا ہے۔ جس monitor سے expiry warnings مطلوب ہوں، اس میں Ignore TLS/SSL Error منتخب نہ کریں۔ یہ toggle self-signed internal hosts کے لیے ہے (unable to verify the first certificate، DEPTH_ZERO_SELF_SIGNED_CERT)، لیکن اسے فعال کرنے سے Uptime Kuma certificate کی بالکل جانچ نہیں کرتا، expiry بھی نہیں۔

بیک اپ: یہ ایک ہی ڈائریکٹری ہے

چونکہ تمام ڈیٹا /app/data میں موجود ہے، اس لیے بیک اپ اس volume کی وہ کاپی ہے جو container بند ہونے کے دوران بنائی جاتی ہے۔ اس طرح SQLite فائل consistent رہتی ہے:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

پہلے docker volume ls | grep kuma سے volume کا اصل نام معلوم کریں، کیونکہ Compose اس کے نام کے شروع میں project directory کا نام شامل کرتا ہے۔ پھر tarball کو off the box کاپی کریں، کیونکہ اسی VPS پر موجود بیک اپ صرف ایک کاپی ہے، بیک اپ نہیں۔ Restore کا طریقہ الٹ ہے: stack بند کریں، خالی /app/data volume میں فائلیں extract کریں، پھر اسے شروع کریں۔

اپ گریڈز

اپ گریڈز کے لیے image pull کریں:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

نیا container پہلی بار start ہوتے وقت database migration چلاتا ہے؛ docker compose logs -f کو monitor کریں۔ pull کرنے سے پہلے اوپر دیا گیا backup لیں، اور major tag کی حد میں رہیں: :1 سے :2 پر منتقل ہونا one-way migration ہے، اس لیے پہلے backup لیں اور release notes دیکھیں۔

ناکامی کی صورتیں، اور نظر آنے والے پیغامات

localhost کی نگرانی میں غلط طور پر "down" دکھائی دینا۔ مانیٹر timeout of 48000ms exceeded یا connect ETIMEDOUT کے ساتھ سرخ ہو جاتا ہے، لیکن سروس آپ کے laptop سے جواب دیتی ہے۔ اگر مانیٹر اسی host کو target کرتا ہے جس پر Uptime Kuma چل رہا ہے، تو CPU یا memory spike نے check کے لیے وسائل کم کر دیے ہیں؛ مسئلہ target میں نہیں ہے۔ مانیٹر کو الگ VPS پر منتقل کریں اور public hostname کو target کریں۔

connect ECONNREFUSED 127.0.0.1:443 (یا کوئی بھی port)۔ اس port پر کچھ بھی listening نہیں کر رہا تھا۔ یا تو سروس down ہے، یا آپ نے container کے اندر سے localhost کو monitor کیا، جہاں 127.0.0.1 آپ کا server نہیں بلکہ container ہے۔ loopback کے بجائے public hostname کو monitor کریں۔

ای میل test میں Invalid login: 535-5.7.8 Username and Password not accepted۔ SMTP credentials غلط ہیں، یا provider کو app-specific password درکار ہے لیکن اسے آپ کے account کا password دیا گیا ہے۔ app password بنائیں اور اسے paste کریں۔

ای میل test میں connect ETIMEDOUT یا queryA ETIMEDOUT <host>۔ port غلط ہے، یا provider outbound SMTP کو block کر رہا ہے۔ تصدیق کریں کہ 465 یا 587، Secure/STARTTLS setting کے مطابق ہے، اور host سے nc -vz smtp.example.com 587 کے ذریعے test کریں۔ بہت سے providers outbound 25 کو block کرتے ہیں، جبکہ کچھ providers submission ports کو اس وقت تک block رکھتے ہیں جب تک آپ درخواست نہ کریں۔

ای میل test میں self signed certificate یا unable to verify the first certificate۔ آپ کا SMTP server ایسا certificate پیش کر رہا ہے جس پر Node اعتماد نہیں کرتا۔ مسئلہ چھپانے کے بجائے mail server کا certificate درست کریں۔

Dashboard "Connecting..." پر رک جاتا ہے، اور console میں WebSocket connection ... failed دکھائی دیتا ہے۔ reverse proxy WebSocket کو upgrade نہیں کر رہا۔ nginx میں Upgrade اور Connection "upgrade" headers شامل کریں، یا ایسا proxy استعمال کریں جو انہیں default طور پر forward کرتا ہو، جیسے Traefik یا Caddy۔ HTML اس لیے load ہوتا ہے کہ یہ معمول کی HTTP GET request ہے؛ upgrade صرف live socket کے لیے درکار ہے۔

Cert-expiry monitor کبھی warning نہیں دیتا، یا غلط warning دیتا ہے۔ یا تو Ignore TLS/SSL Error منتخب ہے، جس سے certificate checking غیر فعال ہو جاتی ہے، یا monitor ایک IP کو target کر رہا ہے اور SNI نہ ہونے کی وجہ سے غلط certificate پڑھ رہا ہے، جس سے Hostname/IP does not match certificate's altnames دکھائی دیتا ہے۔ ignore کا انتخاب ختم کریں اور hostname کے ذریعے monitor کریں۔

logs میں SQLITE_BUSY یا database disk image is malformed۔ /app/data volume ایسے filesystem پر ہے جہاں file locking درست طور پر دستیاب نہیں، عموماً NFS پر۔ اسے local Docker volume پر منتقل کریں اور backup سے restore کریں۔

FAQ

مجھے اپنا uptime monitor کہاں چلانا چاہیے؟

اسے ان servers سے مختلف server پر چلائیں جن کی یہ نگرانی کرتا ہے۔ بہتر ہے کہ server کسی دوسرے provider یا region میں ہو، اور ان تک public internet کے ذریعے hostname سے اسی طرح پہنچے جیسے آپ کے users پہنچتے ہیں۔ اگر monitor اپنے targets کے ساتھ ایک ہی box پر ہو تو server کو بند کرنے والی outage monitor کو بھی بند کر دے گی۔ overloaded host ان services کے بارے میں بھی "down" دکھا سکتا ہے جو درست کام کر رہی ہوں۔ ایک چھوٹا الگ VPS دونوں مسائل سے بچاتا ہے۔

Telegram یا email پر alerts کیسے حاصل کروں؟

Settings then Notifications کے تحت channel شامل کریں، پھر اسے ہر monitor کے ساتھ attach کریں۔ Telegram کے لیے @BotFather سے bot بنائیں اور https://api.telegram.org/bot<token>/getUpdates سے chat.id پڑھیں؛ email کے لیے SSL کے لیے 465 یا STARTTLS کے لیے 587 استعمال کریں۔ اگر آپ کا provider two-factor auth استعمال کرتا ہے تو app password دیں۔ Test دبائیں اور اس پیغام پر انحصار کرنے سے پہلے تصدیق کریں کہ message پہنچ گیا ہے۔

کیا Uptime Kuma کسی cron job یا backup script کی نگرانی کر سکتا ہے؟

جی ہاں، اس کے لیے Push monitor استعمال ہوتا ہے۔ Uptime Kuma آپ کو ایک URL دیتا ہے، اور آپ script کے اختتام پر curl چلاتے ہیں تاکہ یہ صرف کامیابی کی صورت میں signal بھیجے۔ اگر job fail ہو جائے یا box down ہو تو heartbeat نہیں پہنچتا، اور interval گزرنے کے بعد آپ کو alert مل جاتا ہے۔ Scheduled job واقعی چلی یا نہیں، یہ جاننے کا یہی واحد قابلِ اعتماد طریقہ ہے، کیونکہ external check اس کے اندر کی حالت نہیں دیکھ سکتا۔

Uptime Kuma بمقابلہ Zabbix، مجھے کون سا چلانا چاہیے؟

Uptime Kuma تقریباً 10 منٹ میں، بہت کم resources کے ساتھ، اس سوال کا جواب دیتا ہے کہ "کیا یہ باہر سے up ہے، اور کیا اس نے مجھے alert کیا؟" اس کے علاوہ یہ status page بھی فراہم کرتا ہے۔ یہ CPU، memory اور disk trends جیسے تفصیلی metrics، یا پوری fleet کے thresholds جمع نہیں کرتا۔ اس مقصد کے لیے مکمل Zabbix monitoring server زیادہ بھاری، agent-based tool ہے، اور بہت سے لوگ دونوں چلاتے ہیں۔ پھر بھی یہ طے نہیں کر پا رہے کہ کچھ چلانا بھی ہے یا نہیں؟ 2026 میں self-host کرنے والی چیزوں کا ہمارا جائزہ monitoring کو وسیع تناظر میں پیش کرتا ہے۔