توسط Matt Connor 2026-07-15 · به‌روزرسانی شده 2026-07-24

نصب و راه‌اندازی Uptime Kuma در Docker

Q: کجا باید مانیتورینگ uptime خود را اجرا کنم؟

روی سروری متفاوت از سرورهایی که تحت نظارت هستند؛ ایدهآل این است که از یک ارائهدهنده یا منطقه (region) دیگر استفاده کنید تا مانیتورینگ دقیقاً مانند کاربران شما، از طریق hostname و در اینترنت عمومی به آنها متصل شود. اگر مانیتورینگ با هدفهای مورد نظرتان در یک سرور مشترک باشد، قطعی که باعث از کار افتادن سرور میشود، مانیتور را هم از کار میاندازد؛ همچنین فشار زیاد روی host باعث میشود مانیتورینگ برای سرویسهایی که سالم هستند، وضعیت "down" گزارش دهد. استفاده از یک VPS کوچک و مجزا، هر دو مشکل را حل میکند.

Q: چگونه هشدارها را در Telegram یا ایمیل دریافت کنم؟

کانال مورد نظر را در مسیر Settings then Notifications اضافه کنید و سپس آن را به هر مانیتور متصل کنید. برای Telegram، یک bot با استفاده از @BotFather بسازید و chat.id را از https://api.telegram.org/bot /getUpdates بخوانید؛ برای ایمیل، اگر ارائهدهنده شما از تایید دو مرحلهای استفاده میکند، از 465 برای SSL یا از 587 برای STARTTLS به همراه یک app password استفاده کنید. قبل از اعتماد به سیستم، دکمه Test را فشار دهید و رسیدن پیام را تایید کنید.

Q: آیا Uptime Kuma میتواند یک cron job یا اسکریپت backup را مانیتور کند؟

بله، این قابلیت مربوط به مانیتور از نوع Push است: Uptime Kuma یک URL به شما میدهد و شما در انتهای اسکریپت آن را curl میکنید تا فقط در صورت موفقیت اجرا شود. اگر کار با شکست مواجه شود یا سرور از دسترس خارج شود، heartbeat هرگز ارسال نمیشود و پس از پایان بازه زمانی (interval)، شما مطلع میشوید. این تنها راه قابل اعتماد برای اطمینان از اجرای یک کار زمانبندی شده است، زیرا یک بررسی خارجی نمیتواند جزئیات داخلی اسکریپت را ببیند.

آموزش نصب Uptime Kuma در Docker برای پایش وب‌سایت و DNS. یادگیری نحوه ارسال Alert via Telegram و مدیریت صفحه وضعیت با کمترین میزان مصرف RAM.

آنچه در حال ساخت آن هستید

یک کانتینر کوچک و واحد که سرورها و وب‌سایت‌های شما را از بیرون پایش می‌کند و به محض از دسترس خارج شدن هر کدام، از طریق email، Telegram، Discord یا یک webhook به شما اطلاع می‌دهد. Uptime Kuma یک پروسه Node است که از یک فایل SQLite پشتیبانی می‌کند؛ بنابراین به‌راحتی در 256-512 MB از RAM اجرا می‌شود و به شما یک داشبورد زنده، نمودارهای تاریخچه و یک صفحه وضعیت عمومی ارائه می‌دهد. نصب آن تنها یک Compose file 10 خطی است؛ نکته حیاتی این است که آن را کجا اجرا می‌کنید و آیا هشدارهای شما در یک تست با موفقیت ارسال شده‌اند یا خیر؛ زیرا مانیتوری که قابلیت رسیدن پیام‌های آن را هرگز اثبات نکرده‌اید، بدتر از نبودن آن است: زیرا باعث می‌شود در حالی که هیچ چیز را پایش نمی‌کنید، احساس امنیت کاذب داشته باشید.

مانیتور را در جایی اجرا کنید که قطعی سرویس به آن دسترسی نداشته باشد

