Rehberler

Yazan Matt Connor 2026-07-15 · Güncellendi 2026-07-24

Uptime Kuma Docker ile Kurulum Rehberi

Q: Telegram veya e-posta ile nasıl uyarı alırım?

Kanalı Settings then Notifications menüsü altından ekleyin ve ardından her bir monitöre bağlayın. Telegram için @BotFather ile bir bot oluşturun ve https://api.telegram.org/bot /getUpdates üzerinden chat.id okuyun; e-posta için SSL için 465 veya sağlayıcınız iki faktörlü kimlik doğrulama kullanıyorsa STARTTLS için uygulama şifresi ile 587 kullanın. Mesaja güvenmeden önce Test butonuna basın ve mesajın ulaştığını onaylayın.

Q: Uptime Kuma bir cron job veya yedekleme script'ini izleyebilir mi?

Evet, bu Push monitörüdür: Uptime Kuma size bir URL sağlar ve script sonunda curl işlemi yapılır; böylece sadece başarı durumunda tetiklenir. İşlem başarısız olursa veya sunucu kapalıysa heartbeat ulaşmaz ve belirlenen aralık geçtikten sonra uyarı alırsınız. Harici bir kontrol mekanizması script içeriğini göremeyeceği için, zamanlanmış bir işin gerçekten çalışıp çalışmadığını bilmenin tek güvenilir yolu budur.

Uptime Kuma ile web sitelerini, portları ve DNS kayıtlarını Docker üzerinde izleyin. Telegram veya e-posta ile anlık bildirimler alarak sistem takibi yapın.

Ne inşa ediyorsunuz

Diğer sunucularınızı ve web sitelerinizi dışarıdan izleyen; bir yanıt alınamadığı anda size e-posta, Telegram, Discord veya bir webhook aracılığıyla bildirim gönderen tek bir küçük konteyner. Uptime Kuma, bir SQLite dosyası tarafından desteklenen tek bir Node sürecidir; bu nedenle 256-512 MB RAM ile rahatlıkla çalışır. Size canlı bir panel, geçmiş grafikleri ve halka açık bir durum sayfası sunar. Kurulum, on satırlık bir Compose dosyasıdır; asıl önemli olan nerede çalıştırdığınız ve uyarılarınızın bir test sırasında tetiklenip tetiklenmediğidir. Çünkü ulaşılabilir olduğu kanıtlanmamış bir izleyici, hiç olmamasından daha kötüdür: hiçbir şeyi izlemezken koruma altında olduğunuz hissini verir.

Monitörü kesintinin ulaşamayacağı bir yerde çalıştırın

Bu karar tüm sistemin başarısını belirler, bu nedenle ilk adım budur. Uptime Kuma'yı izlediği servislerle aynı sunucuda çalıştırmayın. Eğer monitör izlediği sunucunun kendisindeyse, sunucunun çökmesi veya belleğinin tükenmesi durumunda monitör de kapanır ve hiçbir uyarı alınamaz: ölü bir monitörden gelen sessizlik, "her şey yolunda" durumuyla aynı anlama gelir. Sunucu çalışırken bile daha sinsi bir tuzak mevcuttur: localhost için yapılandırılmış bir monitör, CPU kaynaklarını iş yüküyle paylaşır; bu nedenle yük artışı, monitörün kontrol işleminin zaman aşımına uğramasına ve hedef durumu down olarak işaretlemesine neden olur. Bu bir yanlış alarmdır, oysa gerçek kullanıcılar hizmet almaya devam eder.

Bu nedenle Uptime Kuma'yı, izlediği sunucudan farklı bir VPS üzerinde çalıştırın. İdeal olan, farklı bir sağlayıcı veya bölge kullanmaktır; böylece servislerinize kullanıcılarınız gibi, yani kamuya açık internet üzerinden hostname ile erişilir. Düşük maliyetli bir instance yeterlidir ve tek bir küçük izleme VPS'i tüm sunucularınızı izleyebilir. Kuma'nın kendisinin çöktüğünü tespit etmek için, başka bir yerden cron aracılığıyla bir push heartbeat ekleyin.

