Uptime Kuma को Docker में कैसे सेटअप करें

आप क्या बना रहे हैं

एक छोटा सा कंटेनर जो बाहर से आपके अन्य सर्वर्स और वेबसाइटों पर नजर रखता है। जैसे ही कोई सेवा प्रतिक्रिया देना बंद करती है, यह आपको ईमेल, Telegram, Discord या webhook के माध्यम से सूचित करता है। Uptime Kuma एक Node प्रोसेस है, जो इस सेटअप में SQLite फाइल द्वारा समर्थित है (v2 को एम्बेडेड या बाहरी MariaDB पर भी चलाया जा सकता है)। यह 256-512 MB RAM में आसानी से चलता है और आपको एक लाइव डैशबोर्ड, इतिहास ग्राफ और एक पब्लिक स्टेटस पेज प्रदान करता है। इसका इंस्टॉलेशन दस लाइनों की Compose फाइल है। वास्तव में महत्वपूर्ण यह है कि आप इसे कहाँ चलाते हैं और क्या आपके अलर्ट्स ने कभी टेस्ट के दौरान काम किया है। क्योंकि जिस मॉनिटर को आपने कभी टेस्ट नहीं किया कि वह आप तक पहुँच सकता है या नहीं, वह न होने से भी बदतर है: यह आपको सुरक्षित होने का एहसास दिलाता है जबकि वास्तव में यह कुछ भी नहीं देख रहा होता है।

मॉनिटर को ऐसी जगह चलाएं जहां आउटेज का असर न हो

यह निर्णय पूरी प्रक्रिया की सफलता या विफलता तय करता है, इसलिए यह सबसे महत्वपूर्ण है। Uptime Kuma को उसी सर्वर पर न चलाएं जिसकी यह निगरानी कर रहा है। यदि मॉनिटर उसी सर्वर पर स्थित है जिसकी वह निगरानी करता है, तो जिस घटना की आप चिंता कर रहे हैं—जैसे सर्वर का डाउन होना या मेमोरी खत्म होना—वह मॉनिटर को भी बंद कर देगी और आपको कोई अलर्ट नहीं मिलेगा: एक मृत मॉनिटर की चुप्पी का मतलब "सब कुछ ठीक है" जैसा ही होता है। सर्वर के चालू रहने पर भी एक सूक्ष्म खतरा होता है: localhost पर पॉइंट किया गया मॉनिटर वर्कलोड के साथ CPU साझा करता है, इसलिए लोड बढ़ने पर इसका अपना चेक टाइम-आउट हो सकता है और यह टारगेट को down दिखा सकता है। यह एक गलत अलार्म है, जबकि वास्तविक उपयोगकर्ता सेवा का उपयोग कर पा रहे होते हैं।

इसलिए Uptime Kuma को उस VPS से अलग VPS पर चलाएं जिसकी वह निगरानी करता है। आदर्श रूप से, इसे किसी अलग प्रदाता या क्षेत्र (region) में रखें, जो आपके उपयोगकर्ताओं की तरह ही सार्वजनिक इंटरनेट के माध्यम से होस्टनेम द्वारा आपकी सेवाओं तक पहुंच सके। एक सस्ता इंस्टेंस इसके लिए पर्याप्त है, और एक छोटा मॉनिटरिंग VPS आपके सभी सर्वरों की निगरानी कर सकता है। यह अलगाव आपके द्वारा होस्ट किए जाने वाले भारी ऐप्स के लिए सबसे अधिक मायने रखता है, क्योंकि PhotoPrism या Immich फोटो लाइब्रेरी जैसा कोई ऐप नई फाइलों को इंडेक्स करते समय घंटों तक CPU का उपयोग कर सकता है। यदि मॉनिटर उसी हार्डवेयर को साझा करेगा, तो वह ऐसी सेवा के लिए 'down' का अलार्म देगा जो केवल व्यस्त है। स्वयं Kuma के डाउन होने का पता लगाने के लिए, कहीं और से एक cron के माध्यम से push heartbeat जोड़ें।

आवश्यकताएँ और साइजिंग