این تصمیم تعیین‌کننده کل فرآیند است، بنابراین در اولویت قرار دارد. Uptime Kuma را روی همان سروری که از آن پایش می‌کنید، اجرا نکنید. اگر مانیتور روی همان سروری باشد که تحت نظارت دارد، دقیقاً همان اتفاقی که نگران آن هستید (از کار افتادن سرور یا اتمام حافظه RAM)، مانیتور را هم از کار می‌اندازد و شما هیچ هشداری دریافت نمی‌کنید: سکوتِ یک مانیتورِ از کار افتاده، دقیقاً با وضعیت "همه چیز روبه‌راه است" یکی است. یک تله ظریف‌تر حتی در زمان زنده بودن سرور وجود دارد: مانیتوری که به localhost اشاره دارد، از CPU با بار کاری (workload) مشترک است؛ بنابراین افزایش ناگهانی بار (load spike)، باعث Timeout شدن بررسی مانیتور و تغییر وضعیت هدف به down می‌شود؛ این یک هشدار کاذب است، در حالی که سرویس‌دهی به کاربران واقعی بدون مشکل انجام می‌شود.

بنابراین Uptime Kuma را روی یک VPS متفاوت نسبت به سرور مورد نظر اجرا کنید؛ ایده‌آل این است که از یک ارائه‌دهنده یا منطقه (region) متفاوت باشد تا سرویس‌های شما را دقیقاً همان‌گونه که کاربران می‌بینند، پایش کند: یعنی از طریق اینترنت عمومی و با استفاده از hostname. یک instance ارزان‌قیمت کافی است و یک VPS کوچک برای مانیتورینگ می‌تواند تمام سرورهای شما را تحت نظر داشته باشد. برای تشخیص از کار افتادن خودِ Kuma، یک push heartbeat از طریق یک cron در جایی دیگر اضافه کنید.

پیش‌نیازها و تعیین اندازه سیستم

یک VPS تازه با Ubuntu 24.04 که Docker Engine و افزونه Compose v2 روی آن نصب شده باشد. این ابزارها باید مستقیماً از مخزن apt خودِ Docker نصب شوند، نه از پکیج توزیع docker.io، زیرا نسخه‌ی آن قدیمی‌تر است.
مقدار RAM: برای اجرای تعداد محدودی مانیتور، 256 MB کافی است؛ برای اجرای ده‌ها مانیتور به همراه reverse proxy، مقدار 512 MB تا 1 GB مناسب است. میزان استفاده از CPU در فواصل بین بررسی‌ها، نزدیک به صفر (idle) خواهد بود.
یک دامنه و یک رکورد DNS A (مثلاً status.example.com که به VPS اشاره می‌کند)؛ فقط در صورتی که به TLS و یک صفحه وضعیت (status page) عمومی نیاز دارید. برای نصب خصوصی، می‌توانید از DNS استفاده نکنید و از VPN یا SSH tunnel استفاده کنید.
دسترسی شبکه خروجی (Outbound) به مقصدی که هشدارها به آن ارسال می‌شوند: SMTP برای سرویس ایمیل شما، یا HTTPS برای Telegram و Discord.

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:

آن را اجرا کنید و فرآیند اولین بوت را مشاهده کنید:

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 منتشر می‌کند که قبل از اینکه ufw بسته‌ای را ببیند، ارزیابی می‌شوند؛ بنابراین یک 3001:3001 ساده، داشبورد شما را بدون توجه به فایروال، در اینترنت عمومی قرار می‌دهد. متصل کردن به loopback باعث می‌شود دسترسی خصوصی باقی بماند و فقط reverse proxy در معرض دید باشد؛ یک نمونه خصوصی می‌تواند از پروکسی عبور کند و از طریق a self-hosted WireGuard VPN به 3001 دسترسی داشته باشد.

یک volume نام‌گذاری شده در /app/data. تمام آنچه Uptime Kuma به خاطر می‌سپارد، از جمله پایگاه داده SQLite، مانیتورها، تنظیمات اعلان‌ها و لوگوهای صفحه وضعیت، در آنجا ذخیره می‌شود. با از دست دادن آن، با یک صفحه مدیریت خالی مواجه خواهید شد؛ این تنها موردی است که باید از آن پشتیبان (backup) تهیه کنید.

