SSD Nodes Learn Hosting plans →
Rehberler Matt ConnorYazan Matt Connor · Güncellendi 2026-08-27

Uptime Kuma Docker Kurulumu ve İzleme Rehberi

Uptime Kuma ile web sitelerinizi ve portlarınızı Docker uzerinde izleyin. Sunucu kesintilerini e-posta veya Telegram ile bildiren bu aracın kurulumunu ve yapılandırmasını ogrenin.

Ne inşa ediyorsunuz

Diğer sunucularınızı ve web sitelerinizi dışarıdan izleyen ve biri yanıt vermeyi kestiği anda size e-posta, Telegram, Discord veya bir webhook aracılığıyla bildiren tek bir küçük container. Uptime Kuma, SQLite dosyası tarafından desteklenen tek bir Node sürecidir; bu nedenle 256-512 MB RAM ile rahatça çalışır ve size canlı bir kontrol paneli, geçmiş grafikler ve herkese açık bir durum sayfası sunar. Kurulum on satırlık bir Compose dosyasıdır; asıl önemli olan kısım onu nerede çalıştırdığınız ve uyarılarınızın bir test sırasında tetiklenip tetiklenmediğidir. Çünkü size ulaşabileceğini kanıtlamadığınız bir izleyici, hiç izleyicinizin olmamasından daha kötüdür: hiçbir şeyi izlemezken sizi güvende hissettirir.

İzleme aracını kesintinin ulaşamayacağı bir yerde çalıştırın

Bu karar tüm sistemin başarısını belirlediği için ilk sırada yer alır. Uptime Kuma uygulamasını, izlediği sunucularla aynı makinede çalıştırmayın. Eğer izleme aracı, izlediği sunucunun üzerinde barındırılıyorsa, sunucunun çökmesi veya belleğinin tükenmesi gibi kritik bir durumda izleme aracı da devre dışı kalır ve hiçbir uyarı alamazsınız; ölü bir izleme aracından gelen sessizlik, "her şey yolunda" mesajıyla aynı şekilde algılanır. Sunucu ayaktayken bile daha sinsi bir tuzak mevcuttur: localhost adresine yönlendirilmiş bir izleme aracı, CPU kaynaklarını iş yüküyle paylaşır. Bu durum, bir yük artışı sırasında izleme aracının zaman aşımına uğramasına ve hedefi down (kapalı) olarak işaretlemesine, yani gerçek kullanıcılar hizmet alabiliyorken hatalı bir alarm oluşmasına neden olur.

Bu nedenle Uptime Kuma uygulamasını, izlediği sunucudan farklı bir VPS üzerinde çalıştırın. İdeal olan, farklı bir sağlayıcı veya bölge kullanmak ve hizmetlerinize kullanıcılarınızın yaptığı gibi, yani genel internet üzerinden ve ana bilgisayar adı (hostname) ile erişmektir. Ucuz bir bulut sunucusu yeterlidir; küçük bir izleme VPS'i tüm sunucularınızı izleyebilir. Bu ayrım, özellikle barındırdığınız ağır uygulamalar için kritiktir. Örneğin PhotoPrism veya Immich fotoğraf kütüphanesi gibi uygulamalar, yeni bir içe aktarma işlemini indekslerken saatlerce CPU kullanımını %100'e çıkarabilir; aynı donanımı paylaşan bir izleme aracı, sadece meşgul olan bir servis için hatalı şekilde "kapalı" uyarısı verecektir. Kuma'nın kendisinin çökme ihtimaline karşı, başka bir yerden cron ile bir push heartbeat (canlılık sinyali) ekleyin.