• Docker Engine और Compose v2 plugin के साथ एक नया Ubuntu 24.04 VPS, जिसे Docker के अपने apt repository से इंस्टॉल किया गया हो, न कि docker.io distro पैकेज से, जो पुराना होता है।
• 256 MB RAM पर कुछ मॉनिटर चल सकते हैं; 512 MB से 1 GB RAM दर्जनों मॉनिटर और reverse proxy के लिए पर्याप्त है, और चेक के बीच CPU लगभग खाली रहता है।
• एक domain और एक DNS A record (जैसे status.example.com जो VPS की ओर इशारा करता हो), केवल तभी यदि आप TLS और public status page चाहते हैं। एक private instance के लिए DNS की आवश्यकता नहीं है, आप VPN या SSH tunnel का उपयोग कर सकते हैं।
• अलर्ट भेजने के लिए आउटबाउंड नेटवर्क: आपके mail provider के लिए SMTP, या Telegram और Discord के लिए HTTPS।

Compose file

इसे /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:

इसे start करें और पहली boot प्रक्रिया को monitor करें:

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

एक सही start होने पर Listening on 3001 log में दिखता है और फिर प्रक्रिया शांत हो जाती है। उस file में तीन चीजें जानबूझकर रखी गई हैं।

127.0.0.1:3001:3001, न कि 3001:3001। Docker ports को DNAT rules के साथ publish करता है, जो ufw द्वारा packet देखने से पहले ही evaluate हो जाते हैं। इसलिए, एक साधारण 3001:3001 आपके dashboard को public internet पर डाल देता है, चाहे आपके ufw rules कुछ भी हों; केवल Docker की अपनी DOCKER-USER chain में जोड़े गए rules ही इसे filter कर सकते हैं। Loopback पर bind करने से यह private रहता है और केवल reverse proxy ही expose होता है। इसका मतलब यह भी है कि केवल host ही 3001 तक पहुँच सकता है: बिना proxy वाली एक private instance नीचे दिखाए गए SSH tunnel का उपयोग करती है, और इसे एक self-hosted WireGuard VPN के माध्यम से एक्सेस करने के लिए आपको port को server के WireGuard address (उदाहरण के लिए 10.8.0.1:3001:3001) पर publish करना होगा, न कि 127.0.0.1 पर।

/app/data पर एक named volume। Uptime Kuma जो कुछ भी याद रखता है, जैसे SQLite database, आपके monitors, notification settings और status-page logos, वे सब वहीं रहते हैं। यदि यह खो जाता है, तो आप एक खाली admin screen के साथ शुरू करेंगे; यह एकमात्र ऐसी चीज है जिसका आपको backup लेना चाहिए।

Image को एक major tag, :2 पर pin किया गया है। यह वर्तमान stable line है; इसे copy करने से पहले Docker Hub पर नवीनतम major version देखें। कभी भी latest जैसे moving tag को track न करें, जिसे project ने deprecate कर दिया है। इस image पर major-version jump करने से एक database migration शुरू होता है जिसे आप जानबूझकर trigger करना चाहेंगे, और इसके लिए आपके पास एक fresh backup होना चाहिए, न कि routine pull के दौरान अचानक हुई कोई प्रक्रिया।

एक चेतावनी: /app/data को POSIX file locks का समर्थन करने वाले filesystem पर होना चाहिए। Local Docker volume ठीक है; NFS पर SQLite database corrupt हो जाता है और आपको SQLITE_BUSY तथा database disk image is malformed error मिलते हैं, इसलिए कभी भी network share का उपयोग न करें।

पहली बार चलाना: एडमिन अकाउंट बनाना

अपने proxy के माध्यम से https://status.example.com पर instance को browse करें, या SSH tunnel का उपयोग करें: ssh -L 3001:127.0.0.1:3001 user@your-vps चलाएं और http://localhost:3001 खोलें। v2 के एक नए install पर पहली स्क्रीन पूछती है कि किस database का उपयोग करना है; SQLite चुनें, जो सब कुछ /app/data volume में रखता है और यही वह है जिसे नीचे दिए गए backup और troubleshooting चरणों में माना गया है। इसके बाद एडमिनिस्ट्रेटर username और password के लिए एक setup form आता है; इसमें कोई default login नहीं होता है। एक मजबूत password चुनें: यह dashboard उन सभी चीजों के internal addresses और tokens को देखता है जिन्हें आप monitor करते हैं। बाद में भूल गए? तो browser से नहीं, बल्कि host से reset करें:

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

