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

Uptime Kuma स्वतःच्या सर्व्हरवर कसे सेट करावे?

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

Settings then Notifications अंतर्गत channel जोडा. त्यानंतर तो प्रत्येक 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 चे निरीक्षण करू शकतो का?

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

Docker मध्ये Uptime Kuma चालवून websites, ports, DNS आणि cron jobs तपासा. email किंवा Telegram alerts आणि स्वतंत्र VPS वर status page सेट करण्याची पद्धत जाणून घ्या.

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

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

मॉनिटर outage पोहोचू शकणार नाही अशा ठिकाणी चालवा

हा एक निर्णय संपूर्ण रचना यशस्वी होईल की अपयशी ठरेल हे ठरवतो, त्यामुळे तो प्रथम येतो. ज्या सर्व्हरवरील सेवांचे निरीक्षण करायचे आहे, त्याच सर्व्हरवर Uptime Kuma चालवू नका. मॉनिटरने निरीक्षण केलेल्या सर्व्हरवरच चालत असेल, तर तुम्हाला महत्त्वाची असलेली घटना, म्हणजे सर्व्हर बंद पडणे किंवा त्याची memory संपणे, मॉनिटरलाही बंद पाडते. त्यामुळे कोणताही alert मिळत नाही: बंद मॉनिटरकडून मिळणारे शांत राहणे हे “सर्व काही ठीक आहे” असेच दिसते. सर्व्हर सुरू असतानाही आणखी एक सूक्ष्म धोका असतो. localhost कडे निर्देशित केलेला मॉनिटर workload सोबतच CPU वापरतो. त्यामुळे load spike झाल्यास त्याची स्वतःची तपासणी timeout होऊ शकते आणि target down असे दाखवले जाऊ शकते. हा false alarm असतो; प्रत्यक्ष वापरकर्त्यांना सेवा व्यवस्थित मिळत असते.

म्हणून Uptime Kuma चे निरीक्षण करावयाच्या सर्व्हरपेक्षा वेगळ्या VPS वर चालवा. शक्य असल्यास वेगळा provider किंवा region वापरा. तुमच्या वापरकर्त्यांप्रमाणे public internet वरून hostname द्वारे सेवांपर्यंत पोहोचा. स्वस्त instance पुरेसा आहे. एक छोटा monitoring VPS तुमच्या सर्व्हरचे निरीक्षण करू शकतो. तुम्ही host करत असलेल्या मोठ्या अॅप्ससाठी हे विभाजन विशेष महत्त्वाचे आहे. उदाहरणार्थ, PhotoPrism किंवा Immich photo library नवीन import चे indexing करताना तासन्तास CPU पूर्णपणे वापरू शकते. त्याच hardware वर चालणारा मॉनिटर केवळ सेवा व्यस्त असताना ती down असल्याचा alert देऊ शकतो. Kuma स्वतः बंद पडल्याचे समजण्यासाठी, दुसऱ्या ठिकाणाहून cron द्वारे push heartbeat जोडा.

पूर्वतयारी आणि आकारमान

Docker च्या स्वतःच्या apt repository मधून स्थापित केलेला Docker Engine आणि Compose v2 plugin असलेला नवीन Ubuntu 24.04 VPS. docker.io distro package वापरू नका; ते जुन्या आवृत्तीचे असते.
काही monitors चालवण्यासाठी 256 MB RAM पुरेशी आहे. reverse proxy सह डझनभर monitors चालवण्यासाठी 512 MB ते 1 GB RAM आरामदायक आहे. तपासण्यांदरम्यान CPU वापर जवळपास शून्य असतो.
एक domain आणि DNS A record (उदाहरणार्थ, status.example.com VPS कडे निर्देश करणारा), पण TLS आणि सार्वजनिक status page हवे असल्यासच. Private instance साठी DNS टाळून VPN किंवा SSH tunnel वापरता येतो.
Alerts ज्या ठिकाणी पाठवायचे आहेत तिथे outbound network उपलब्ध असणे आवश्यक आहे: तुमच्या 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 वेळी काय होते ते 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

योग्यरीत्या सुरू झाल्यावर logs मध्ये Listening on 3001 दिसते आणि त्यानंतर logs शांत होतात. त्या फाइलमधील तीन गोष्टी जाणीवपूर्वक अशा ठेवलेल्या आहेत.