تصویر (image) به یک تگ اصلی، :2، محدود شده است. این نسخه پایدار فعلی است؛ قبل از کپی کردن، Docker Hub را برای جدیدترین نسخه اصلی بررسی کنید و هرگز از تگ‌های متغیر مانند latest استفاده نکنید، زیرا پروژه آن‌ها را منسوخ (deprecate) کرده است. تغییر نسخه اصلی در این تصویر، یک مهاجرت پایگاه داده (database migration) یک‌طرفه است که باید آگاهانه انجام شود، نه اینکه در یک pull معمولی با آن مواجه شوید.

یک نکته مهم: /app/data باید روی یک سیستم فایل با قابلیت POSIX file locks قرار داشته باشد. یک Docker volume محلی مناسب است؛ در NFS پایگاه داده SQLite خراب می‌شود و با SQLITE_BUSY و database disk image is malformed مواجه می‌شوید، بنابراین هرگز از اشتراک‌گذاری شبکه (network share) استفاده نکنید.

اولین اجرا: ایجاد حساب administrator

از طریق proxy خود در https://status.example.com یا با استفاده از یک SSH tunnel به instance متصل شوید: دستور ssh -L 3001:127.0.0.1:3001 user@your-vps را اجرا کرده و http://localhost:3001 را باز کنید. اولین صفحه، فرم تنظیمات برای نام کاربری و رمز عبور administrator است؛ هیچ نام کاربری پیش‌فرضی وجود ندارد. یک رمز عبور واقعی انتخاب کنید: این dashboard به آدرس‌های داخلی و توکن‌های تمام موارد تحت نظارت دسترسی دارد. اگر رمز عبور را فراموش کردید، آن را از طریق host بازنشانی کنید، نه از طریق مرورگر:

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

ابتدا کانال‌های اطلاع‌رسانی خود را اضافه و آن‌ها را تست کنید

پیش از افزودن مانیتورها، هشدارهای خود را تنظیم کنید تا بتوانید هنگام ساخت هر مانیتور، یک کانال به آن متصل کنید. به مسیر Settings then Notifications then Setup Notification بروید و از دکمه Test هر کانال استفاده کنید تا از رسیدن پیام مطمئن شوید؛ زیرا یک اطلاع‌رسانی تست‌نشده، دومین دلیل رایج در شکست بی‌صدای تنظیمات است.

Email (SMTP). فیلدهای host، port، encryption، username، password، یک From و یک To را پر کنید. دو ترکیب سالم عبارتند از 465 با تنظیم "Secure" روی TLS/SSL، یا 587 با STARTTLS. برای Gmail و اکثر ارائه‌دهندگانی که دارای تایید هویت دو مرحله‌ای هستند، باید یک app password ایجاد کنید؛ استفاده از رمز عبور معمولی حساب کاربری منجر به خطای Error: Invalid login: 535-5.7.8 Username and Password not accepted می‌شود.

Telegram. به @BotFather پیام دهید، /newbot ارسال کنید و bot token را کپی کنید. برای یافتن chat ID خود، یک بار به بات جدید پیام دهید، https://api.telegram.org/bot<token>/getUpdates را باز کنید و chat.id را از JSON بخوانید. باتی که قبلاً به آن پیام نداده‌اید، دارای getUpdates خالی است و جایی برای ارسال پیام ندارد.

Discord. در کانال مورد نظر، مسیر Edit Channel then Integrations then Webhooks then New Webhook را باز کنید، URL را کپی کنید و آن را به عنوان یک اطلاع‌رسانی Discord وارد کنید.

Generic webhook. برای سایر موارد، مانند Slack incoming webhook، یک endpoint سفارشی یا هوک اتوماسیون خانگی، نوع Webhook یک payload از نوع JSON را به URL ارائه‌شده POST می‌کند. همچنین یکپارچه‌سازی Apprise اکثر 90 سرویس دیگر در لیست را پوشش می‌دهد.

