लेखक: Matt Connor 2026-07-15 · अपडेट किया गया: 2026-08-25

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

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

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

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

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

Uptime Kuma को Docker के जरिए इंस्टॉल करने का तरीका जानें। वेबसाइट, DNS और cron jobs की मॉनिटरिंग के लिए इसे अलग VPS पर चलाएं ताकि सर्वर डाउन होने पर भी अलर्ट मिलते रहें।

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

एक छोटा सा कंटेनर जो बाहर से आपके अन्य सर्वर्स और वेबसाइट्स पर नजर रखता है। जैसे ही कोई सर्वर जवाब देना बंद करता है, यह आपको ईमेल, Telegram, Discord या webhook के माध्यम से सूचित करता है। Uptime Kuma एक Node process है जो SQLite फाइल का उपयोग करती है, इसलिए यह 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 फ़ाइल

इसे /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 प्रक्रिया को देखें:

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

एक सही शुरुआत में Listening on 3001 लॉग होता है और फिर यह शांत हो जाता है। उस फ़ाइल में तीन चीजें जानबूझकर की गई हैं।

127.0.0.1:3001:3001, न कि 3001:3001। Docker पोर्ट्स को उन DNAT नियमों के साथ publish करता है जिनका मूल्यांकन ufw द्वारा पैकेट देखने से पहले ही हो जाता है, इसलिए एक साधारण 3001:3001 आपके डैशबोर्ड को आपके फ़ायरवॉल की परवाह किए बिना सार्वजनिक इंटरनेट पर डाल देता है। लूपबैक (loopback) पर बाइंड करने से यह निजी रहता है और केवल reverse proxy ही expose होता है; एक निजी instance प्रॉक्सी को छोड़ सकता है और self-hosted WireGuard VPN के माध्यम से 3001 तक पहुँच सकता है।

/app/data पर एक named volume। Uptime Kuma जो कुछ भी याद रखता है, जैसे SQLite डेटाबेस, आपके मॉनिटर, नोटिफिकेशन सेटिंग्स और स्टेटस-पेज लोगो, सब वहीं रहता है। इसे खोने का मतलब है कि आप एक खाली एडमिन स्क्रीन से शुरुआत करेंगे; यह एकमात्र ऐसी चीज़ है जिसका आपको बैकअप लेना चाहिए।

इमेज को एक प्रमुख टैग, :2 से पिन किया गया है। यह वर्तमान स्टेबल लाइन है; इसे कॉपी करने से पहले Docker Hub पर नवीनतम प्रमुख वर्ज़न देखें, और कभी भी latest जैसे बदलते टैग को ट्रैक न करें, जिसे प्रोजेक्ट ने अस्वीकृत (deprecate) कर दिया है। इस इमेज पर एक प्रमुख वर्ज़न का जंप एक तरफा डेटाबेस माइग्रेशन है जिसे आप जानबूझकर ट्रिगर करना चाहेंगे, न कि नियमित pull के दौरान अनजाने में।

एक चेतावनी: /app/data को POSIX फ़ाइल लॉक वाले फ़ाइल सिस्टम पर होना चाहिए। एक लोकल Docker वॉल्यूम ठीक है; NFS पर SQLite डेटाबेस करप्ट हो जाता है और आपको SQLITE_BUSY तथा database disk image is malformed त्रुटियाँ मिलती हैं, इसलिए कभी भी नेटवर्क शेयर का उपयोग न करें।

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

अपने प्रॉक्सी के माध्यम से https://status.example.com पर, या SSH टनल के जरिए इंस्टेंस पर जाएँ: ssh -L 3001:127.0.0.1:3001 user@your-vps चलाएँ और http://localhost:3001 खोलें। पहला पेज एडमिनिस्ट्रेटर यूजरनेम और पासवर्ड के लिए एक सेटअप फॉर्म है; इसमें कोई डिफ़ॉल्ट लॉगिन नहीं होता है। एक मजबूत पासवर्ड चुनें: यह डैशबोर्ड आपके द्वारा मॉनिटर की जाने वाली हर चीज़ के इंटरनल एड्रेस और टोकन देख सकता है। बाद में भूल जाने पर इसे ब्राउज़र से नहीं, बल्कि होस्ट से रीसेट करें:

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

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

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

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

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

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

Generic webhook. किसी अन्य चीज़ के लिए, जैसे Slack incoming webhook, कस्टम एंडपॉइंट, या होम-ऑटोमेशन हुक, 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 करना होगा। यदि यह छूट गया तो page load तो होगा लेकिन 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 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 करें, config का test करें, फिर certbot को block को 443 पर listen करने के लिए rewrite करने दें, 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 इन दोनों को अपने द्वारा generate किए गए 443 block में copy कर देता है। यदि आप पहले से ही एक proxy के पीछे कई containers चला रहे हैं, तो container labels के साथ Traefik के माध्यम से routing और automatic TLS वही काम करता है और डिफ़ॉल्ट रूप से WebSocket upgrades को forward करता है।

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

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 पर जाना एक one-way migration है, इसलिए पहले backup लें और 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 को सही संदर्भ में रखता है।

#uptime-kuma#मॉनिटरिंग #Docker #सेल्फ़-होस्टिंग#status-page