127.0.0.1:3001:3001, 3001:3001 नाही. Docker पोर्ट प्रकाशित करण्यासाठी DNAT नियम वापरते. हे नियम ufw ला पॅकेट दिसण्यापूर्वी लागू होतात. त्यामुळे साधे 3001:3001 वापरल्यास firewall काहीही असला तरी तुमचे dashboard सार्वजनिक इंटरनेटवर उपलब्ध होते. Loopback ला bind केल्याने ते private राहते आणि केवळ reverse proxy उघडा ठेवला जातो; 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 घेणे आवश्यक असलेली ही एकमेव गोष्ट आहे.

Image ला major tag :2 वर pin केले आहे. ही सध्याची stable line आहे. फाइल copy करण्यापूर्वी नवीनतम major version साठी Docker Hub तपासा. latest सारखा बदलता tag कधीही वापरू नका; project तो deprecate करत आहे. या image मध्ये major-version jump झाल्यास database migration एकतर्फी होते. ती नियमित pull दरम्यान अनवधानाने होऊ न देता जाणीवपूर्वक सुरू करणे आवश्यक आहे.

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

पहिली सुरुवात: admin 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 निवडा: तुम्ही monitor करत असलेल्या सर्व गोष्टींचे internal addresses आणि tokens या dashboard ला दिसतात. नंतर password विसरलात? तो browser मधून नव्हे, host वरून reset करा:

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

प्रथम सूचना चॅनेल जोडा आणि त्यांची चाचणी करा

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

Email (SMTP). host, port, encryption, username, password, From आणि To भरा. कार्यरत असलेल्या दोन जोड्या म्हणजे 465 आणि "Secure" साठी TLS/SSL, किंवा 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 कॉपी करा. तुमचा chat ID मिळवण्यासाठी नवीन bot ला प्रथम एकदा message पाठवा, https://api.telegram.org/bot<token>/getUpdates उघडा आणि JSON मधील chat.id वाचा. ज्या bot ला तुम्ही प्रथम message पाठवलेला नाही, त्याच्याकडे रिकामे getUpdates असते आणि message पाठवण्यासाठी कोणतेही ठिकाण उपलब्ध नसते.

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

Generic webhook. इतर कोणत्याही सेवेसाठी, जसे Slack incoming webhook, custom endpoint किंवा home-automation hook, Webhook type तुम्ही दिलेल्या URL वर JSON payload POST करतो. यादीतील इतर सुमारे ninety services साठी bundled Apprise integration पुरेसे आहे. आउटेज आणि तुमच्या फोनमध्ये कोणताही third party मध्यस्थ नको असल्यास, अंगभूत ntfy type निवडा आणि तो तुम्ही स्वतः चालवत असलेल्या ntfy server कडे निर्देशित करा. यामुळे तुम्ही end to end नियंत्रित करत असलेल्या चॅनेलद्वारे तुमच्या handset वर सूचना push होतात.

एकावेळी एक प्रकारचे monitor जोडा

Add New Monitor वर क्लिक करा, प्रकार निवडा आणि Friendly Name, Check Interval (60 seconds योग्य आहे), Retries ("down" घोषित करण्यापूर्वीच्या सलग अपयशांची संख्या; एक packet drop झाल्यामुळे page होऊ नये म्हणून 2 किंवा 3) आणि कोणत्या notifications पाठवायच्या ते निश्चित करा. तुम्ही वापरणार असलेले प्रकार:

HTTP(s). पूर्ण URL. स्वीकारलेला status code मिळाल्यास monitor up मानला जातो (डीफॉल्टनुसार 200-299; तुमच्यासाठी 301 किंवा 401 सामान्य असल्यास Accepted Status Codes अंतर्गत श्रेणी वाढवा). Websites आणि APIs साठी हा मुख्य monitor आहे.
HTTP(s) - Keyword. हीच request पाठवली जाते; मात्र body मध्ये एखादी string आढळल्यास, किंवा Invert निवडल्यावर ती string अनुपस्थित असल्यासच monitor "up" मानला जातो. साध्या HTTP check ला healthy वाटणारी साइट प्रत्यक्षात 200 OK परत करताना "Error establishing a database connection" दाखवत असेल, तर हे ओळखता येते. स्वतंत्र backend शी संवाद साधणाऱ्या browser front end साठीही हा योग्य check आहे. उदाहरणार्थ, Jellyfin वर चालणारा Halcyon video-store skin; त्याचा page shell 200 यशस्वीपणे परत करू शकतो, पण त्यामागील media server unreachable असू शकतो.
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 packets drop करतात. त्यामुळे red ping monitor चा अर्थ "host down" किंवा "provider blocks ping" असा दोन्ही असू शकतो. TCP monitor वापरून पुष्टी करा.
DNS. तुम्ही निर्दिष्ट केलेल्या resolver विरुद्ध A, AAAA, MX, TXT इत्यादी record resolve करतो आणि उत्तर अपेक्षित आहे का ते तपासू शकतो. त्यामुळे registrar किंवा DNS outage लवकर ओळखता येतो.
Push. आतून बाहेरच्या दिशेने तपासणी करणारा monitor. पुढील भागात त्याचे वर्णन आहे.