Ön Koşullar ve Boyutlandırma

Docker Engine ve Compose v2 eklentisi yüklü, yeni bir Ubuntu 24.04 VPS. Bu bileşenler, güncelliğini yitirmiş olan docker.io dağıtım paketi yerine Docker'ın kendi apt deposundan yüklenmelidir.
256 MB RAM ile sınırlı sayıda izleme yapılabilir; onlarca izleme ve reverse proxy için 512 MB ile 1 GB arası RAM önerilir. Kontroller arasında CPU kullanımı minimum düzeydedir.
TLS ve halka açık bir durum sayfası isteniyorsa bir alan adı ve DNS A kaydı (örneğin VPS'e yönlendirilmiş status.example.com) gereklidir. Özel bir kurulum için DNS yerine VPN veya SSH tüneli kullanılabilir.
Uyarıların gönderileceği ağa doğru giden bağlantı: e-posta sağlayıcınız için SMTP veya Telegram ve Discord için HTTPS.

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 başlatın ve ilk açılışı 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şlangıç Listening on 3001 günlüğü tutar ve işlem yapmayı durdurur. Bu dosyadaki üç unsur bilinçli olarak ayarlanmıştır.

3001:3001 değil, 127.0.0.1:3001:3001. Docker, portları ufw paketi görmeden önce DNAT kurallarıyla yayınlar. Bu nedenle, yalın bir 3001:3001 kullanımı, güvenlik duvarından bağımsız olarak dashboard'u internete açar. Loopback adresine bağlamak, sadece reverse proxy'nin dış dünyaya açık kalmasını sağlayarak sistemi özel tutar; özel bir örnek, proxy yerine kendi sunucunuzda barındırılan bir WireGuard VPN üzerinden 3001 adresine erişebilir.

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

İmaj, ana bir etikete (major tag), :2 değerine sabitlenmiştir. Bu mevcut kararlı sürümdür; kopyalamadan önce Docker Hub üzerinden en yeni ana sürümü kontrol edin. Projenin devre dışı bıraktığı latest gibi hareketli etiketleri asla kullanmayın. Bu imajdaki ana sürüm geçişleri, rutin bir pull işlemi sırasında tesadüfen değil, bilinçli olarak tetiklenmesi gereken tek yönlü bir veritabanı migrasyonudur.

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

İlk çalıştırma: admin hesabını oluşturun

https://status.example.com adresindeki proxy üzerinden veya bir SSH tüneli aracılığıyla instance'a erişin: 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 şifresi için bir kurulum formudur; varsayılan bir giriş bilgisi bulunmamaktadır. Güçlü bir şifre seçin: bu dashboard, izlenen tüm bileşenlerin dahili adreslerini ve tokenlarını görür. Şifre unutulursa: tarayıcı üzerinden değil, host üzerinden sıfırlayın:

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

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

Her bir izleyiciyi oluştururken bir kanalı bağlayabilmek için uyarıları izleyicileri eklemeden önce kurun. Settings > Notifications > Setup Notification yolunu izleyin. Mesajın ulaştığını onaylamak için her kanalın Test butonunu kullanın; çünkü test edilmemiş bir bildirim, kurulumun sessizce başarısız olmasının en yaygın ikinci nedenidir.

Email (SMTP). Host, port, encryption, username, password, From ve To alanlarını doldurun. Çalışan iki kombinasyon; "Secure" ayarı TLS/SSL olan 465 veya STARTTLS kullanan 587'dir. Gmail ve iki faktörlü kimlik doğrulama kullanan çoğu sağlayıcı için bir app password oluşturulmalıdır; normal hesap şifresi Error: Invalid login: 535-5.7.8 Username and Password not accepted hatası döndürür.

Telegram. @BotFather adresine /newbot mesajı gönderin ve bot token'ı kopyalayın. Chat ID için yeni bota bir kez mesaj gönderin, https://api.telegram.org/bot<token>/getUpdates adresini açın ve JSON içerisindeki chat.id değerini okuyun. Daha önce hiç mesaj gönderilmemiş bir botun getUpdates değeri boştur ve mesaj gönderilemez.

Discord. İlgili kanalda Edit Channel > Integrations > Webhooks > New Webhook yolunu izleyin, URL'yi kopyalayın ve bunu bir Discord bildirimi olarak yapıştırın.

Generic webhook. Slack incoming webhook, özel bir uç nokta veya ev otomasyonu kancası gibi diğer tüm durumlar için geçerlidir. Webhook tipi, sağladığınız bir URL'ye JSON payload gönderir. Dahil edilen Apprise entegrasyonu, listedeki doksan civarındaki diğer hizmetlerin çoğunu kapsar.

İzleyicileri tek tek ekleyin

Add New Monitor butonuna tıklayın, bir tip seçin ve Friendly Name, Check Interval (60 saniye uygundur), Retries (durumun "down" sayılması için gereken ardışık hata sayısı; tek bir paket kaybının uyarı vermemesi için 2 veya 3 seçilmelidir) ve tetiklenecek bildirimleri ayarlayın. Kullanılacak tipler şunlardır:

HTTP(s). Tam bir URL. "Up" durumu, kabul edilen bir durum kodu (varsayılan olarak 200-299; eğer 301 veya 401 sizin için normalse Accepted Status Codes altından genişletilebilir) anlamına gelir. Web siteleri ve API'ler için temel araçtır.
HTTP(s) - Keyword. Aynı istek, ancak "up" durumu için gövdede belirli bir dizinin bulunması veya Invert seçeneğinin seçilmemiş olması gerekir. Bu yöntem, sitenin "Error establishing a database connection" hatası döndürürken 200 OK kodu vermesini yakalar; düz bir HTTP kontrolü bu durumu sağlıklı olarak raporlar.
TCP Port. HTTP olmayan servislar için bir ana makine ve porta yapılan doğrudan TCP bağlantısıdır: 22 portunda SSH, 5432 portunda Postgres, 25 portunda bir SMTP sunucusu veya bir oyun sunucusu.
Ping. ICMP echo: düşük maliyetli erişilebilirlik ve gecikme kontrolüdür. Ancak birçok ağ ve bulut güvenlik duvarı ICMP paketlerini düşürür; bu nedenle kırmızı bir ping izleyicisi "ana makine kapalı" veya "sağlayıcı ping paketlerini engelliyor" anlamına gelebilir; durumu bir TCP izleyicisi ile doğrulayın.
DNS. Belirlediğiniz bir çözücüye karşı bir kaydı (A, AAAA, MX, TXT vb.) çözer ve yanıtı doğrular; kayıt operatörü veya DNS kesintilerini erken aşamada yakalar.
Push. Bir sonraki bölümde ele alınan, içeriden dışarıya izleme yöntemidir.

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

Yukarıdaki tüm monitörler, dışarıdan servisinize erişir. Push monitör ters yönde çalışır: Uptime Kuma bekler ve işiniz çalıştığını bildirmek için onu çağırır. Bir yedekleme veya cron işlemini izlemenin tek güvenilir yolu budur: Bir HTTP kontrolü bir URL'nin yanıt verdiğini bilir, ancak işlemin tamamlandığını yalnızca işin kendisi bilir.

Push tipinde bir monitör oluşturun. Uptime Kuma şu şekilde benzersiz bir URL oluşturur:

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

Heartbeat Interval değerini, işin çalışma sıklığına biraz pay ekleyerek ayarlayın. Ardından, komutun yalnızca başarı durumunda çalışması 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="

İşlem başarısız olursa, set -e curl komutundan önce durur; sistem kapalıysa işlem zaten hiç çalışmaz. Her iki durumda da heartbeat durur ve belirlenen aralık ile yeniden deneme süresi dolduğunda, Uptime Kuma monitörü down durumuna getirir ve sizi uyarır. Bu push token değerini gizli bir bilgi olarak kabul edin: Bu token'a sahip olan herkes başarılı bir sinyal gönderebilir.

Bir genel durum sayfası oluşturun

Durum sayfası, kontrol panelini açığa çıkarmadan hangi servislerin çalıştığını ve geçmiş verilerini gösteren, müşteriye yönelik bir görünümdür. Status Pages kısmına gidip New Status Page seçeneğine tıklayın. Bir isim ve bir slug (/status/main gibi genel yol) belirleyin. İstediğiniz monitörleri "Websites" veya "APIs" gibi gruplara sürükleyin. Bir logo ve kısa bir açıklama ekleyip Save butonuna basın. Sayfayı kendi alan adınıza bağlayabilir, böylece status.example.com üzerinden doğrudan sunulmasını sağlayabilirsiniz.

İki önemli husus: bir durum sayfası bir servisin varlığını ve çalışma durumunu gösterdiğinden, yalnızca halka açılmasında sakınca olmayan monitörleri ekleyin; kontrol paneli giriş bilgilerinizin arkasında kalırken, durum sayfası kasıtlı olarak halka açıktır ve kimlik doğrulaması gerektirmez.

TLS ile bir reverse proxy arkasına yerleştirin ve websockets yapılandırmasına dikkat edin

Genel bir sunucu için, TLS ve bir hostname sağlamak amacıyla loopback-bound konteynerin önüne bir reverse proxy yerleştirin. Herkesin hata yaptığı detay şudur: Uptime Kuma'nın arayüzü canlı bir Socket.IO uygulamasıdır, bu nedenle proxy WebSocket bağlantısını upgrade etmelidir. Bu adım atlanırsa sayfa yüklenir ancak bağlantı kurulamaz; dashboard "Connecting..." durumunda kalır, canlı heartbeat verileri güncellenmez ve tarayıcı konsolunda WebSocket connection to 'wss://.../socket.io/...' failed hatası görünür.

nginx ve certbot kurulumunu yapın, ardından loopback portuna proxy yönlendirmesi yapan vhost dosyasını yazın. Şimdilik port 80 üzerinde çalıştırın ve TLS ekleme işlemini sonradan certbot ile gerçekleştirin; zorluklar, yenileme zamanlayıcısı ve hata durumları issuing Let's Encrypt certificates with certbot and nginx içeriğinde ele alınmaktadır.

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

Bu içeriği /etc/nginx/sites-available/status.example.com olarak kaydedin; önemli olan iki WebSocket satırı şunlardı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, konfigürasyonu test edin, ardından certbot'un 443 portunu dinleyecek şekilde bloğu yeniden yazmasına izin verin, sertifikayı ekleyin ve HTTP-to-HTTPS yönlendirmesini dahil edin:

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" çifti kritik öneme sahiptir; proxy_read_timeout 3600s ise nginx'in uzun süreli soketi kapatmasını engeller; certbot her ikisini de oluşturduğu 443 bloğuna kopyalar. Eğer tek bir proxy arkasında halihazırda birden fazla konteyner çalıştırıyorsanız, routing them through Traefik with automatic TLS yöntemi, konteyner etiketlerini kullanarak aynı işlemi yapar ve WebSocket upgrade işlemlerini varsayılan olarak iletir.

Tüm vhost için basic-auth kullanmayın, çünkü bu durum genel durum sayfasını ve /api/push uç noktasını da erişime kapatır. Uptime Kuma'nın yerleşik giriş sistemini kullanın, internete açıksa fail2ban watching for repeated failed logins yapılandırmasını ekleyin ve dashboard'un genel erişime ihtiyacı yoksa proxy kullanımını bırakıp VPN üzerinden erişin.

Doğru sertifika süresi izleme

Bir HTTP(s) izleyicisi, bir TLS sertifikasının süresi dolmadan önce uyarı verebilir: Certificate Expiry Notification seçeneği işaretlendiğinde, Uptime Kuma belirlenen gün sayısı kala uyarı gönderir. Yanlış yapılandırma hataları hatalı sonuçlara yol açar. İzleme işlemi IP yerine hostname üzerinden yapılmalıdır; aksi takdirde SNI içermeyen bir istek sunucunun varsayılan sertifikasını alır ve Hostname/IP does not match certificate's altnames hatası alınır. Ayrıca, son kullanma tarihi uyarısı almak istediğiniz bir izleyicide Ignore TLS/SSL Error seçeneğini işaretlemeyin: bu seçenek self-signed iç sunucular (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT) içindir, ancak Uptime Kuma'nın sertifika ve son kullanma tarihi kontrollerini tamamen durdurur.

Yedeklemeler: tek bir dizindir

Her şey /app/data içerisinde bulunduğu için, yedekleme işlemi konteyner durdurulmuşken alınan bir hacim 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, hacim isminin başına proje dizini adını eklediği için önce docker volume ls | grep kuma ile hacmin gerçek adını doğrulayın. Ardından tarball dosyasını sunucunun dışına kopyalayın; çünkü aynı VPS üzerindeki yedekleme bir kopya halidir, gerçek bir yedekleme değildir. Geri yükleme işlemi tersi yöndedir: stack'i durdurun, boş bir /app/data hacmine çıkartın ve stack'i başlatın.

Güncellemeler

Güncellemeler bir image pull işlemidir:

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

Yeni container ilk başlatıldığında tüm database migration işlemlerini gerçekleştirir; docker compose logs -f loglarını takip edin. Image çekilmeden önce yukarıdaki yedeği alın ve major tag sınırları içinde kalın: :1 sürümünden :2 sürümüne geçiş tek yönlü bir migration işlemidir; bu nedenle önce yedek alın ve release notes içeriğini kontrol edin.

Hata modları ve göreceğiniz dizinler

localhost'a yönlendirilmiş bir monitörde hatalı "down" durumu. Monitör timeout of 48000ms exceeded veya connect ETIMEDOUT ile kırmızıya döner, ancak servis dizüstü bilgisayarınızdan yanıt verir. Eğer monitör Uptime Kuma'nın çalıştığı aynı ana bilgisayarı hedefliyorsa, kontrolü hedef değil, CPU veya bellek kullanımı engellemiştir. Monitörü ayrı bir VPS'e taşıyın ve genel hostname'i hedefleyin.

connect ECONNREFUSED 127.0.0.1:443 (veya herhangi bir port). O portta dinleme yapan bir servis yok: ya servis kapalıdır ya da 127.0.0.1'nin sunucunuz değil, konteyner olduğu konteyner içinden localhost'i izliyorsunuz. Loopback yerine genel hostname'i 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ı uygulama özel şifresi beklerken hesap şifrenizi kullanıyorsunuz. Bir uygulama şifresi oluşturun ve onu yapıştırın.

E-posta testinde connect ETIMEDOUT veya queryA ETIMEDOUT <host>. Yanlış port veya sağlayıcı giden SMTP trafiğini engelliyor. 465 veya 587 ayarının Secure/STARTTLS ayarıyla eşleştiğini onaylayın ve nc -vz smtp.example.com 587 ile ana makineden test edin. Birçok sağlayıcı giden 25 trafiğini engeller ve bazıları siz talep edene kadar gönderim portlarını engeller.

E-posta testinde self signed certificate veya unable to verify the first certificate. SMTP sunucunuz Node'un güvenmeyeceği bir sertifika sunuyor; sorunu geçiştirmek yerine posta sunucusunun sertifikasını düzeltin.

Dashboard "Connecting..." durumunda takılı kalıyor, konsolda WebSocket connection ... failed görünüyor. Reverse proxy, WebSocket yükseltmesini (upgrade) yapmıyor. nginx üzerinde Upgrade ve Connection "upgrade" başlıklarını ekleyin veya Traefik veya Caddy gibi bunları varsayılan olarak ileten bir proxy kullanın. HTML yüklenir çünkü bu normal bir HTTP GET isteğidir; sadece canlı soket yükseltme gerektirir.

Sertifika süresi dolan monitör asla uyarı vermiyor veya hatalı uyarı veriyor. Ya sertifika kontrolünü devre dışı bırakan Ignore TLS/SSL Error seçeneği işaretli ya da monitör bir IP'yi hedefliyor ve eksik SNI nedeniyle yanlış sertifikayı okuyarak Hostname/IP does not match certificate's altnames hatası veriyor. İşareti kaldırın ve hostname üzerinden izleme yapın.

Loglarda SQLITE_BUSY veya database disk image is malformed. /app/data dizini, genellikle NFS olan ve uygun dosya kilitleme özelliğine sahip olmayan bir dosya sistemi üzerindedir; bunu yerel bir Docker dizinine taşıyın ve yedekten geri yükleyin.

FAQ

Uptime monitor nerede çalıştırılmalıdır?

İzlenen sunuculardan farklı bir sunucuda, ideal olarak farklı bir sağlayıcıda veya bölgede çalıştırılmalıdır. Sunuculara, kullanıcılar gibi genel internet üzerinden hostname ile erişilmelidir. Eğer monitor ile hedefler aynı sunucuda bulunursa, sunucunun çökmesi monitorün de çökmesine neden olur. Ayrıca aşırı yüklenmiş bir host, sorunsuz çalışan servisler için hatalı "down" uyarısı verebilir. Küçük ve ayrı bir VPS her iki sorunu da önler.

Telegram veya e-posta ile nasıl uyarı alırım?

Kanalı Settings then Notifications menüsü altından ekleyin ve ardından her bir monitöre bağlayın. Telegram için @BotFather ile bir bot oluşturun ve https://api.telegram.org/bot<token>/getUpdates üzerinden chat.id okuyun; e-posta için SSL için 465 veya sağlayıcınız iki faktörlü kimlik doğrulama kullanıyorsa STARTTLS için uygulama şifresi ile 587 kullanın. Mesaja güvenmeden önce Test butonuna basın ve mesajın ulaştığını onaylayın.

Uptime Kuma bir cron job veya yedekleme script'ini izleyebilir mi?

Evet, bu Push monitörüdür: Uptime Kuma size bir URL sağlar ve script sonunda curl işlemi yapılır; böylece sadece başarı durumunda tetiklenir. İşlem başarısız olursa veya sunucu kapalıysa heartbeat ulaşmaz ve belirlenen aralık geçtikten sonra uyarı alırsınız. Harici bir kontrol mekanizması script içeriğini göremeyeceği için, zamanlanmış bir işin gerçekten çalışıp çalışmadığını bilmenin tek güvenilir yolu budur.

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

Uptime Kuma, neredeyse hiç kaynak tüketmeden ve bir durum sayfası sunarak, on dakika içinde "dışarıdan bakıldığında servis ayakta mı ve bana uyarı gönderdi mi" sorusuna yanıt verir. CPU, bellek ve disk trendleri gibi derin metrikleri veya geniş ölçekli eşik değerlerini toplamaz; bunun için tam kapsamlı bir Zabbix izleme sunucusu daha ağır ve agent tabanlı bir araçtır; birçok kullanıcı her ikisini de kullanır. Hala ne çalıştıracağınıza karar veremediniz mi? 2026 yılında self-host edilebilecekler derlememiz izleme sistemlerini bağlam içinde sunar.

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