सबसे पहले अपने नोटिफिकेशन चैनल जोड़ें और उनका परीक्षण करें

मॉनिटर जोड़ने से पहले अलर्ट सेट करें, ताकि आप प्रत्येक मॉनिटर को बनाते समय उसे एक चैनल से जोड़ सकें। Settings के बाद Notifications और फिर Setup Notification पर जाएं, और प्रत्येक चैनल के Test बटन का उपयोग करके पुष्टि करें कि संदेश प्राप्त हो रहा है, क्योंकि बिना परीक्षण किया गया नोटिफिकेशन सेटअप के चुपचाप विफल होने का दूसरा सबसे सामान्य कारण है।

Email (SMTP). होस्ट, पोर्ट, एन्क्रिप्शन, यूजरनेम, पासवर्ड, एक From और एक To भरें। सामान्य संयोजन 465 हैं जिसमें "Secure" को TLS/SSL पर सेट किया जाता है, या 587 जिसमें STARTTLS का उपयोग होता है; कुछ सर्वर 25 पर भी STARTTLS प्रदान करते हैं, इसलिए उस पोर्ट और मोड का उपयोग करें जिसे आपका प्रदाता निर्दिष्ट करता है। Gmail और टू-फैक्टर ऑथेंटिकेशन वाले अधिकांश प्रदाताओं के लिए आपको एक app password जनरेट करना होगा; सामान्य अकाउंट पासवर्ड से Error: Invalid login: 535-5.7.8 Username and Password not accepted त्रुटि प्राप्त होगी।

Telegram. @BotFather को संदेश भेजें, /newbot भेजें, और बॉट टोकन कॉपी करें। अपनी चैट आईडी के लिए, नए बॉट को एक बार संदेश भेजें, https://api.telegram.org/bot<token>/getUpdates खोलें, और JSON से chat.id पढ़ें। जिस बॉट को आपने पहले कभी संदेश नहीं भेजा है, उसका getUpdates खाली होता है और उसके पास भेजने के लिए कोई स्थान नहीं होता है।

Discord. चैनल में, Edit Channel के बाद Integrations, फिर Webhooks और New Webhook खोलें, URL कॉपी करें, और इसे Discord नोटिफिकेशन के रूप में पेस्ट करें।

Generic webhook. किसी अन्य चीज़ के लिए, जैसे Slack इनकमिंग वेबहुक, कस्टम एंडपॉइंट, या होम-ऑटोमेशन हुक, Webhook प्रकार आपके द्वारा प्रदान किए गए URL पर JSON पेलोड को POST करता है, और बंडल किया गया Apprise इंटीग्रेशन सूची में मौजूद अन्य नब्बे से अधिक सेवाओं को कवर करता है। यदि आप नहीं चाहते कि किसी आउटेज और आपके फोन के बीच कोई तीसरा पक्ष हो, तो इन-बिल्ट ntfy प्रकार चुनें और इसे अपने स्वयं के ntfy सर्वर की ओर निर्देशित करें, जो आपके द्वारा नियंत्रित चैनल के माध्यम से आपके हैंडसेट पर एंड-टू-एंड पुश नोटिफिकेशन भेजता है।

एक बार में एक प्रकार के मॉनिटर जोड़ें

Add New Monitor पर क्लिक करें, एक प्रकार चुनें, और Friendly Name, Check Interval (60 सेकंड एक उचित अंतराल है), Retries ("down" होने से पहले लगातार विफलताएं; 2 या 3 रखें ताकि एक पैकेट ड्रॉप होने पर अलर्ट न आए), और जिन नोटिफिकेशन को ट्रिगर करना है, उन्हें सेट करें। आप जिन प्रकारों का उपयोग करेंगे:

• HTTP(s). एक पूर्ण URL। "Up" का अर्थ है एक स्वीकृत स्टेटस कोड (डिफ़ॉल्ट रूप से 200-299; यदि आपके लिए 301 या 401 सामान्य है, तो इसे Accepted Status Codes के अंतर्गत विस्तृत करें)। वेबसाइटों और API के लिए यह आपका मुख्य टूल है।
• HTTP(s) - Keyword. वही अनुरोध, लेकिन "up" होने के लिए बॉडी में एक स्ट्रिंग का मौजूद होना भी आवश्यक है, या Invert विकल्प के साथ, उसका अनुपस्थित होना। यह तब काम आता है जब साइट 200 OK रिटर्न करती है लेकिन पेज पर "Error establishing a database connection" लिखा होता है, जिसे एक सामान्य HTTP चेक स्वस्थ मान लेगा। यह उन ब्राउज़र फ्रंट-एंड के लिए भी सही चेक है जो एक अलग बैकएंड से बात करते हैं, जैसे Jellyfin के ऊपर एक Halcyon वीडियो-स्टोर स्किन, जिसका पेज शेल खुशी-खुशी 200 रिटर्न करता है जबकि उसके पीछे का मीडिया सर्वर पहुंच से बाहर होता है।
• TCP Port. किसी होस्ट और पोर्ट के लिए एक सीधा TCP कनेक्शन, उन चीजों के लिए जो HTTP नहीं हैं: 22 पर SSH, 5432 पर Postgres, 25 पर एक SMTP सर्वर, या कोई गेम सर्वर।
• Ping. ICMP echo: पहुंच और लेटेंसी जांचने का सस्ता तरीका। लेकिन कई नेटवर्क और क्लाउड फायरवॉल ICMP को ड्रॉप कर देते हैं, इसलिए एक लाल पिंग मॉनिटर का मतलब "होस्ट डाउन" या "प्रदाता द्वारा पिंग ब्लॉक" हो सकता है; TCP मॉनिटर के साथ इसकी पुष्टि करें।
• DNS. आपके द्वारा निर्दिष्ट रिज़ल्वर के विरुद्ध एक रिकॉर्ड (A, AAAA, MX, TXT आदि) रिज़ॉल्व करता है, और उत्तर की पुष्टि कर सकता है, जिससे रजिस्ट्रार या DNS आउटेज का जल्दी पता चल जाता है।
• Push. इनसाइड-आउट मॉनिटर, जिसे आगे कवर किया गया है।

Push (heartbeat) monitor के साथ cron job की निगरानी करना

ऊपर बताए गए सभी मॉनिटर बाहर से आपकी सर्विस के अंदर पहुँचते हैं। एक पुश मॉनिटर इसके विपरीत काम करता है: Uptime Kuma प्रतीक्षा करता है, और आपकी जॉब उसे यह बताने के लिए कॉल करती है कि "मैं चल गई।" बैकअप या cron की निगरानी करने का यह एकमात्र सटीक तरीका है: एक HTTP चेक यह जानता है कि URL रिस्पॉन्स दे रहा है, लेकिन केवल जॉब ही यह जानती है कि वह पूरी हो गई है।

Push प्रकार का एक मॉनिटर बनाएँ। Uptime Kuma एक यूनिक URL जनरेट करेगा, जैसे:

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

Heartbeat Interval को उस समय पर सेट करें जितनी बार जॉब चलती है, और इसमें थोड़ा अतिरिक्त समय (slack) जोड़ दें। इसके बाद, स्क्रिप्ट के अंत में एक लाइन जोड़ें, ताकि यह केवल सफलता पर ही ट्रिगर हो:

#!/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="

यदि जॉब फेल हो जाती है, तो set -e curl से पहले ही रुक जाता है; यदि सर्वर डाउन है, तो यह कभी नहीं चलती। दोनों ही स्थितियों में हार्टबीट रुक जाती है, और जैसे ही इंटरवल-प्लस-रिट्राय (interval-plus-retries) की समय-सीमा समाप्त होती है, Uptime Kuma मॉनिटर को down स्थिति में बदल देता है और आपको अलर्ट भेजता है। इस पुश टोकन को एक सीक्रेट की तरह रखें: जिसके पास भी यह होगा, वह एक सफल बीट (healthy beat) को फर्जी तरीके से भेज सकता है।