push (heartbeat) monitor ने cron job चे निरीक्षण करणे

वरील प्रत्येक monitor बाहेरून तुमच्या सेवेपर्यंत पोहोचून तिची तपासणी करतो. Push monitor याच्या उलट कार्य करतो: Uptime Kuma प्रतीक्षा करतो आणि तुमचे job त्याला “मी चालले” असे सांगण्यासाठी call करते. Backup किंवा cron चे निरीक्षण करण्याचा हा एकमेव विश्वसनीय मार्ग आहे: HTTP check ला एखादा URL प्रतिसाद देत आहे एवढेच माहीत असते; पण job पूर्ण झाले की नाही हे फक्त job लाच माहीत असते.

Push प्रकारचा monitor तयार करा. Uptime Kuma यासारखा unique URL तयार करतो:

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

Heartbeat Interval हे job ज्या वारंवारतेने चालते त्यानुसार सेट करा आणि थोडी अतिरिक्त मुभा ठेवा. त्यानंतर script च्या शेवटी एक ओळ जोडा, म्हणजे ती फक्त यशस्वी झाल्यावरच execute होईल:

#!/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 पर्यंत पोहोचण्यापूर्वी थांबते; box बंद असल्यासही ते चालत नाही. दोन्ही परिस्थितींमध्ये heartbeat थांबतो. Interval-plus-retries window संपल्यानंतर Uptime Kuma monitor ची स्थिती down करतो आणि तुम्हाला alert पाठवतो. त्या push token ला secret समजा: तो ज्याच्याकडे असेल तो healthy beat बनावट पद्धतीने पाठवू शकतो.

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

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

दोन गोष्टी लक्षात ठेवा. फक्त सार्वजनिक करण्यास हरकत नसलेले monitors जोडा. status page मुळे एखादी सेवा अस्तित्वात आहे का आणि ती सुरू आहे का हे दिसते. dashboard तुमच्या login मागेच राहतो. त्याउलट status page जाणीवपूर्वक सार्वजनिक असतो आणि त्यासाठी authentication आवश्यक नसते.

TLS सह reverse proxy मागे ठेवा आणि WebSocket कनेक्शन लक्षात घ्या

सार्वजनिक instance साठी, TLS आणि hostname देण्यासाठी loopback-bound container च्या पुढे reverse proxy ठेवा. सर्वांना अडचणीत आणणारा महत्त्वाचा मुद्दा हा आहे: Uptime Kuma चे UI हे live Socket.IO app आहे, त्यामुळे proxy ने WebSocket कनेक्शन upgrade केले पाहिजे. हे चुकल्यास page load होते, पण कनेक्शन कधीच स्थापित होत नाही; 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 जोडू द्या; 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 दीर्घकाळ टिकणारे socket बंद करत नाही; certbot तयार केलेल्या 443 block मध्ये या दोन्ही lines copy करतो. एका proxy मागे आधीच अनेक containers चालवत असल्यास, automatic TLS सह Traefik मधून त्यांचे routing करणे हाच प्रकार container labels वापरून करते आणि WebSocket upgrades default ने forward करते.

संपूर्ण vhost वर basic authentication लागू करू नका, कारण त्यामुळे public status page आणि /api/push endpoint देखील बंद होतील. Uptime Kuma चे built-in login तसेच ठेवा. ते internet-facing असल्यास, वारंवार होणाऱ्या अयशस्वी login प्रयत्नांवर fail2ban ने लक्ष ठेवणे जोडा. Dashboard सार्वजनिक असण्याची गरज नसेल, तर proxy काढून VPN द्वारे त्याच्यापर्यंत पोहोचा.

प्रमाणपत्राची मुदत संपण्याचे योग्य पद्धतीने निरीक्षण

HTTP(s) मॉनिटर TLS प्रमाणपत्राची मुदत संपण्यापूर्वीही सूचना देऊ शकतो: Certificate Expiry Notification निवडा. त्यानंतर Uptime Kuma ठरावीक दिवस आधी alert देते. दोन चुका झाल्यास ते चुकीचे परिणाम दाखवू शकते. IP ऐवजी hostname नुसार मॉनिटर करा. SNI नसलेल्या विनंतीला सर्व्हरचे default प्रमाणपत्र मिळते आणि तुम्हाला Hostname/IP does not match certificate's altnames दिसते. तसेच, ज्या मॉनिटरकडून मुदत संपण्याच्या सूचना हव्या आहेत त्यावर Ignore TLS/SSL Error निवडू नका. हा पर्याय self-signed अंतर्गत host साठी आहे (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT). मात्र तो Uptime Kuma ला प्रमाणपत्र तपासण्यापासून पूर्णपणे थांबवतो; त्यात मुदत संपण्याची तपासणीही समाविष्ट आहे.