افزودن مانیتورها، هر بار یک نوع

روی Add New Monitor کلیک کنید، یک نوع را انتخاب کنید، و Friendly Name، Check Interval (مقدار 60 seconds منطقی است)، Retries (تعداد شکست‌های متوالی قبل از وضعیت "down"؛ مقدار 2 یا 3 انتخاب شود تا یک بسته گم‌شده باعث ارسال اعلان نشود) و اعلان‌های مورد نظر را تنظیم کنید. انواع مانیتورهایی که استفاده خواهید کرد:

HTTP(s). یک URL کامل. وضعیت "up" به معنای دریافت کد وضعیت پذیرفته شده است (به صورت پیش‌فرض 200-299؛ اگر 301 یا 401 برای شما عادی است، آن را در بخش Accepted Status Codes تغییر دهید). ابزار اصلی شما برای وب‌سایت‌ها و APIها.
HTTP(s) - Keyword. همان درخواست قبلی، اما وضعیت "up" مستلزم وجود یک رشته متنی در بدنه پاسخ است (مگر اینکه گزینه Invert غیرفعال باشد). این حالت باعث می‌شود اگر سایت در حین رندر شدن عبارت "Error establishing a database connection" را برگرداند و کد 200 OK را ارسال کند، مانیتور متوجه خطا شود؛ در حالی که یک بررسی ساده HTTP آن را سالم تشخیص می‌دهد.
TCP Port. یک اتصال TCP مستقیم به یک host و port برای مواردی که HTTP نیستند: مانند SSH روی پورت 22، Postgres روی پورت 5432، یک سرور SMTP روی پورت 25، یا یک سرور بازی.
Ping. پروتکل ICMP echo: برای بررسی دسترسی و تأخیر (latency) با هزینه بسیار کم. اما بسیاری از شبکه‌ها و فایروال‌های ابری، ICMP را مسدود می‌کنند؛ بنابراین یک مانیتور Ping قرمز می‌تواند به معنای "host down" باشد یا اینکه "provider blocks ping"؛ این موضوع را با یک مانیتور TCP تأیید کنید.
DNS. یک رکورد (مانند A, AAAA, MX, TXT و غیره) را در برابر یک resolver مشخص حل می‌کند و می‌تواند پاسخ را تأیید کند؛ این کار باعث شناسایی زودهنگام قطعی ثبت‌کننده (registrar) یا قطعی DNS می‌شود.
Push. مانیتور از درون به بیرون (inside-out) که در بخش بعدی بررسی می‌شود.

مانیتورینگ یک cron job با استفاده از مانیتورینگ push (heartbeat)

تمام مانیتورهای ذکر شده در بالا، از بیرون به سرویس شما متصل می‌شوند. یک مانیتور push برعکس عمل می‌کند: Uptime Kuma منتظر می‌ماند و job شما برای اعلام وضعیت "اجرا شد"، آن را فراخوانی می‌کند. این تنها روش مطمئن برای نظارت بر یک backup یا cron است: یک بررسی HTTP فقط از پاسخگویی URL مطلع می‌شود، اما فقط خودِ job می‌داند که عملیات با موفقیت تکمیل شده است.

یک مانیتور از نوع Push ایجاد کنید. Uptime Kuma یک URL منحصر‌به‌فرد مانند زیر تولید می‌کند:

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