एक पब्लिक स्टेटस पेज बनाना

स्टेटस पेज ग्राहकों के लिए दृश्य होता है: इसमें यह दिखता है कि कौन सी सेवाएं चालू हैं और उनका हालिया इतिहास क्या है, बिना आपके डैशबोर्ड को उजागर किए। Status Pages फिर New Status Page पर जाएं, इसे एक नाम और एक slug (पब्लिक पाथ, जैसे /status/main) दें, जिन मॉनिटर्स को आप शामिल करना चाहते हैं उन्हें "Websites" और "APIs" जैसे समूहों में ड्रैग करें, एक लोगो और संक्षिप्त विवरण जोड़ें, और Save पर क्लिक करें। आप इस पेज को अपने स्वयं के डोमेन से भी जोड़ सकते हैं ताकि status.example.com इसे सीधे सर्व करे।

दो सावधानियां: केवल उन्हीं मॉनिटर्स को जोड़ें जिन्हें आप सार्वजनिक करने के लिए तैयार हैं, क्योंकि स्टेटस पेज यह उजागर करता है कि कोई सेवा मौजूद है और क्या वह चालू है; और डैशबोर्ड आपके लॉगिन के पीछे सुरक्षित रहता है जबकि स्टेटस पेज जानबूझकर सार्वजनिक होता है और इसके लिए किसी प्रमाणीकरण (auth) की आवश्यकता नहीं होती है।

इसे TLS के साथ एक reverse proxy के पीछे रखें, और websockets का ध्यान रखें

Public instance के लिए, TLS और hostname के लिए loopback-bound container के सामने एक reverse proxy लगाएँ। वह विवरण जो सभी को उलझाता है: Uptime Kuma का UI एक live Socket.IO app है, इसलिए proxy को WebSocket connection को upgrade करना होगा। यदि आप ऐसा नहीं करते हैं, तो पेज लोड तो होगा लेकिन कभी connect नहीं होगा; 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 issuing Let's Encrypt certificates with certbot and nginx में बताए गए हैं।

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 करें, config का test करें, फिर certbot को block को rewrite करने दें ताकि वह 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 में copy कर देता है जिसे वह generate करता है। यदि आप पहले से ही एक proxy के पीछे कई containers चला रहे हैं, तो routing them through Traefik with automatic TLS container labels के साथ वही काम करता है और डिफ़ॉल्ट रूप से WebSocket upgrades को forward करता है।

पूरे vhost पर basic-auth न लगाएँ, क्योंकि यह public status page और /api/push endpoint को भी lock कर देता है। Uptime Kuma के built-in login का उपयोग करें, यदि यह internet-facing है तो fail2ban watching for repeated failed logins जोड़ें, और यदि dashboard को public करने की आवश्यकता नहीं है, तो proxy को हटा दें और इसे SSH tunnel के माध्यम से, या VPN पर उस port को publish करके access करें जो loopback के बजाय VPN address पर हो।

Certificate-expiry monitoring, सही तरीके से करना

एक HTTP(s) monitor आपको TLS certificate की expiry से पहले भी चेतावनी दे सकता है: Certificate Expiry Notification को tick करें और Uptime Kuma निर्धारित दिनों की संख्या पहले आपको alert भेज देगा। दो गलतियों के कारण यह गलत जानकारी दे सकता है। Monitor को IP के बजाय hostname द्वारा सेट करें, अन्यथा बिना SNI वाली request सर्वर का default certificate प्राप्त करेगी और आपको Hostname/IP does not match certificate's altnames दिखाई देगा। और जिस monitor से आप expiry warnings चाहते हैं, उस पर Ignore TLS/SSL Error को tick न करें: यह toggle self-signed internal hosts (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT) के लिए है, लेकिन यह Uptime Kuma को certificate की जाँच करने से पूरी तरह रोक देता है, जिसमें expiry की जाँच भी शामिल है।

बैकअप: यह केवल एक डायरेक्टरी है