बॅकअप: ही एकच directory आहे

सर्व डेटा /app/data मध्ये असल्यामुळे, container थांबवलेल्या स्थितीत त्या volume ची प्रत घेतली की बॅकअप तयार होतो. त्यामुळे SQLite file सुसंगत राहते:

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 च्या नावाने prefix करते. त्यानंतर tarball सर्व्हरच्या बाहेर copy करा, कारण त्याच VPS वरील बॅकअप ही केवळ प्रत असते; तो स्वतंत्र बॅकअप नसतो. Restore ची प्रक्रिया उलट आहे: stack थांबवा, रिकाम्या /app/data volume मध्ये archive extract करा आणि stack सुरू करा.

श्रेणीसुधारणा

श्रेणीसुधारणा म्हणजे image pull करणे:

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

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

अपयशाच्या स्थिती आणि दिसणारे संदेश

localhost कडे निर्देश करणाऱ्या monitor वर चुकीचे "down" दिसणे. Monitor वर timeout of 48000ms exceeded किंवा connect ETIMEDOUT दिसते, तरी सेवा तुमच्या laptop वरून प्रतिसाद देते. जर monitor Uptime Kuma चालू असलेल्या त्याच host ला लक्ष्य करत असेल, तर CPU किंवा memory वाढल्यामुळे check साठी पुरेशी संसाधने उरली नाहीत; target मध्ये समस्या नाही. Monitor वेगळ्या VPS वर हलवा आणि public hostname ला लक्ष्य करा.

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

ईमेल चाचणीमध्ये Invalid login: 535-5.7.8 Username and Password not accepted. SMTP credentials चुकीचे आहेत किंवा provider ला app-specific password आवश्यक आहे, पण त्याऐवजी account password दिला आहे. App password तयार करून तो प्रविष्ट करा.

ईमेल चाचणीमध्ये connect ETIMEDOUT किंवा queryA ETIMEDOUT <host>. Port चुकीचा आहे किंवा provider outbound SMTP अवरोधित करतो. 465 किंवा 587 हे Secure/STARTTLS setting शी जुळते का ते तपासा आणि host वरून nc -vz smtp.example.com 587 ने चाचणी करा. अनेक provider outbound 25 अवरोधित करतात. काही provider कडे submission ports वापरण्यासाठी आधी विनंती करावी लागते.

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

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

Cert-expiry monitor कधीही warning देत नाही किंवा चुकीची warning देतो. Ignore TLS/SSL Error निवडलेले असू शकते. त्यामुळे certificate तपासणी बंद होते. किंवा monitor IP ला लक्ष्य करतो आणि SNI नसल्यामुळे चुकीचे certificate वाचतो; त्यात Hostname/IP does not match certificate's altnames दिसते. Ignore पर्याय निवडलेला नसल्याची खात्री करा आणि hostname वापरून monitor करा.

Logs मध्ये SQLITE_BUSY किंवा database disk image is malformed. /app/data volume योग्य file locking नसलेल्या filesystem वर आहे, सामान्यतः NFS वर. तो local Docker volume वर हलवा आणि backup मधून restore करा.

FAQ

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

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

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

Settings then Notifications अंतर्गत channel जोडा. त्यानंतर तो प्रत्येक 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 चे निरीक्षण करू शकतो का?

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

Uptime Kuma विरुद्ध Zabbix: मी कोणते चालवावे?

Uptime Kuma "ते बाहेरून उपलब्ध आहे का आणि त्याने मला alert दिला का" या प्रश्नाचे उत्तर दहा मिनिटांत आणि अत्यल्प resources वापरून देते. त्यासोबत status page देखील मिळते. मात्र ते CPU, memory आणि disk trends किंवा fleet-wide thresholds यांसारखे सखोल metrics गोळा करत नाही. त्यासाठी पूर्ण Zabbix monitoring server हे अधिक संसाधने लागणारे, agent-based tool आहे. अनेक जण दोन्ही चालवतात. अजूनही काय चालवायचे हे ठरलेले नसेल, तर 2026 मध्ये self-host करण्यासारख्या गोष्टींचा आमचा आढावा monitoring चा संदर्भ स्पष्ट करतो.

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