مقدار Heartbeat Interval را برابر با زمان اجرای job، به اضافه مقدار کمی زمان اضافی (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="

اگر job با خطا مواجه شود، set -e قبل از دستور curl متوقف می‌شود؛ اگر سرور خاموش باشد، اسکریپت اصلاً اجرا نمی‌شود. در هر دو حالت، ارسال heartbeat متوقف می‌شود و پس از گذشت بازه زمانی (interval-plus-retries)، Uptime Kuma وضعیت مانیتور را به down تغییر داده و به شما هشدار می‌دهد. با آن push token مانند یک رمز عبور برخورد کنید: هر کسی که آن را داشته باشد، می‌تواند وضعیت سلامت سیستم را جعل کند.

ساخت یک صفحه وضعیت عمومی (Public Status Page)

صفحه وضعیت، نمای مخصوص مشتریان است: این صفحه بدون نمایش داشبورد شما، نشان می‌دهد که کدام سرویس‌ها فعال هستند و تاریخچه اخیر آن‌ها چگونه بوده است. به مسیر Status Pages then New Status Page بروید، یک نام و یک slug (مسیر عمومی، مانند /status/main) انتخاب کنید، مانیتورهای مورد نظر را در گروه‌هایی مثل "Websites" و "APIs" قرار دهید، یک لوگو و یک توضیحات کوتاه اضافه کنید و سپس Save را بزنید. همچنین می‌توانید صفحه را به دامنه اختصاصی خود متصل کنید تا status.example.com مستقیماً آن را سرو کند.

دو نکته احتیاطی: فقط مانیتورهایی را اضافه کنید که مایل به عمومی کردن آن‌ها هستید، زیرا صفحه وضعیت نشان می‌دهد که یک سرویس وجود دارد و وضعیت فعال یا غیرفعال بودن آن را فاش می‌کند؛ و همچنین، داشبورد شما پشت سیستم ورود (login) باقی می‌ماند، در حالی که صفحه وضعیت به صورت عمدی عمومی است و نیازی به احراز هویت (auth) ندارد.

استفاده از یک Reverse Proxy با TLS و توجه به Websockets

برای یک نمونه عمومی، یک reverse proxy جلوی کانتینری که به loopback متصل است قرار دهید تا TLS و یک hostname فراهم شود. نکته‌ای که باعث بروز مشکل برای همه می‌شود: رابط کاربری Uptime Kuma یک اپلیکیشن زنده مبتنی بر Socket.IO است، بنابراین proxy باید اتصال WebSocket را upgrade کند. اگر این مورد را نادیده بگیرید، صفحه بارگذاری می‌شود اما هرگز متصل نمی‌شود؛ داشبورد در حالت "Connecting..." باقی می‌ماند، وضعیت heartbeat به‌روزرسانی نمی‌شود و کنسول مرورگر خطای WebSocket connection to 'wss://.../socket.io/...' failed را نشان می‌دهد.

nginx و certbot را نصب کنید، سپس vhost را برای پروکسی کردن به پورت loopback بنویسید. فعلاً آن را روی پورت 80 قرار دهید و اجازه دهید certbot بعداً TLS را اضافه کند؛ چالش‌ها، زمان‌بندی تمدید و حالت‌های شکست آن در 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 ذخیره کنید؛ دو خط مربوط به WebSocket مهم‌ترین بخش‌ها هستند:

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;
    }
}

سایت را فعال کنید، پیکربندی را تست کنید، سپس اجازه دهید certbot بلوک را برای گوش دادن روی پورت 443 بازنویسی کند، گواهینامه را اضافه کند و یک redirect از HTTP به HTTPS ایجاد کند:

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 از قطع شدن socketهای طولانی‌مدت توسط nginx جلوگیری می‌کند؛ certbot هر دو را در بلوک 443 که ایجاد می‌کند، کپی می‌کند. اگر از قبل چندین کانتینر را پشت یک proxy اجرا می‌کنید، routing them through Traefik with automatic TLS همین کار را با استفاده از container labels انجام می‌دهد و به صورت پیش‌فرض WebSocket upgrades را فوروارد می‌کند.

روی کل vhost از basic-auth استفاده نکنید، زیرا این کار باعث مسدود شدن صفحه وضعیت عمومی و endpoint /api/push می‌شود. از سیستم ورود داخلی Uptime Kuma استفاده کنید، اگر سرویس در معرض اینترنت است fail2ban watching for repeated failed logins را اضافه کنید، و اگر داشبورد نیازی به عمومی بودن ندارد، از proxy استفاده نکنید و از طریق VPN به آن دسترسی پیدا کنید.