चूंकि सब कुछ /app/data में रहता है, इसलिए बैकअप उस वॉल्यूम की एक कॉपी है जिसे कंटेनर के रुके होने पर लिया जाता है, ताकि 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 के साथ वॉल्यूम का वास्तविक नाम सुनिश्चित करें, क्योंकि Compose इसे प्रोजेक्ट डायरेक्टरी के साथ प्रीफिक्स (prefix) करता है। इसके बाद tarball को सर्वर से बाहर कॉपी करें, क्योंकि एक ही VPS पर रखा गया बैकअप केवल एक कॉपी है, वास्तविक बैकअप नहीं। रिस्टोर करने की प्रक्रिया इसके विपरीत है: स्टैक को रोकें, इसे एक खाली /app/data वॉल्यूम में एक्सट्रैक्ट करें, और फिर इसे स्टार्ट करें।

Upgrades

Upgrades एक 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 पर जाने से database migrate हो जाता है। प्रोजेक्ट की migration guide के अनुसार, यदि migration बीच में रुक जाए, तो backup से restore करके पुनः प्रयास करना पड़ता है। इसलिए, पहले backup लें और उस guide तथा release notes को पढ़ें।

विफलता के प्रकार और दिखाई देने वाले संदेश

localhost पर पॉइंट किए गए मॉनिटर पर गलत "down" स्थिति। मॉनिटर timeout of 48000ms exceeded या connect ETIMEDOUT के साथ लाल हो जाता है, जबकि आपके लैपटॉप से सर्विस रिस्पॉन्स दे रही है। यदि यह उसी होस्ट को टारगेट करता है जिस पर Uptime Kuma चल रहा है, तो CPU या मेमोरी स्पाइक ने चेक को बाधित किया है, न कि टारगेट को। मॉनिटर को एक अलग VPS पर ले जाएं और पब्लिक होस्टनेम को टारगेट करें।

connect ECONNREFUSED 127.0.0.1:443 (या कोई भी पोर्ट)। उस पोर्ट पर कोई सर्विस लिसन नहीं कर रही थी: या तो सर्विस डाउन है, या आपने कंटेनर के अंदर से localhost को मॉनिटर किया है, जहाँ 127.0.0.1 का अर्थ कंटेनर है, न कि आपका सर्वर। लूपबैक के बजाय पब्लिक होस्टनेम को मॉनिटर करें।

ईमेल टेस्ट पर Invalid login: 535-5.7.8 Username and Password not accepted। SMTP क्रेडेंशियल्स गलत हैं, या प्रोवाइडर को आपके अकाउंट पासवर्ड के बजाय ऐप-विशिष्ट पासवर्ड की आवश्यकता है। एक ऐप पासवर्ड जनरेट करें और उसे पेस्ट करें।

ईमेल टेस्ट पर connect ETIMEDOUT या queryA ETIMEDOUT <host>। गलत पोर्ट, या प्रोवाइडर आउटबाउंड SMTP को ब्लॉक कर रहा है। पुष्टि करें कि 465 या 587 आपके Secure/STARTTLS सेटिंग से मेल खाते हैं, और होस्ट से nc -vz smtp.example.com 587 के साथ टेस्ट करें। कई प्रोवाइडर आउटबाउंड 25 को ब्लॉक करते हैं और कुछ तब तक सबमिशन पोर्ट्स को ब्लॉक रखते हैं जब तक आप अनुरोध न करें।

ईमेल टेस्ट पर self signed certificate या unable to verify the first certificate। आपका SMTP सर्वर ऐसा सर्टिफिकेट प्रस्तुत कर रहा है जिस पर Node भरोसा नहीं करेगा; इसे छिपाने के बजाय मेल सर्वर के सर्टिफिकेट को ठीक करें।

डैशबोर्ड "Connecting..." पर अटका है, कंसोल WebSocket connection ... failed दिखाता है। रिवर्स प्रॉक्सी WebSocket को अपग्रेड नहीं कर रहा है। nginx पर Upgrade और Connection "upgrade" हेडर जोड़ें, या ऐसे प्रॉक्सी का उपयोग करें जो डिफ़ॉल्ट रूप से उन्हें फॉरवर्ड करता है, जैसे Traefik या Caddy। HTML लोड हो जाता है क्योंकि यह एक सामान्य HTTP GET है; केवल लाइव सॉकेट को अपग्रेड की आवश्यकता होती है।

