द्वारे Matt Connor 2026-07-15 · अपडेटेड 2026-07-24

Uptime Kuma Docker मध्ये कसे इंस्टॉल करायचे

Q: मला Telegram किंवा email वर alerts कसे मिळतील?

Settings मध्ये जाऊन Notifications अंतर्गत चॅनेल निवडा आणि ते प्रत्येक monitor ला जोडा. Telegram साठी, @BotFather वापरून bot तयार करा आणि https://api.telegram.org/bot /getUpdates मधून chat.id वाचा; email साठी, SSL साठी 465 किंवा STARTTLS साठी 587 वापरा (जर तुमचा provider two-factor auth वापरत असेल, तर app password वापरा). Test बटण दाबा आणि मेसेज व्यवस्थित येत असल्याची खात्री करा.

Q: Uptime Kuma द्वारे मी cron job किंवा backup script monitor करू शकतो का?

हो, त्यासाठी Push monitor वापरा: Uptime Kuma तुम्हाला एक URL देतो आणि तुम्ही script च्या शेवटी curl करू शकता, ज्यामुळे फक्त यशस्वीतेनंतरच तो अलर्ट पाठवेल. जर job फेल झाले किंवा box डाऊन असेल, तर heartbeat मिळणार नाही आणि ठराविक interval संपल्यानंतर तुम्हाला अलर्ट मिळेल. scheduled job प्रत्यक्षात चालली आहे की नाही हे जाणून घेण्याचा हा एकमेव विश्वासार्ह मार्ग आहे, कारण external check द्वारे script च्या अंतर्गत प्रक्रिया पाहता येत नाहीत.

Docker वापरून Uptime Kuma सेटअप करा. वेबसाइट, पोर्ट आणि DNS मॉनिटर करण्यासाठी आणि Telegram किंवा Email द्वारे alerts मिळवण्यासाठी ही पद्धत वापरा.

तुम्ही काय तयार करत आहात

एक लहान कंटेनर जो तुमच्या इतर सर्व्हर्स आणि वेबसाइट्सवर बाहेरून लक्ष ठेवतो. एखादी सेवा प्रतिसाद देणे थांबवल्यास तो तुम्हाला लगेच email, Telegram, Discord किंवा webhook द्वारे सूचित करतो. Uptime Kuma ही एक Node प्रक्रिया आहे जी SQLite फाईलवर आधारित आहे. त्यामुळे ती 256-512 MB RAM मध्ये सहज चालते. हे तुम्हाला live dashboard, history graphs आणि public status page प्रदान करते. याची installation फक्त दहा ओळींची Compose फाईल आहे. सर्वात महत्त्वाचा भाग म्हणजे तुम्ही ती कुठे चालवता आणि तुमचे alerts टेस्टमध्ये यशस्वीरित्या आले आहेत का. जर मॉनिटरिंग सिस्टीम तुम्हाला सूचना देऊ शकत नसेल, तर ती न ठेवण्यापेक्षाही वाईट आहे; कारण ती तुम्हाला सुरक्षित असल्याचा चुकीचा भास निर्माण करते.

monitor अशा ठिकाणी चालवा जिथे outage त्याचा पोहोचू शकणार नाही

ही एक महत्त्वाची पायरी आहे, म्हणून ती सर्वात आधी येते. Uptime Kuma त्याच सर्व्हरवर चालवू नका ज्या गोष्टींवर ते लक्ष ठेवते. जर monitor ज्या server वर आहे तोच monitor असेल, तर तो server बंद पडल्यास किंवा त्याची memory संपल्यास monitor देखील बंद पडेल. अशा वेळी तुम्हाला कोणतीही alert मिळणार नाही; dead monitor कडून मिळणारी शांतता ही "सर्व काही ठीक आहे" असेच दर्शवते. जेव्हा server चालू असतो तेव्हाही एक सूक्ष्म अडचण येऊ शकते: localhost वर लक्ष ठेवणारा monitor workload सोबतच CPU शेअर करतो. त्यामुळे load वाढल्यास monitor ची स्वतःची check process timeout होऊ शकते आणि target down दाखवू शकते. ही एक false alarm असेल, जरी real users साठी सर्व काही व्यवस्थित सुरू असेल.