Ön gereksinimler ve boyutlandırma

  • Docker Engine ve Compose v2 eklentisi kurulu, güncel bir Ubuntu 24.04 VPS. Kurulum, geride kalan docker.io dağıtım paketleri yerine doğrudan Docker'ın kendi apt deposundan yapılmalıdır.
  • 256 MB RAM birkaç izleme servisi için yeterlidir; 512 MB ile 1 GB arası bellek, onlarca servis ve reverse proxy için rahat bir çalışma ortamı sağlar. İşlemci kullanımı kontroller arasında neredeyse boştadır.
  • TLS ve herkese açık bir durum sayfası isteniyorsa, bir alan adı ve DNS A kaydı (örneğin VPS'i işaret eden status.example.com) gereklidir. Özel bir kurulumda DNS atlanabilir; VPN veya SSH tüneli kullanılabilir.
  • Uyarıların gönderileceği yerlere yönelik giden ağ trafiği: E-posta sağlayıcınız için SMTP veya Telegram ve Discord için HTTPS erişimi.

Compose dosyası

Bunu /srv/uptime-kuma/compose.yaml içine yerleştirin.

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:

Servisi ayağa kaldırın ve ilk başlatma sürecini izleyin:

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

Doğru bir başlatma işleminde Listening on 3001 logu görülür ve süreç sessizleşir. Bu dosyadaki üç unsur bilinçli olarak seçilmiştir.

3001:3001 değil, 127.0.0.1:3001:3001. Docker, portları ufw paketi görmeden önce değerlendirilen DNAT kuralları ile yayınlar; bu nedenle çıplak bir 3001:3001, güvenlik duvarınız ne olursa olsun panelinizi herkese açık internete çıkarır. Loopback adresine bağlamak, yalnızca reverse proxy'nin dışa açık olduğu özel bir yapı sağlar; özel bir instance, proxy'yi atlayarak kendi barındırdığınız bir WireGuard VPN üzerinden 3001 adresine erişebilir.

/app/data konumunda adlandırılmış bir volume. Uptime Kuma'nın hatırladığı her şey; SQLite veritabanı, monitörleriniz, bildirim ayarlarınız ve durum sayfası logolarınız burada tutulur. Bu veriyi kaybederseniz boş bir yönetici ekranıyla karşılaşırsınız; yedeklemeniz gereken tek şey budur.

İmaj, ana bir sürüme sabitlenmiştir, :2. Bu, mevcut kararlı sürümdür; kopyalamadan önce Docker Hub üzerinden en yeni ana sürümü kontrol edin ve projenin kullanımdan kaldırdığı latest gibi değişken etiketleri asla takip etmeyin. Bu imajdaki bir ana sürüm yükseltmesi, tek yönlü bir veritabanı geçişidir; bunu rutin bir güncelleme sırasında kazara değil, bilinçli olarak tetiklemek istersiniz.

Bir uyarı: /app/data, POSIX dosya kilitleme özelliğine sahip bir dosya sisteminde bulunmalıdır. Yerel bir Docker volume uygundur; NFS üzerinde SQLite veritabanı bozulur ve SQLITE_BUSY ile database disk image is malformed hatalarını alırsınız, bu nedenle ağ paylaşımı asla kullanmayın.

İlk çalıştırma: yönetici hesabını oluşturma

Proxy'niz üzerinden https://status.example.com adresine gidin veya bir SSH tüneli kullanın: ssh -L 3001:127.0.0.1:3001 user@your-vps komutunu çalıştırın ve http://localhost:3001 adresini açın. İlk sayfa, yönetici kullanıcı adı ve parolası için bir kurulum formudur; varsayılan bir giriş bilgisi bulunmamaktadır. Güçlü bir parola seçin: bu panel, izlediğiniz her şeyin dahili adreslerini ve belirteçlerini (token) görebilir. Parolayı daha sonra mı unuttunuz? Tarayıcıdan değil, ana makine üzerinden sıfırlayın:

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

Önce bildirim kanallarınızı ekleyin ve test edin

Monitörleri oluşturmadan önce uyarıları yapılandırın; böylece her birini oluştururken bir kanal atayabilirsiniz. Settings ardından Notifications ve Setup Notification yolunu izleyin. Her kanalın Test butonunu kullanarak mesajın ulaştığını doğrulayın; çünkü test edilmemiş bir bildirim, kurulumun sessizce başarısız olmasının en yaygın ikinci nedenidir.

Email (SMTP). Host, port, şifreleme, kullanıcı adı, parola, From (Gönderen) ve To (Alıcı) bilgilerini doldurun. Çalışan iki kombinasyon, "Secure" ayarı TLS/SSL olarak seçili 465 veya STARTTLS ile 587 şeklindedir. Gmail ve iki faktörlü kimlik doğrulaması kullanan çoğu sağlayıcı için bir app password (uygulama şifresi) oluşturmanız gerekir; normal hesap parolası Error: Invalid login: 535-5.7.8 Username and Password not accepted hatasına neden olur.

Telegram. @BotFather adresine mesaj gönderin, /newbot komutunu iletin ve bot token değerini kopyalayın. Chat ID için yeni bota bir kez mesaj atın, https://api.telegram.org/bot<token>/getUpdates adresini açın ve JSON içindeki chat.id değerini okuyun. Daha önce mesaj atmadığınız bir botun getUpdates değeri boştur ve mesajın gönderilebileceği bir yer yoktur.

Discord. Kanal içinde Edit Channel ardından Integrations, Webhooks ve New Webhook yolunu izleyin, URL'yi kopyalayın ve Discord bildirimi olarak yapıştırın.

Generic webhook. Slack gelen webhook'ları, özel uç noktalar veya ev otomasyonu kancaları gibi diğer tüm durumlar için Webhook türü, sağladığınız URL'ye bir JSON payload'u POST eder. Dahili Apprise entegrasyonu, listedeki diğer doksan civarındaki servisin çoğunu kapsar. Bir kesinti ile telefonunuz arasında üçüncü bir tarafın bulunmasını istemiyorsanız, yerleşik ntfy türünü seçin ve bunu kendi çalıştırdığınız bir ntfy sunucusuna yönlendirin; bu, uçtan uca kontrol ettiğiniz bir kanal üzerinden cihazınıza bildirim gönderir.

İzleyicileri tek seferde bir tür olacak şekilde ekleyin

Add New Monitor düğmesine tıklayın, bir tür seçin ve Friendly Name (Dost İsim), Check Interval (Kontrol Aralığı; 60 saniye makul bir süredir), Retries (Yeniden Deneme; "down" durumuna geçmeden önceki ardışık başarısızlık sayısı; tek bir paket kaybının uyarı tetiklememesi için 2 veya 3) ve tetiklenecek bildirimleri ayarlayın. Kullanacağınız türler şunlardır:

  • HTTP(s). Tam bir URL. "Up" durumu, kabul edilen bir durum kodunu ifade eder (varsayılan olarak 200-299; 301 veya 401 sizin için normal bir durumsa Accepted Status Codes kısmından bu aralığı genişletin). Web siteleri ve API'ler için temel aracınızdır.
  • HTTP(s) - Keyword. Aynı istek türüdür ancak "up" durumu için yanıt gövdesinde belirli bir dizenin bulunması (veya Invert seçeneği işaretliyse bulunmaması) gerekir. Bu, sitenin "Error establishing a database connection" (Veritabanı bağlantısı kurulamadı) hatası verirken 200 OK döndürmesi gibi durumları yakalar; düz bir HTTP kontrolü bunu sağlıklı olarak algılayabilir. Ayrıca, ayrı bir arka uçla konuşan tarayıcı ön yüzleri için de doğru kontrol yöntemidir; örneğin Jellyfin üzerinde çalışan bir Halcyon video-store arayüzü, arka plandaki medya sunucusuna ulaşılamadığı halde sayfa iskeletini 200 koduyla başarıyla döndürebilir.
  • TCP Port. HTTP olmayan servisler için bir ana bilgisayar ve porta yapılan yalın TCP bağlantısıdır: 22 numaralı portta SSH, 5432 numaralı portta Postgres, 25 numaralı portta bir SMTP sunucusu veya bir oyun sunucusu gibi.
  • Ping. ICMP echo: düşük maliyetli erişilebilirlik ve gecikme ölçümü. Ancak birçok ağ ve bulut güvenlik duvarı ICMP trafiğini engeller; bu nedenle kırmızı bir ping izleyicisi "sunucu kapalı" anlamına gelebileceği gibi "sağlayıcı ping'i engelliyor" anlamına da gelebilir; durumu bir TCP izleyicisi ile doğrulayın.
  • DNS. Belirlediğiniz bir çözümleyici üzerinden bir kaydı (A, AAAA, MX, TXT vb.) sorgular ve yanıtı doğrulayabilir; böylece kayıt kuruluşu veya DNS kesintilerini erkenden tespit edebilirsiniz.
  • Push. Bir sonraki bölümde ele alınacak olan, içeriden dışarıya doğru çalışan izleyici türüdür.

Bir cron işini push (heartbeat) monitörü ile izleme

Yukarıdaki tüm monitörler, hizmetinize dışarıdan erişir. Bir push monitörü ise tam tersi şekilde çalışır: Uptime Kuma bekler ve sizin işiniz ona "çalıştım" bilgisini gönderir. Bir yedekleme veya cron işini izlemenin tek güvenilir yolu budur: bir HTTP denetimi URL'nin yanıt verdiğini bilir, ancak işin başarıyla tamamlandığını yalnızca işin kendisi bilir.

Push türünde bir monitör oluşturun. Uptime Kuma, aşağıdakine benzer benzersiz bir URL oluşturur:

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

Heartbeat Interval (Sinyal Aralığı) değerini, işin çalışma sıklığına biraz pay ekleyerek ayarlayın. Ardından, yalnızca başarı durumunda tetiklenmesi için betiğin sonuna şu satırı ekleyin:

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

İş başarısız olursa, set -e curl komutundan önce durur; sunucu kapalıysa betik zaten hiç çalışmaz. Her iki durumda da sinyal durur ve interval-plus-retries (aralık artı yeniden deneme) süresi dolduğunda, Uptime Kuma monitörü down (kapalı) durumuna getirir ve sizi uyarır. Bu push token değerini bir sır olarak saklayın: ona sahip olan herkes sahte bir "sağlıklı" sinyali gönderebilir.

Halka açık bir durum sayfası oluşturma

Durum sayfası, müşterilerin gördüğü arayüzdür; panelinizi ifşa etmeden hangi servislerin çalıştığını ve geçmiş durumlarını gösterir. Status Pages menüsünden New Status Page seçeneğine gidin, bir isim ve slug (örneğin /status/main gibi halka açık yol) belirleyin, izlemek istediğiniz monitörleri "Websites" ve "APIs" gibi gruplara sürükleyin, bir logo ve kısa açıklama ekleyip kaydedin. Sayfayı kendi alan adınıza bağlayarak status.example.com üzerinden doğrudan yayınlanmasını da sağlayabilirsiniz.

İki hususa dikkat edilmelidir: Yalnızca halka açık olmasında sakınca görmediğiniz monitörleri ekleyin, çünkü durum sayfası bir servisin varlığını ve çalışıp çalışmadığını ifşa eder. Yönetim paneli giriş bilgilerinizle korunmaya devam ederken, durum sayfası kasıtlı olarak herkese açıktır ve kimlik doğrulama gerektirmez.

TLS destekli bir reverse proxy arkasına alın ve WebSocket bağlantılarına dikkat edin

Halka açık bir kurulum için, loopback adresine bağlı container'ın önüne TLS ve bir ana bilgisayar adı (hostname) için bir reverse proxy yerleştirin. Herkesin takıldığı detay şudur: Uptime Kuma arayüzü canlı bir Socket.IO uygulamasıdır, bu nedenle proxy'nin WebSocket bağlantısını yükseltmesi (upgrade) gerekir. Bu atlanırsa sayfa yüklenir ancak bağlantı kurulamaz; panel "Connecting..." durumunda kalır, canlı kalp atışları güncellenmez ve tarayıcı konsolunda WebSocket connection to 'wss://.../socket.io/...' failed hatası görünür.

nginx ve certbot paketlerini kurun, ardından loopback portuna yönlendirme yapan vhost dosyasını oluşturun. Şimdilik 80 numaralı port üzerinde çalıştırın ve TLS ekleme işlemini daha sonra certbot ile yapın; doğrulama süreci, yenileme zamanlayıcısı ve hata modları certbot ve nginx ile Let's Encrypt sertifikası oluşturma rehberinde ele alınmıştır.

sudo apt install -y nginx certbot python3-certbot-nginx

Bunu /etc/nginx/sites-available/status.example.com olarak kaydedin; kritik olan iki WebSocket satırıdır:

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

Siteyi etkinleştirin, yapılandırmayı test edin ve ardından certbot'un bloğu 443 portunu dinleyecek şekilde yeniden yazmasına, sertifikayı eklemesine ve HTTP'den HTTPS'e yönlendirme yapmasına izin verin:

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 ve Connection "upgrade" ikilisi tüm işleyişi belirler, proxy_read_timeout 3600s ise nginx'in uzun ömürlü soket bağlantısını kesmesini engeller; certbot her iki satırı da oluşturduğu 443 bloğuna kopyalar. Eğer halihazırda bir proxy arkasında birden fazla container çalıştırıyorsanız, Traefik ile otomatik TLS üzerinden yönlendirme yöntemi aynı işlemi container etiketleri ile yapar ve WebSocket yükseltmelerini varsayılan olarak iletir.

Tüm vhost için basic-auth uygulamayın, çünkü bu işlem halka açık durum sayfasını ve /api/push uç noktasını da kilitler. Uptime Kuma'nın kendi yerleşik giriş sistemini kullanın, internete açıksa başarısız giriş denemelerini izleyen fail2ban ekleyin ve eğer panelin halka açık olması gerekmiyorsa proxy kullanmak yerine bir VPN üzerinden erişim sağlayın.

Sertifika süresi takibi, doğru yöntemle

Bir HTTP(s) monitörü, TLS sertifikası süresi dolmadan önce sizi uyarabilir: Certificate Expiry Notification seçeneğini işaretlediğinizde, Uptime Kuma belirlenen gün sayısından önce bildirim gönderir. İki hata, yanlış okumaya neden olur. İzleme işlemini IP adresi ile değil, hostname ile yapın; aksi takdirde SNI içermeyen bir istek sunucunun varsayılan sertifikasını döndürür ve Hostname/IP does not match certificate's altnames hatası alırsınız. Ayrıca, süresi dolan sertifikalar için uyarı almak istediğiniz bir monitörde Ignore TLS/SSL Error seçeneğini işaretlemeyin: bu ayar, kendinden imzalı (self-signed) dahili sunucular içindir (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT); ancak bu seçenek, Uptime Kuma'nın sertifikayı denetlemesini tamamen durdurur ve süre takibi de devre dışı kalır.

Yedekleme: tek bir dizin

Her şey /app/data içinde barındığından, yedekleme işlemi container durdurulmuşken alınan bir volume kopyasıdır; bu sayede SQLite dosyası tutarlı kalır:

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

Compose, proje dizinini önek olarak eklediği için önce docker volume ls | grep kuma ile volume'un gerçek adını doğrulayın. Ardından tarball dosyasını sunucudan dışarı kopyalayın; aynı VPS üzerindeki bir yedek, yedek değil sadece bir kopyadır. Geri yükleme işlemi bunun tersidir: stack'i durdurun, içeriği boş bir /app/data volume'una çıkartın ve başlatın.

Yükseltmeler

Yükseltmeler, bir image çekme işleminden ibarettir:

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

Yeni container, ilk başlatma sırasında tüm veritabanı migrasyonlarını çalıştırır; docker compose logs -f dosyasını izleyin. Çekme işleminden önce yukarıda belirtilen yedeği alın ve ana sürüm etiketi sınırları içinde kalın: :1 sürümünden :2 sürümüne geçiş tek yönlü bir migrasyondur; bu nedenle önce yedek alın ve sürüm notlarını inceleyin.

Hata modları ve karşılaşacağınız dizeler

localhost adresine yönlendirilen monitörde hatalı "kapalı" durumu. Monitör timeout of 48000ms exceeded veya connect ETIMEDOUT hatasıyla kırmızıya döner, ancak servis dizüstü bilgisayarınızdan yanıt veriyordur. Eğer monitör, Uptime Kuma'nın çalıştığı aynı ana makineyi hedefliyorsa, bir CPU veya bellek artışı hedefi değil, kontrol işlemini kısıtlamıştır. Monitörü ayrı bir VPS'e taşıyın ve genel ana makine adını (public hostname) hedefleyin.

connect ECONNREFUSED 127.0.0.1:443 (veya herhangi bir port). O portta dinleme yapan bir servis yoktur: servis kapalı olabilir veya localhost adresini, sunucunuz değil container olan 127.0.0.1 içinden izliyor olabilirsiniz. Loopback yerine genel ana makine adını izleyin.

E-posta testinde Invalid login: 535-5.7.8 Username and Password not accepted. SMTP kimlik bilgileri yanlıştır veya sağlayıcı hesap parolanız yerine uygulamaya özel bir parola bekliyordur. Uygulamaya özel bir parola oluşturun ve bunu yapıştırın.

E-posta testinde connect ETIMEDOUT veya queryA ETIMEDOUT <host>. Yanlış port kullanılmıştır veya sağlayıcı giden SMTP trafiğini engelliyordur. 465 veya 587 değerlerinin Secure/STARTTLS ayarıyla eşleştiğini doğrulayın ve ana makine üzerinden nc -vz smtp.example.com 587 ile test edin. Birçok sağlayıcı giden 25 trafiğini engeller; bazıları ise siz talep edene kadar gönderim portlarını kapalı tutar.

E-posta testinde self signed certificate veya unable to verify the first certificate. SMTP sunucunuz, Node tarafından güvenilmeyen bir sertifika sunuyordur; sorunu geçici çözümlerle örtmek yerine posta sunucusunun sertifikasını düzeltin.

Dashboard "Connecting..." durumunda takılı kalıyor, konsol WebSocket connection ... failed hatası gösteriyor. Reverse proxy, WebSocket bağlantısını yükseltmiyordur (upgrade). Nginx üzerinde Upgrade ve Connection "upgrade" başlıklarını ekleyin veya Traefik ya da Caddy gibi bu başlıkları varsayılan olarak ileten bir proxy kullanın. HTML yüklenir çünkü bu normal bir HTTP GET isteğidir; yalnızca canlı soket bağlantısı yükseltme gerektirir.

Sertifika süresi monitörü uyarı vermiyor veya hatalı uyarı veriyor. Ya sertifika kontrolünü devre dışı bırakan Ignore TLS/SSL Error seçeneği işaretlidir ya da monitör bir IP adresini hedefliyordur ve SNI eksikliği nedeniyle Hostname/IP does not match certificate's altnames hatasıyla yanlış sertifikayı okuyordur. "Ignore" seçeneğinin işaretini kaldırın ve ana makine adı üzerinden izleme yapın.

Loglarda SQLITE_BUSY veya database disk image is malformed. /app/data birimi, düzgün dosya kilitleme desteği olmayan bir dosya sisteminde (genellikle NFS) bulunuyordur; birimi yerel bir Docker birimine taşıyın ve yedekten geri yükleyin.

FAQ

Uptime monitorumu nerede çalıştırmalıyım?

İzlediği sunuculardan farklı bir sunucuda, ideal olarak başka bir sağlayıcıda veya bölgede, kullanıcılarınızın yaptığı gibi genel internet üzerinden ana bilgisayar adı (hostname) ile erişerek çalıştırılmalıdır. Eğer monitör, hedefleriyle aynı sunucuyu paylaşıyorsa, sunucuyu devre dışı bırakan bir kesinti monitörü de devre dışı bırakır; ayrıca aşırı yüklenmiş bir ana bilgisayar, aslında düzgün çalışan servisler için "kapalı" uyarısı verebilir. Küçük, ayrı bir VPS her iki sorunu da önler.

Telegram veya e-posta üzerinden nasıl uyarı alabilirim?

Ayarlar (Settings) ardından Bildirimler (Notifications) kısmından kanalı ekleyin ve ardından her monitöre atayın. Telegram için @BotFather ile bir bot oluşturun ve https://api.telegram.org/bot<token>/getUpdates üzerinden chat.id değerini okuyun; e-posta için, sağlayıcınız iki faktörlü kimlik doğrulama kullanıyorsa SSL için 465 veya STARTTLS için 587 ayarlarını bir uygulama şifresiyle birlikte kullanın. Test düğmesine basın ve güvenilirliğinden emin olmadan önce mesajın ulaştığını doğrulayın.

Uptime Kuma bir cron job veya yedekleme betiğini izleyebilir mi?

Evet, bu Push monitörü ile mümkündür: Uptime Kuma size bir URL verir ve siz de bunu betiğin sonuna curl komutuyla eklersiniz; böylece sadece başarı durumunda tetiklenir. Eğer iş başarısız olursa veya sunucu kapalıysa sinyal (heartbeat) asla ulaşmaz ve süre dolduğunda uyarılırsınız. Harici bir kontrol betiğin içini göremeyeceği için, zamanlanmış bir işin gerçekten çalıştığını bilmenin tek güvenilir yolu budur.

Uptime Kuma mı yoksa Zabbix mi, hangisini çalıştırmalıyım?

Uptime Kuma, "dışarıdan bakıldığında çalışıyor mu ve beni uyardı mı" sorusuna, neredeyse hiç kaynak tüketmeden ve bir durum sayfası (status page) sunarak on dakika içinde yanıt verir. CPU, bellek ve disk eğilimleri veya filo genelindeki eşik değerleri gibi derin metrikleri toplamaz; bunun için tam teşekküllü bir Zabbix izleme sunucusu daha ağır, aracı tabanlı (agent-based) bir araçtır ve birçok kişi her ikisini de çalıştırır. Hâlâ ne çalıştıracağınıza karar veremediyseniz, 2026 yılında self-host edilecekler listemiz izleme araçlarını bağlamına oturtmaktadır.

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