مانیتورینگ انقضای گواهینامه (Certificate) به روش صحیح

یک مانیتور HTTP(s) می‌تواند قبل از انقضای گواهینامه TLS به شما هشدار دهد: گزینه Certificate Expiry Notification را فعال کنید تا Uptime Kuma در تعداد روزهای مشخص شده، هشدار ارسال کند. دو اشتباه باعث بروز خطا در خواندن اطلاعات می‌شود. مانیتورینگ را به جای IP، بر اساس hostname انجام دهید؛ در غیر این صورت، درخواستی که فاقد SNI باشد، گواهینامه پیش‌فرض سرور را دریافت می‌کند و شما با خطای Hostname/IP does not match certificate's altnames مواجه می‌شوید. همچنین، در مانیتوری که می‌خواهید هشدارهای انقضا را دریافت کنید، گزینه Ignore TLS/SSL Error را فعال نکنید: این گزینه برای میزبان‌های داخلی با گواهینامه self-signed (مانند unable to verify the first certificate و DEPTH_ZERO_SELF_SIGNED_CERT) است، اما باعث می‌شود Uptime Kuma بررسی گواهینامه، از جمله تاریخ انقضا را، کاملاً متوقف کند.

Backups: it is one directory

از آنجایی که همه چیز در /app/data قرار دارد، یک backup کپی از آن volume است که در زمان متوقف بودن container تهیه می‌شود تا فایل SQLite سازگار باشد:

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

ابتدا نام واقعی volume را با استفاده از docker volume ls | grep kuma تایید کنید، زیرا Compose نام پروژه را به ابتدای آن اضافه می‌کند. سپس فایل tarball را به خارج از سرور منتقل کنید؛ زیرا ذخیره کردن backup در همان VPS، تنها یک کپی است و نه یک backup واقعی. فرآیند بازیابی (Restore) برعکس است: stack را متوقف کنید، فایل را در یک volume خالی از نوع /app/data استخراج کنید و سپس آن را اجرا کنید.

Upgrades

ارتقا (Upgrades) شامل دریافت یک image جدید است:

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

کانتینر جدید در اولین اجرا، تمام database migrationها را اجرا می‌کند؛ وضعیت docker compose logs -f را بررسی کنید. حتماً قبل از pull کردن، از مرحله بالا backup تهیه کنید و در محدوده یک major tag باقی بمانید: انتقال از :1 به :2 یک migration یک‌طرفه است، بنابراین ابتدا backup تهیه کنید و release notes را بررسی کنید.

Failure modes, with the strings you will see

False "down" on a monitor pointed at localhost. The monitor goes red with timeout of 48000ms exceeded or connect ETIMEDOUT, yet the service answers from your laptop. If it targets the same host Uptime Kuma runs on, a CPU or memory spike starved the check, not the target. Move the monitor to a separate VPS and target the public hostname.

connect ECONNREFUSED 127.0.0.1:443 (or any port). Nothing was listening on that port: either the service is down, or you monitored localhost from inside the container, where 127.0.0.1 is the container, not your server. Monitor the public hostname, not loopback.

Invalid login: 535-5.7.8 Username and Password not accepted on an email test. The SMTP credentials are wrong, or the provider wants an app-specific password and got your account password. Generate an app password and paste that.

connect ETIMEDOUT or queryA ETIMEDOUT <host> on an email test. Wrong port, or the provider blocks outbound SMTP. Confirm 465 or 587 matches the Secure/STARTTLS setting, and test from the host with nc -vz smtp.example.com 587. Many providers block outbound 25 and some block submission ports until you ask.

self signed certificate or unable to verify the first certificate on an email test. Your SMTP server presents a certificate Node will not trust; fix the mail server's certificate rather than papering over it.

