Uptime Kuma self-hosted na VPS

Uptime Kuma é o monitor de disponibilidade open-source mais popular, interface bonita, alertas em mais de 90 canais (Telegram, Slack, Email, WhatsApp) e status pages públicas profissionais. Self-hosteado na VPS, você monitora todos os seus serviços sem pagar por planos de monitoramento externo.

Instalar Uptime Kuma com Docker

Instalação simples e rápida com Docker:

yaml
# docker-compose.yml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    restart: always
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime_kuma_data:/app/data
    environment:
      - UPTIME_KUMA_PORT=3001

volumes:
  uptime_kuma_data:

# Subir:
docker compose up -d

# Nginx como proxy reverso:
# /etc/nginx/conf.d/uptime-kuma.conf
server {
    listen 443 ssl http2;
    server_name status.seudominio.com.br;

    ssl_certificate     /etc/letsencrypt/live/status.seudominio.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/status.seudominio.com.br/privkey.pem;

    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-Proto $scheme;
    }
}

Configurar monitores e alertas

Adicionar monitores via interface web e configurar alertas no Telegram:

bash
# Após acessar https://status.seudominio.com.br:
# 1. Criar conta admin
# 2. Add New Monitor

# Tipos de monitor disponíveis:
# - HTTP(s): verificar URL, código de status e conteúdo
# - TCP Port: verificar se porta está aberta
# - Ping: verificar conectividade ICMP
# - DNS: verificar resolução de nome
# - Docker container: verificar se container está rodando
# - Push: o serviço envia heartbeat ao Kuma (para jobs cron)

# Configurar alerta no Telegram:
# Settings → Notifications → Add Notification → Telegram
# - Bot Token: criar bot com @BotFather no Telegram
# - Chat ID: seu ID ou ID do grupo
# - Test: enviar mensagem de teste

# Configurar monitor de push para cron jobs:
# Add Monitor → Push
# Kuma gera URL: https://status.seudominio.com.br/api/push/CODIGO?status=up&msg=OK
# Adicionar ao final do cron job:
# 0 3 * * * /opt/scripts/backup.sh && curl -s "https://status.seudominio.com.br/api/push/CODIGO?status=up&msg=OK"

Criar status page pública

Status page profissional para comunicar disponibilidade aos clientes:

bash
# No Uptime Kuma — Status Page → New Status Page

# Configurações da status page:
# - Slug: status (resulta em https://status.seudominio.com.br/status/status)
# - Title: Status da Plataforma Runstack
# - Selecionar monitores para exibir

# Configurar domínio customizado para a status page:
# Settings → Status Pages → Edit → Custom Domain
# status.seudominio.com.br

# Nginx para domínio customizado da status page:
server {
    listen 443 ssl http2;
    server_name status-publico.seudominio.com.br;

    location / {
        proxy_pass http://127.0.0.1:3001/status/meu-slug;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# A status page mostra:
# - Status atual (operacional, degradado, interrupção)
# - Uptime dos últimos 90 dias (barra visual)
# - Histórico de incidentes
# - Latência média

Monitorar containers Docker internos

Uptime Kuma pode monitorar o estado de containers na própria VPS:

yaml
# Para monitorar containers Docker, o Uptime Kuma precisa de acesso ao socket:
# docker-compose.yml — adicionar o socket:
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    restart: always
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime_kuma_data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro   # somente leitura

# Na interface — Add Monitor → Docker Container
# Container Name: nome do container (ex: minha-api-app-1)
# Verifica se o container está em estado "running"

# Combinação poderosa: monitor HTTP + monitor Docker:
# - HTTP: verifica que a aplicação responde corretamente
# - Docker: verifica que o container está rodando
# - Push: verifica que o cron de backup executou

# Grupos de monitores para organizar:
# - Produção → API, Frontend, Banco
# - Infraestrutura → Nginx, Portainer, n8n

Backup e recuperação do Uptime Kuma

Backup dos dados de monitoramento e histórico:

bash
# Backup do volume (contém SQLite com todo o histórico):
DATE=$(date +%Y%m%d_%H%M)

docker run --rm \
  -v uptime_kuma_data:/data \
  -v /var/backups:/backup \
  alpine tar czf "/backup/uptime_kuma_${DATE}.tar.gz" /data

# O volume contém:
# - kuma.db (SQLite com monitores, histórico, configurações)
# - ssl/ (certificados SSL do próprio Kuma, se configurado)

# Restaurar em novo servidor:
# 1. Parar o Kuma
# 2. Extrair backup no volume
docker run --rm \
  -v uptime_kuma_data:/data \
  -v /var/backups:/backup \
  alpine tar xzf "/backup/uptime_kuma_${DATE}.tar.gz" -C /

# 3. Reiniciar o Kuma
docker compose up -d uptime-kuma

Não quer configurar manualmente?

Implante o VPS em menos de 5 minutos com a Runstack. Infraestrutura da OPEN Datacenter, com servidores em São Paulo.

Perguntas frequentes

UptimeRobot/Better Uptime: monitoramento externo de fora da sua rede, detecta quedas que o self-hosted não veria (queda da própria VPS). Uptime Kuma self-hosted: sem limites de monitores, sem custo extra, mais tipos de monitor (Docker, Push, DNS), status pages customizadas. Combinação ideal: Uptime Kuma para monitoramento interno + UptimeRobot (plano gratuito) para monitoramento externo como segunda opinião.

Sim, de duas formas: (1) via HTTP: o Nginx expõe a porta e o Kuma acessa pelo hostname interno do Docker; (2) via Docker monitor (com acesso ao socket): verifica se o container está rodando pelo estado do daemon Docker. Para serviços sem porta HTTP: use o monitor Docker direto.

Uptime Kuma suporta alertas via WhatsApp através de integrações: Twilio (WhatsApp Business API), CallMeBot (gratuito para uso pessoal) ou Evolution API. Para Evolution API self-hosted: no Kuma → Notifications → Webhook → configurar POST para o endpoint do Evolution com o payload correto. É um dos poucos monitores que suporta isso nativamente.

Não há limite definido. A limitação é o desempenho do servidor: cada monitor HTTP faz uma requisição a cada intervalo configurado (padrão: 60s). Com 100 monitores a cada 60s: 100 req/min saindo da VPS. Para VPS de 2 GB RAM: centenas de monitores funcionam sem problema.

Sim, para monitores HTTP você pode configurar "Max Response Time" em ms: se a resposta demorar mais que o threshold, o status fica "degraded" (amarelo) em vez de "down" (vermelho). O histórico de latência fica visível no dashboard e na status page. Útil para detectar gargalos de performance antes de virar uma queda.