त्यामुळे Uptime Kuma, ज्या services वर ते लक्ष ठेवते त्यापेक्षा वेगळ्या VPS वर चालवा. शक्य असल्यास वेगळा provider किंवा वेगळा region निवडा, जेणेकरून तो तुमच्या services पर्यंत तुमच्या users प्रमाणेच पोहोचेल: म्हणजेच public internet द्वारे, hostname द्वारे. यासाठी एक स्वस्त instance पुरेसा आहे आणि एक लहान monitoring VPS तुमच्या सर्व servers वर लक्ष ठेवू शकते. जर Kuma स्वतः बंद पडला तर ते ओळखण्यासाठी, इतर कोठून cron द्वारे push heartbeat सेट करा.

Prerequisites and sizing

Docker Engine आणि Compose v2 plugin सह एक नवीन Ubuntu 24.04 VPS. हे 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 (उदा. VPS कडे निर्देशित करणारा status.example.com). हे केवळ तेव्हाच आवश्यक आहे जर तुम्हाला TLS आणि public status page हवे असेल. Private instance साठी DNS ची गरज नाही; तुम्ही VPN किंवा SSH tunnel वापरू शकता.
Alerts पाठवण्यासाठी outbound network: तुमच्या mail provider साठी SMTP, किंवा Telegram आणि Discord साठी HTTPS.

The 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:

हे सुरू करा आणि पहिली 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 rules द्वारे प्रकाशित करते, जे ufw कडे पॅकेट पोहोचण्यापूर्वीच तपासले जातात. त्यामुळे केवळ 3001:3001 वापरल्यास तुमचा dashboard तुमच्या firewall च्या पलीकडे सार्वजनिक इंटरनेटवर उपलब्ध होईल. loopback ला bind केल्यामुळे ते खाजगी राहते आणि फक्त reverse proxy बाहेरून उपलब्ध असतो; खाजगी instance मध्ये proxy न वापरता a self-hosted WireGuard VPN द्वारे 3001 ला प्रवेश मिळवता येतो.

/app/data येथे एक named volume. Uptime Kuma मधील सर्व गोष्टी, जसे की SQLite database, तुमचे monitors, notification settings आणि status-page logos, तिथे साठवले जातात. जर ते गमावले, तर तुम्हाला रिकाम्या admin screen पासून सुरुवात करावी लागेल; बॅकअप घेण्यासाठी ही एकमेव आवश्यक गोष्ट आहे.

image ही major tag :2 ला पिन केलेली आहे. ही सध्याची stable line आहे; कॉपी करण्यापूर्वी Docker Hub वर नवीन major version तपासा. latest सारख्या moving tag चा वापर करू नका, कारण प्रकल्प तो deprecated मानतो. या image मध्ये major-version बदलणे म्हणजे एक-वे database migration आहे, जे तुम्हाला जाणीवपूर्वक करावे लागते, नियमित pull दरम्यान ते आपोआप होऊ नये.

एक महत्त्वाची सूचना: /app/data साठी POSIX file locks असलेले filesystem आवश्यक आहे. local Docker volume वापरणे योग्य आहे; NFS वर SQLite database corrupt होतो आणि तुम्हाला SQLITE_BUSY आणि database disk image is malformed मिळतात, म्हणून कधीही network share वापरू नका.

First run: create the admin account

https://status.example.com वरील तुमच्या proxy द्वारे किंवा SSH tunnel द्वारे instance ला भेट द्या: ssh -L 3001:127.0.0.1:3001 user@your-vps चालवा आणि http://localhost:3001 उघडा. पहिले पान administrator username आणि password साठी setup form आहे; कोणतेही default login नाही. एक सुरक्षित password निवडा: हे dashboard तुम्ही monitor करत असलेल्या सर्व गोष्टींचे internal addresses आणि tokens पाहू शकते. नंतर पासवर्ड विसरलात? ब्राउझरऐवजी host मधून reset करा:

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

प्रथम तुमचे notification channels जोडा आणि त्यांची चाचणी घ्या