सर्टिफिकेट-एक्सपायरी मॉनिटर कभी चेतावनी नहीं देता, या गलत चेतावनी देता है। या तो Ignore TLS/SSL Error टिक किया हुआ है, जो सर्टिफिकेट चेकिंग को डिसेबल कर देता है, या मॉनिटर एक IP को टारगेट कर रहा है और SNI न होने के कारण गलत सर्टिफिकेट पढ़ रहा है, जिससे Hostname/IP does not match certificate's altnames दिखाई देता है। इग्नोर विकल्प को अनटिक करें और होस्टनेम द्वारा मॉनिटर करें।

लॉग्स में SQLITE_BUSY या database disk image is malformed। /app/data वॉल्यूम ऐसे फाइलसिस्टम पर है जिसमें उचित फाइल लॉकिंग नहीं है, आमतौर पर NFS; इसे लोकल Docker वॉल्यूम पर ले जाएं और बैकअप से रिस्टोर करें।

FAQ

मुझे अपना uptime monitor कहाँ चलाना चाहिए?

आदर्श रूप से इसे उन सर्वर्स से अलग सर्वर पर चलाएं जिनकी यह निगरानी करता है। बेहतर होगा कि यह किसी अन्य प्रदाता या क्षेत्र (region) में हो, ताकि यह आपके उपयोगकर्ताओं की तरह ही public internet के माध्यम से hostname द्वारा उन तक पहुँच सके। यदि monitor अपने targets के साथ एक ही बॉक्स पर चलता है, तो सर्वर को बंद करने वाली खराबी monitor को भी बंद कर देगी, और overloaded host उन सेवाओं के लिए भी "down" का संकेत दे सकता है जो वास्तव में ठीक चल रही हैं। एक छोटा सा अलग VPS इन दोनों समस्याओं से बचाता है।

मुझे Telegram या email पर अलर्ट कैसे मिलेंगे?

Settings के अंतर्गत Notifications में जाकर चैनल जोड़ें, और फिर उसे प्रत्येक monitor के साथ संलग्न करें। Telegram के लिए, @BotFather के साथ एक bot बनाएँ और https://api.telegram.org/bot<token>/getUpdates से chat.id पढ़ें; email के लिए, SSL हेतु 465 का उपयोग करें या यदि आपका प्रदाता two-factor authentication का उपयोग करता है, तो app password के साथ STARTTLS हेतु 587 का उपयोग करें। उस पर भरोसा करने से पहले Test दबाएँ और पुष्टि करें कि संदेश प्राप्त हो गया है।

क्या Uptime Kuma किसी cron job या backup script की निगरानी कर सकता है?

हाँ, इसके लिए Push monitor का उपयोग करें: Uptime Kuma आपको एक URL देता है जिसे आप स्क्रिप्ट के अंत में curl करते हैं ताकि यह केवल सफलता पर ही ट्रिगर हो। यदि job विफल हो जाती है या बॉक्स बंद हो जाता है, तो heartbeat कभी नहीं पहुँचती है और निर्धारित अंतराल बीतने के बाद आपको अलर्ट मिल जाता है। यह जानने का एकमात्र विश्वसनीय तरीका है कि कोई scheduled job वास्तव में चली है या नहीं, क्योंकि बाहरी जाँच इसके अंदर नहीं देख सकती।

Uptime Kuma बनाम Zabbix, मुझे क्या चलाना चाहिए?

Uptime Kuma दस मिनट में और लगभग बिना किसी संसाधन के यह जवाब देता है कि "क्या यह बाहर से चालू है और क्या इसने मुझे अलर्ट किया", साथ ही यह एक status page भी प्रदान करता है। यह CPU, memory और disk trends या पूरे fleet के thresholds जैसे गहरे metrics एकत्र नहीं करता है; इसके लिए, एक पूर्ण Zabbix monitoring server अधिक भारी और agent-आधारित टूल है, और कई लोग दोनों का उपयोग करते हैं। अभी भी तय नहीं कर पा रहे हैं कि क्या चलाना है? 2026 में क्या self-host करें, इस पर हमारा सारांश monitoring को सही संदर्भ में रखता है।