Dashboard stuck on "Connecting...", console shows WebSocket connection ... failed. The reverse proxy is not upgrading the WebSocket. Add the Upgrade and Connection "upgrade" headers on nginx, or use a proxy that forwards them by default such as Traefik or Caddy. The HTML loads because that is a normal HTTP GET; only the live socket needs the upgrade.

Cert-expiry monitor never warns, or warns wrongly. Either Ignore TLS/SSL Error is ticked, which disables cert checking, or the monitor targets an IP and reads the wrong certificate through missing SNI, showing Hostname/IP does not match certificate's altnames. Untick ignore, monitor by hostname.

SQLITE_BUSY or database disk image is malformed in the logs. The /app/data volume is on a filesystem without proper file locking, usually NFS; move it to a local Docker volume and restore from backup.

FAQ

کجا باید مانیتورینگ uptime خود را اجرا کنم؟

روی سروری متفاوت از سرورهایی که تحت نظارت هستند؛ ایده‌آل این است که از یک ارائه‌دهنده یا منطقه (region) دیگر استفاده کنید تا مانیتورینگ دقیقاً مانند کاربران شما، از طریق hostname و در اینترنت عمومی به آن‌ها متصل شود. اگر مانیتورینگ با هدف‌های مورد نظرتان در یک سرور مشترک باشد، قطعی که باعث از کار افتادن سرور می‌شود، مانیتور را هم از کار می‌اندازد؛ همچنین فشار زیاد روی host باعث می‌شود مانیتورینگ برای سرویس‌هایی که سالم هستند، وضعیت "down" گزارش دهد. استفاده از یک VPS کوچک و مجزا، هر دو مشکل را حل می‌کند.

چگونه هشدارها را در Telegram یا ایمیل دریافت کنم؟

کانال مورد نظر را در مسیر Settings then Notifications اضافه کنید و سپس آن را به هر مانیتور متصل کنید. برای Telegram، یک bot با استفاده از @BotFather بسازید و chat.id را از https://api.telegram.org/bot<token>/getUpdates بخوانید؛ برای ایمیل، اگر ارائه‌دهنده شما از تایید دو مرحله‌ای استفاده می‌کند، از 465 برای SSL یا از 587 برای STARTTLS به همراه یک app password استفاده کنید. قبل از اعتماد به سیستم، دکمه Test را فشار دهید و رسیدن پیام را تایید کنید.

آیا Uptime Kuma می‌تواند یک cron job یا اسکریپت backup را مانیتور کند؟

بله، این قابلیت مربوط به مانیتور از نوع Push است: Uptime Kuma یک URL به شما می‌دهد و شما در انتهای اسکریپت آن را curl می‌کنید تا فقط در صورت موفقیت اجرا شود. اگر کار با شکست مواجه شود یا سرور از دسترس خارج شود، heartbeat هرگز ارسال نمی‌شود و پس از پایان بازه زمانی (interval)، شما مطلع می‌شوید. این تنها راه قابل اعتماد برای اطمینان از اجرای یک کار زمان‌بندی شده است، زیرا یک بررسی خارجی نمی‌تواند جزئیات داخلی اسکریپت را ببیند.

Uptime Kuma در مقابل Zabbix، کدام را اجرا کنم؟

Uptime Kuma در عرض 10 دقیقه و با مصرف بسیار کم منابع، به سوالاتی مثل "آیا سرویس از بیرون در دسترس است و آیا هشدار ارسال کرد یا خیر" پاسخ می‌دهد و یک status page نیز ارائه می‌دهد. این ابزار متریک‌های عمیق مانند روند مصرف CPU، memory و disk یا آستانه‌های (thresholds) سراسری را جمع‌آوری نمی‌کند؛ برای این منظور، یک سرور مانیتورینگ کامل Zabbix ابزاری سنگین‌تر و مبتنی بر agent است و بسیاری از افراد هر دو را اجرا می‌کنند. هنوز در مورد انتخاب ابزار مردد هستید؟ مجموعه ما از آنچه باید در سال 2026 self-host کنید دید کلی به شما می‌دهد.

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