मॉनिटर्स जोडण्यापूर्वी अलर्ट सेट करा, जेणेकरून प्रत्येक मॉनिटर तयार करताना तुम्ही चॅनेल जोडू शकाल. Settings then Notifications then Setup Notification वर जा, आणि प्रत्येक चॅनेलचा Test बटण वापरून संदेश मिळतो की नाही याची खात्री करा; कारण न तपासलेले notification ही सेटअपमध्ये शांतपणे (silently) होणारी दुसरी सर्वात मोठी चूक आहे.

Email (SMTP). host, port, encryption, username, password, From आणि To भरा. दोन कार्यरत कॉम्बिनेशन्स म्हणजे 465 (ज्यामध्ये "Secure" TLS/SSL वर सेट आहे) किंवा 587 (STARTTLS सह). Gmail आणि 2FA असलेल्या बहुतेक प्रोव्हायडर्ससाठी तुम्हाला app password जनरेट करावा लागेल; सामान्य खाते पासवर्ड वापरल्यास Error: Invalid login: 535-5.7.8 Username and Password not accepted त्रुटी येते.

Telegram. @BotFather ला मेसेज करा, /newbot पाठवा, आणि bot token कॉपी करा. तुमच्या chat ID साठी, नवीन bot ला एकदा मेसेज करा, https://api.telegram.org/bot<token>/getUpdates उघडा, आणि JSON मधून chat.id वाचा. ज्या bot ला तुम्ही आधी मेसेज केलेला नाही, त्याचा getUpdates रिकामा असतो आणि संदेश कुठेही पाठवता येत नाही.

Discord. चॅनेलमध्ये, Edit Channel then Integrations then Webhooks then New Webhook उघडा, URL कॉपी करा, आणि ती Discord notification म्हणून पेस्ट करा.

Generic webhook. इतर कोणत्याही गोष्टीसाठी, जसे की Slack incoming webhook, custom endpoint, किंवा home-automation hook; Webhook प्रकार तुमच्याद्वारे पुरवलेल्या URL वर JSON payload POST करतो. तसेच, त्यातील Apprise integration इतर नऊ-दशak (ninety-odd) सेवांना सपोर्ट करते.

मॉनिटर्स जोडा, एक वेळी एक प्रकार

Add New Monitor वर क्लिक करा, एक प्रकार निवडा आणि Friendly Name, Check Interval (60 seconds योग्य आहे), Retries (एकत्रित अपयश आल्यास "down" मानण्यासाठी; 2 किंवा 3 ठेवा जेणेकरून एक पॅकेट ड्रॉप झाल्यामुळे अलर्ट येणार नाही), आणि नोटिफिकेशन सेट करा. तुम्ही वापरण्याचे प्रकार:

HTTP(s). पूर्ण URL. "Up" म्हणजे स्वीकारार्ह status code (बाय डिफॉल्ट 200-299; जर 301 किंवा 401 सामान्य असेल, तर Accepted Status Codes मध्ये व्याप्ती वाढवा). वेबसाइट्स आणि APIs साठी हा मुख्य प्रकार आहे.
HTTP(s) - Keyword. ही विनंती (request) सारखीच असते, परंतु "up" होण्यासाठी body मध्ये एक विशिष्ट string असणे आवश्यक आहे (किंवा Invert पर्याय नसावा). यामुळे वेबसाइट "Error establishing a database connection" असा संदेश दाखवत असतानाही 200 OK मिळवत असेल, तर ती शोधता येते; साधी HTTP तपासणी याला 'healthy' मानू शकते.
TCP Port. host आणि port कडे थेट TCP कनेक्शन, जे HTTP नसलेल्या गोष्टींसाठी वापरले जाते: 22 वर SSH, 5432 वर Postgres, 25 वर SMTP server, किंवा game server.
Ping. ICMP echo: कनेक्टिव्हिटी आणि latency तपासण्यासाठी सोपा मार्ग. परंतु अनेक networks आणि cloud firewalls ICMP ड्रॉप करतात, त्यामुळे लाल रंगाचा ping monitor म्हणजे "host down" किंवा "provider blocks ping" असू शकते; TCP monitor वापरून याची खात्री करा.
DNS. तुम्ही दिलेल्या resolver विरुद्ध रेकॉर्ड (A, AAAA, MX, TXT इत्यादी) रिझॉल्व्ह करते आणि उत्तराची पडताळणी करते, ज्यामुळे registrar किंवा DNS outage लवकर लक्षात येतो.
Push. 'Inside-out' मॉनिटर, ज्याबद्दल पुढे माहिती दिली आहे.

Push (heartbeat) मॉनिटरद्वारे cron job मॉनिटर करणे

वरील सर्व मॉनिटर्स तुमच्या सर्व्हिसमध्ये बाहेरून प्रवेश करतात. Push मॉनिटर याउलट पद्धतीने काम करतो: Uptime Kuma प्रतीक्षा करते आणि तुमचा job "मी यशस्वीरित्या चाललो आहे" असे सांगण्यासाठी त्याला कॉल करतो. बॅकअप किंवा cron तपासण्यासाठी ही एकमेव खात्रीशीर पद्धत आहे: HTTP चेकला URL प्रतिसाद देते हे समजते, परंतु job पूर्ण झाले आहे हे फक्त त्या job लाच माहित असते.

Push प्रकारचा मॉनिटर तयार करा. Uptime Kuma खालीलप्रमाणे एक युनिक URL तयार करते:

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

Heartbeat Interval हा job किती वेळा चालतो त्या वेळेपेक्षा थोडा जास्त ठेवा. त्यानंतर स्क्रिप्टच्या शेवटी एक ओळ जोडा, जेणेकरून ती फक्त यशस्वी झाल्यावरच कार्यान्वित होईल:

#!/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 अयशस्वी झाले, तर curl करण्यापूर्वी set -e थांबते; जर सिस्टम (box) बंद असेल, तर ती कधीच चालणार नाही. दोन्ही परिस्थितीत heartbeat थांबते, आणि एकदा interval-plus-retries विंडो संपली की, Uptime Kuma मॉनिटरची स्थिती down करते आणि तुम्हाला अलर्ट पाठवते. त्या push token ला गुप्त (secret) माना: तो ज्याच्याकडे असेल तो कोणीही 'healthy beat' पाठवू शकतो.

सार्वजनिक status page तयार करा

status page हे ग्राहकांसाठीचे दृश्य आहे: यामध्ये तुमचे dashboard उघड न करता, कोणती services सुरू आहेत आणि त्यांचा अलीकडील इतिहास काय आहे, हे दिसते. Status Pages then New Status Page वर जा, त्याला एक नाव आणि slug (सार्वजनिक path, जसे की /status/main) द्या, तुम्हाला हवे असलेले monitors "Websites" आणि "APIs" सारख्या groups मध्ये ओढा (drag), एक logo आणि थोडक्यात description जोडा आणि Save करा. तुम्ही या page ला स्वतःच्या domain शी देखील bind करू शकता, जेणेकरून status.example.com ते थेट सर्व्ह करेल.

दोन खबरदारी: फक्त तेच monitors समाविष्ट करा जे तुम्हाला सार्वजनिक करायचे आहेत, कारण status page मुळे एखादी service अस्तित्वात आहे आणि ती सुरू आहे की नाही हे समजते; आणि तुमचे dashboard तुमच्या login च्या मागे सुरक्षित राहते, तर status page जाणीवपूर्वक सार्वजनिक असते आणि त्याला कोणत्याही 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 लोड होईल पण connection होणार नाही; dashboard "Connecting..." दाखवेल, live heartbeats update होणार नाहीत आणि browser console मध्ये WebSocket connection to 'wss://.../socket.io/...' failed दिसेल.

nginx आणि certbot install करा, त्यानंतर loopback port ला proxy करणारा vhost लिहा. सध्या याला port 80 वर ठेवा आणि नंतर certbot द्वारे TLS सेट करा; यातील आव्हाने, 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 ला 443 port वर listen करण्यासाठी block 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 या दोन्ही गोष्टी 443 block मध्ये copy करतो. जर तुम्ही एकाच proxy मागे अनेक containers चालवत असाल, तर routing them through Traefik with automatic TLS मध्ये container labels वापरून हेच काम होते आणि WebSocket upgrades default ने forward केले जातात.

संपूर्ण vhost ला basic-auth करू नका, कारण यामुळे public status page आणि /api/push endpoint देखील लॉक होईल. Uptime Kuma चे built-in login वापरा, जर instance internet-facing असेल तर fail2ban watching for repeated failed logins वापरा, आणि जर dashboard public करण्याची गरज नसेल, तर proxy न वापरता VPN द्वारे access करा.

Certificate-expiry monitoring, done right

HTTP(s) monitor तुम्हाला TLS certificate संपण्यापूर्वी देखील सूचित करू शकते: Certificate Expiry Notification निवडा आणि Uptime Kuma ठराविक दिवस आधी अलर्ट देईल. दोन चुकांमुळे हे चुकीचे ठरते. IP ऐवजी hostname ने मॉनिटर करा, अन्यथा SNI शिवाय केलेल्या request ला सर्व्हरचे 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 तपासणे देखील समाविष्ट आहे.

Backups: it is one directory

सर्व काही /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 त्या नावाच्या आधी project directory जोडते. त्यानंतर tarball दुसऱ्या मशीनवर कॉपी करा; कारण त्याच VPS वर बॅकअप ठेवणे म्हणजे केवळ प्रत (copy) ठेवणे आहे, बॅकअप नाही. रिस्टोर (Restore) करण्याची प्रक्रिया उलट आहे: stack थांबवा, रिकाम्या /app/data वॉल्यूममध्ये फाईल्स extract करा आणि stack सुरू करा.

Upgrades

Upgrades म्हणजे image pull प्रक्रिया आहे:

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

नवीन container पहिल्यांदा सुरू होताना सर्व database migration पूर्ण करते; docker compose logs -f वर लक्ष ठेवा. image pull करण्यापूर्वी वरील backup नक्की घ्या. major tag च्या मर्यादेत राहा: :1 कडून :2 कडे जाणे ही एक-वे (one-way) migration प्रक्रिया आहे, त्यामुळे प्रथम backup घ्या आणि release notes तपासा.

Failure modes, with the strings you will see

localhost वर पॉइंट केलेल्या monitor वर चुकीचा "down" status दिसणे. monitor वर timeout of 48000ms exceeded किंवा connect ETIMEDOUT मुळे तो लाल होतो, तरीही तुमच्या laptop वरून service प्रतिसाद देते. जर monitor त्याच host वर असेल ज्यावर Uptime Kuma चालते, तर target ऐवजी CPU किंवा memory spike मुळे check fail झाले आहे. monitor एका वेगळ्या VPS वर हलवा आणि public hostname target करा.

connect ECONNREFUSED 127.0.0.1:443 (किंवा कोणताही port). त्या port वर काहीही listen होत नव्हते: एकतर service बंद आहे, किंवा तुम्ही localhost कंटेनरच्या आतून monitor करत आहात, जिथे 127.0.0.1 हा तुमचा server नसून container आहे. loopback ऐवजी public hostname monitor करा.

Email test मध्ये Invalid login: 535-5.7.8 Username and Password not accepted. SMTP credentials चुकीचे आहेत, किंवा provider ला app-specific password आवश्यक आहे आणि तुम्ही तुमच्या account password चा वापर केला आहे. app password तयार करा आणि तो वापरा.

Email test मध्ये connect ETIMEDOUT किंवा queryA ETIMEDOUT <host>. चुकीचा port, किंवा provider outbound SMTP ब्लॉक करतो. 465 किंवा 587 हे Secure/STARTTLS सेटिंगशी मॅच होते की नाही ते तपासा, आणि host वरून nc -vz smtp.example.com 587 वापरून test करा. अनेक providers outbound 25 ब्लॉक करतात आणि काही providers विनंती केल्याशिवाय submission ports ब्लॉक करतात.

Email test मध्ये self signed certificate किंवा unable to verify the first certificate. तुमचा SMTP server असा certificate सादर करतो जो Node ला विश्वासार्ह वाटत नाही; certificate वर तात्पुरता उपाय करण्याऐवजी mail server चे certificate दुरुस्त करा.

Dashboard "Connecting..." वर अडकले आहे, console मध्ये WebSocket connection ... failed दिसत आहे. reverse proxy WebSocket upgrade करत नाहीये. nginx वर Upgrade आणि Connection "upgrade" headers जोडा, किंवा Traefik किंवा Caddy सारखा proxy वापरा जो them by default forward करतो. HTML लोड होते कारण ते एक सामान्य HTTP GET आहे; फक्त live socket ला upgrade ची गरज असते.

Cert-expiry monitor कधीही warning देत नाही, किंवा चुकीची warning देतो. एकतर Ignore TLS/SSL Error टिक केले आहे, ज्यामुळे cert checking बंद होते, किंवा monitor IP address 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 वर आहे ज्यामध्ये proper file locking नाही, सहसा NFS; ते local Docker volume वर हलवा आणि backup मधून restore करा.

FAQ

मी माझा uptime monitor कुठे चालवू?

तो ज्या सर्व्हर्सवर लक्ष ठेवतो, त्यापेक्षा वेगळ्या सर्व्हरवर चालवा. शक्यतो दुसरा provider किंवा region निवडा. युजर्सप्रमाणेच public internet वरून hostname द्वारे त्या सर्व्हर्सपर्यंत पोहोचा. जर monitor आणि target एकाच box मध्ये असतील, तर सर्व्हर डाऊन झाल्यास monitor सुद्धा बंद पडेल. तसेच, host वर जास्त लोड असल्यास, सर्व्हर्स व्यवस्थित असूनही monitor "down" असा चुकीचा अलर्ट देऊ शकतो. या दोन्ही समस्या टाळण्यासाठी एक छोटा, वेगळा VPS वापरा.

मला Telegram किंवा email वर alerts कसे मिळतील?

Settings मध्ये जाऊन Notifications अंतर्गत चॅनेल निवडा आणि ते प्रत्येक monitor ला जोडा. Telegram साठी, @BotFather वापरून bot तयार करा आणि https://api.telegram.org/bot<token>/getUpdates मधून chat.id वाचा; email साठी, SSL साठी 465 किंवा STARTTLS साठी 587 वापरा (जर तुमचा provider two-factor auth वापरत असेल, तर app password वापरा). Test बटण दाबा आणि मेसेज व्यवस्थित येत असल्याची खात्री करा.

Uptime Kuma द्वारे मी cron job किंवा backup script monitor करू शकतो का?

हो, त्यासाठी Push monitor वापरा: Uptime Kuma तुम्हाला एक URL देतो आणि तुम्ही script च्या शेवटी curl करू शकता, ज्यामुळे फक्त यशस्वीतेनंतरच तो अलर्ट पाठवेल. जर job फेल झाले किंवा box डाऊन असेल, तर heartbeat मिळणार नाही आणि ठराविक interval संपल्यानंतर तुम्हाला अलर्ट मिळेल. scheduled job प्रत्यक्षात चालली आहे की नाही हे जाणून घेण्याचा हा एकमेव विश्वासार्ह मार्ग आहे, कारण external check द्वारे script च्या अंतर्गत प्रक्रिया पाहता येत नाहीत.

Uptime Kuma vs Zabbix, मी काय वापरावे?

Uptime Kuma "बाहेरून सर्व्हर चालू आहे का आणि मला अलर्ट मिळाला का" याचे उत्तर केवळ 10 मिनिटांत आणि अत्यंत कमी resources वापरून देते, सोबत status page देखील मिळते. हे CPU, memory आणि disk trends सारखी सखोल metrics किंवा fleet-wide thresholds गोळा करत नाही; त्यासाठी a full Zabbix monitoring server हे agent-based आणि अधिक वजनदार tool आहे. अनेक लोक दोन्ही वापरतात. अजूनही निर्णय घेण्यास कठीण जात आहे का? our roundup of what to self-host in 2026 मध्ये तुम्हाला अधिक माहिती मिळेल.

#uptime-kuma#monitoring #docker #self-hosting#status-page