Uma pequena loja online em Konya roda o Uptime Kuma em um VPS (um servidor virtual alugado) no mesmo data center do seu servidor web, e o painel está verde há três dias. Na segunda-feira, a caixa de entrada do suporte diz outra coisa: clientes que usam dados móveis não conseguem carregar a página de checkout, e um revendedor na Alemanha não consegue acessar o site. A falha está em algum ponto do caminho até o site, como um problema de roteamento em uma rede ou uma regra de bloqueio geográfico ampla demais. O monitor ficava ao lado do site, então não viu nada disso.
Este guia mostra o que 99,9% de uptime significa em horas, o que o Uptime Kuma faz, qual tipo de monitor escolher e como instalá-lo com Docker. Depois mostra por que verificar a partir de um único lugar deixa um ponto cego, como enviar as verificações de um monitor por um proxy HTTP ou SOCKS5 e quanto tráfego isso consome.
O que é uptime e o que significa 99,9% de uptime?
Uptime (tempo de atividade) é a parcela do tempo em que um serviço esteve acessível durante um período medido; downtime (tempo de inatividade) é o restante. Não é o comando uptime do Linux, que mostra há quanto tempo uma máquina está ligada. Um ano de 365 dias tem 8.760 horas, e 99,9% deixa 0,1% delas, 8,76 horas, para o downtime. As calculadoras que mostram 8 horas, 45 minutos e 57 segundos contam o ano como 365,25 dias.
| Uptime | Downtime por ano (365 dias) | Por mês de 30 dias | Por dia |
|---|---|---|---|
| 99% | 87,6 horas | 7 h 12 min | 14 min 24 s |
| 99,5% | 43,8 horas | 3 h 36 min | 7 min 12 s |
| 99,9% | 8 h 45 min 36 s | 43 min 12 s | 1 min 26 s |
| 99,95% | 4 h 22 min 48 s | 21 min 36 s | 43 s |
| 99,99% | 52 min 34 s | 4 min 19 s | 8,6 s |
Uma garantia de uptime é essa meta escrita em um acordo de nível de serviço (SLA). O livro de SRE do Google descreve duas formas de medi-la: a parcela do tempo em que um sistema esteve no ar e a parcela das requisições que tiveram sucesso (Embracing Risk).
O que é o Uptime Kuma e para que serve?
O Uptime Kuma é uma ferramenta de monitoramento criada por Louis Lam e publicada sob a licença MIT. Você a instala no seu próprio servidor, abre no navegador e adiciona monitores; cada monitor é um endereço ou serviço a verificar. O repositório do projeto tinha mais de 90.000 estrelas em setembro de 2026, quando a versão atual era a 2.5.5.
Ao contrário de um serviço hospedado, ele guarda o histórico de verificações e as chaves de notificação no seu servidor e não limita o número de monitores. Em troca, você mantém esse servidor funcionando, e ele verifica a partir do lugar onde roda. Ele também oferece páginas de status públicas (menu Página de Status), janelas de Manutenção que pausam os alertas e uma interface em mais de 40 idiomas.
Como o Uptime Kuma verifica um site?
Todo monitor repete o mesmo ciclo:
- O intervalo termina. O Intervalo de Heartbeat é de 60 segundos por padrão. A requisição leva o User-Agent
Uptime-Kuma/2.5.5, então você consegue encontrá-la nos logs do seu servidor. - Ele espera. Se nenhuma resposta chega dentro do Tempo esgotado da requisição, 48 segundos por padrão, a verificação falha.
- Ele lê a resposta. O código de status precisa estar dentro de Códigos HTTP Aceitáveis,
200-299por padrão (Códigos de status HTTP). Um monitor de palavra-chave também procura a sua palavra na página, diferenciando maiúsculas de minúsculas. - Ele tenta de novo. Com Novas tentativas acima de 0, uma verificação que falhou é repetida no Intervalo de repetição de Heartbeat. Monitores novos começam com 0, então um único pacote perdido dispara um alerta.
- Ele alerta. Quando as tentativas acabam, o monitor passa para DOWN ("Desligado" na interface em português) e os canais que você adicionou em Configurações > Notificações recebem uma mensagem; quando uma verificação volta a passar, ele passa para UP ("Ligado").
- Ele registra. A página do monitor mostra o uptime de 24 horas, 30 dias e 1 ano.
A Notificação De Certificado Expirado vem desligada nos monitores novos. Ligue-a para sites HTTPS: o Let's Encrypt passou a oferecer em maio de 2026 certificados opcionais de 45 dias e planeja certificados de 64 dias por padrão a partir de fevereiro de 2027 (Let's Encrypt), então as renovações vão ficar mais frequentes.
Qual tipo de monitor escolher?
O Uptime Kuma 2.5.5 tem cerca de trinta tipos de monitor. A maioria dos sites precisa destes:
| Tipo de monitor | O que confirma | Por proxy? | Quando escolher |
|---|---|---|---|
| HTTP(s) | O servidor responde com um código de status aceito | Sim | Uma pequena página de health check |
| HTTP(s) - Palavra-Chave | A página contém uma palavra que você espera | Sim | Checkout, login |
| HTTP(s) - Consulta JSON | Uma resposta de API traz o valor esperado | Sim | Endpoints de API |
| TCP Port, Ping, DNS | Uma porta está aberta, um host responde, um registro está correto | Não | Banco de dados, servidor de e-mail, DNS |
| Push | Uma tarefa agendada informa que rodou | Não é necessário | Backups, cron jobs |
| Globalping | Ping, HTTP ou DNS a partir de uma sonda da comunidade | Não, roda a partir do local que você digita | Cobertura geográfica ampla |
| UptimeRobot (serviço hospedado, para comparação) | HTTP, palavra-chave, porta e ping a partir dos servidores do serviço | Não; os planos pagos escolhem entre quatro regiões (setembro de 2026) | Nada para instalar |
O HTTP(s) sozinho prova apenas que o servidor respondeu. Até uma página de manutenção ou um template quebrado pode responder 200 e contar como UP. Um monitor de palavra-chave que procura o rótulo do botão de pagamento pega os dois casos, e a opção Palavra-chave de Inversão alerta quando uma palavra como "manutenção" aparece. Uma página de health check é um endereço curto que o seu desenvolvedor adiciona e que responde "ok" quando a aplicação e o banco de dados respondem.
Avançado: como instalar o Uptime Kuma com Docker?
Você precisa de um VPS Linux ou de um servidor doméstico com Docker, separado da máquina que roda o site. O comando do README do projeto:
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2-droda o contêiner em segundo plano, e--restart=alwayso inicia de novo depois de uma falha ou reinicialização.-p 3001:3001publica a porta padrão 3001.-v uptime-kuma:/app/dataguarda o banco de dados em um volume do Docker, que continua existindo quando o contêiner é removido (volumes do Docker). O README diz que pastas de rede (NFS) não são suportadas.louislam/uptime-kuma:2acompanha a série 2.x; em 25 de setembro de 2026, apontava para a 2.5.5.
Com o Docker Compose, baixe o compose.yaml oficial em uma pasta vazia e rode docker compose up -d; ele guarda os dados em uma pasta local ./data. Depois abra http://ip-do-seu-servidor:3001, escolha o idioma e um banco de dados (SQLite basta para uma instalação pequena), crie a conta de administrador e clique em Adicionar novo monitor. Os nomes de menu deste guia são os da interface em português do Brasil. Para atualizar, baixe a nova imagem, remova o contêiner e rode o comando de novo; o volume mantém os seus monitores.
Abrir o painel no seu próprio domínio com HTTPS é trabalho de um reverse proxy como nginx ou Caddy, que precisa repassar os cabeçalhos Upgrade e Connection para o WebSocket; a wiki do projeto tem exemplos. As duas direções de proxy são comparadas em Forward proxy e reverse proxy: qual é a diferença?.
O que o monitoramento a partir de um único lugar deixa passar?
Um monitor no próprio data center do site prova que o servidor funciona, não que os clientes conseguem chegar até ele. Ele não percebe:
- Um problema de roteamento em uma rede: os clientes de um provedor não conseguem acessar o site.
- DNS que muda por região: um registro errado em um servidor DNS afeta só os usuários dele.
- Uma regra de bloqueio geográfico ampla demais: uma regra pensada para um país bloqueia também outro.
- Um servidor de CDN que devolve erros: uma CDN entrega o site a partir de muitos servidores, e só os visitantes enviados ao servidor com defeito veem os erros.
- IPs móveis compartilhados que batem em um limite de requisições: as operadoras colocam muitos usuários atrás de um único endereço (O que é CGNAT?).
Há três formas de ampliar a visão. A primeira é um segundo Uptime Kuma em outro país. A segunda é o tipo de monitor Globalping, adicionado na versão 2.1.0, que testa a partir de sondas mantidas pela comunidade; o campo de localização aceita um país, uma cidade ou o nome de um provedor (Globalping). O Globalping permite 250 testes por hora sem conta e escolhe entre as sondas online naquele momento, então uma rede específica pode estar sem sonda justamente quando você precisa.
A terceira forma é um proxy no monitor: a verificação sai por um ponto de saída no país que você escolher, a ideia por trás de um teste de localização.
Como configurar um proxy em um monitor do Uptime Kuma?
Isto trata das verificações de saída do monitor; o painel atrás do nginx é o caso do reverse proxy visto acima. As configurações de proxy aparecem só nos monitores HTTP(s), HTTP(s) - Palavra-Chave e HTTP(s) - Consulta JSON.
- Vá em Configurações > Proxies e clique em Configuração do Proxy.
- Em Protocolo Do Proxy, escolha HTTP ou SOCKS v5 (+DNS). A lista também tem HTTPS, SOCKS, SOCKS v5 e SOCKS v4.
- Em Servidor Proxy, digite
pr.proxynet.ioe a porta8000para HTTP, ou a porta SOCKS5 que o Gerador de endpoints mostra. - Marque O servidor proxy tem autenticação e preencha Usuário e Senha (aqui,
user:pass). Copie o nome de usuário do Gerador de endpoints do painel da Proxynet; ele carrega o país, a cidade e a sessão (Autenticação de proxy). - Definir como padrão atribui o proxy aos novos monitores, e Aplicar em todos os monitores existentes, aos atuais.
- Salve e, em cada monitor, escolha Sem Proxy ou o proxy na seção Proxy.
Para um segundo país, clique em Clonar ao lado do proxy e mude o país no nome de usuário. "Checkout (Türkiye)" e "Checkout (Alemanha)" podem então vigiar o mesmo endereço.
O protocolo decide onde o nome do site é resolvido. O SOCKS v5 resolve o domínio no servidor do Uptime Kuma; o SOCKS v5 (+DNS) e o HTTP deixam o proxy resolvê-lo na saída, então o DNS também é testado a partir do país de destino (Diferença entre SOCKS e HTTP proxy). Para confirmar a rota, aponte um monitor de palavra-chave com o proxy para uma página que mostre o seu país (Seu proxy está funcionando?).
O pool de Proxies móveis tem linhas da Turkcell, da Türk Telekom e da Vodafone em Türkiye. Você escolhe o país e a cidade, não a operadora; cada verificação mostra como o site se comporta em uma rede móvel.
Se o servidor não consegue chegar ao Telegram ou a outro serviço de alertas, a variável de ambiente NOTIFICATION_PROXY (desde a 2.0.0) envia a maioria dos alertas por um proxy, mas não os e-mails (variáveis de ambiente de proxy).
Quanto tráfego o monitoramento por proxy consome?
Proxies residenciais e móveis são cobrados por GB. Com um intervalo de 60 segundos, um monitor faz 43.200 verificações em 30 dias. O Uptime Kuma baixa só o HTML da página, sem imagens nem scripts, mas abre uma conexão nova pelo proxy a cada verificação, então cada uma repete o handshake TLS, a troca que estabelece a criptografia HTTPS.
Medimos isso em 25 de setembro de 2026, enviando a requisição do Uptime Kuma (com os cabeçalhos dele, sem compressão) por um proxy HTTP local e contando os bytes nas duas direções:
| O que o monitor carrega | Por verificação | A cada 60 s, 30 dias | A cada 300 s, 30 dias |
|---|---|---|---|
| Página de health check pequena, 0,5 KB de HTML | 6,8 KB | 0,29 GB | 0,06 GB |
| Página com 120 KB de HTML | 127 KB | 5,5 GB | 1,1 GB |
| A mesma página, comprimida com gzip | 36,5 KB | 1,6 GB | 0,32 GB |
| A mesma página, método HEAD | 7,5 KB | 0,32 GB | 0,06 GB |
Para calcular o seu número, pegue nas ferramentas de desenvolvedor do navegador o tamanho do HTML da página sem compressão, some 6 a 8 KB da conexão e multiplique pelas verificações por mês e pelo número de monitores. Para reduzir:
- Monitore uma página de health check em vez da página inicial.
- Use HEAD em Opções HTTP > Método; ele dispensa o corpo da página, então monitores de palavra-chave não podem usá-lo.
- Peça compressão com
{"Accept-Encoding": "gzip"}no campo Cabeçalhos; as verificações de palavra-chave continuam funcionando. - Aumente o intervalo: um monitor sem proxy a cada 60 segundos, monitores com proxy a cada 2 a 5 minutos.
Os Proxies residenciais dão uma saída de conexão doméstica no país que você escolher. Uma saída rotativa dá a cada verificação um novo endereço IP, o que faz os tempos de resposta oscilarem; os Proxies de sessão fixa mantêm um IP por 1-60 minutos.
Casos de uso
- O checkout visto a partir de dados móveis em Türkiye: um monitor de palavra-chave por meio de Proxies móveis.
- Um portal de revendedores para parceiros no exterior: um monitor por país de revendedor (testes de localização).
- A API do seu aplicativo móvel: um monitor de Consulta JSON verificado a partir de uma rede móvel (testes de aplicativos).
- Uma API de parceiro que aceita só IPs cadastrados: o Uptime Kuma em um servidor com IP fixo (IP estático e IP dinâmico).
- Mudanças no conteúdo de uma página: é outra tarefa, veja Como monitorar alterações em um site e receber alertas.
- Uma verificação pontual de "o site caiu?": veja Não é possível acessar esse site.
Erros comuns
- Instalar o monitor no servidor que ele vigia. Quando o servidor cai, a ferramenta que enviaria o alerta cai junto.
- Deixar Novas tentativas em 0. Um único pacote perdido às 3 da manhã acorda alguém; use 1 ou 2.
- Deixar o seu próprio firewall bloquear o monitor. Se o monitor começar a receber 403, libere o IP dele (erro Access Denied). Monitore só sites que são seus ou que você tem permissão para verificar.
- SOCKS v5 simples em um teste de localização. O DNS continua sendo resolvido no seu servidor.
- Ligar "Ignorar erros TLS/SSL para sites HTTPS". Isso também desliga o alerta de vencimento do certificado.
- Rodar o contêiner sem volume. Uma atualização apaga todos os monitores.
Guia de decisão
| Necessidade | Recomendação |
|---|---|
| Vigiar um site sem instalar nada | Um serviço hospedado; o Uptime Kuma se os dados devem ficar com você |
| Saber que a página abre com o conteúdo certo | HTTP(s) - Palavra-Chave no checkout, Novas tentativas 1-2 |
| Ver o site como os usuários móveis em Türkiye o veem | Um monitor por meio de um proxy móvel, HTTP ou SOCKS v5 (+DNS) |
| Verificar a partir do país de um cliente no exterior | Uma saída residencial nesse país; o Globalping, se uma localização aproximada bastar |
| Manter baixo o tráfego do proxy | Uma página de health check, HEAD ou gzip, intervalo de 2-5 minutos |
| Vigiar uma API de parceiro com lista de IPs permitidos | Um servidor com IP fixo na lista do parceiro |
| Abrir o painel no seu domínio com HTTPS | Um reverse proxy que repasse os cabeçalhos de WebSocket |
Perguntas frequentes
O Uptime Kuma é gratuito?
Sim, é um software de código aberto sob a licença MIT. Seus custos são o servidor em que ele roda e o eventual tráfego de proxy.
Qual porta o Uptime Kuma usa?
A porta 3001 por padrão. Em -p 8080:3001, o primeiro número é a porta no seu servidor e o segundo, a porta dentro do contêiner (O que é a porta 8080?).
Qual é a diferença entre o Uptime Kuma e o UptimeRobot?
O UptimeRobot é um serviço hospedado, sem nada para instalar; em setembro de 2026, o plano gratuito cobria 50 monitores com intervalo de 5 minutos. O Uptime Kuma roda no seu próprio servidor, sem limite de monitores, e a manutenção desse servidor fica com você.
Quanto downtime 99,9% de uptime permite em um mês?
43 minutos e 12 segundos em um mês de 30 dias, e cerca de 43 minutos e 50 segundos em um mês médio do calendário.
O que é uma garantia de uptime em um SLA?
É a meta de disponibilidade no contrato de um fornecedor. Confira o período de medição, o que fica de fora (como a manutenção planejada) e a compensação, muitas vezes um crédito de serviço.
O Uptime Kuma consegue monitorar de vários lugares?
Sim, embora a versão 2.5.5 não tenha agentes remotos: um monitor comum verifica a partir do próprio servidor. Para mais lugares, rode cópias em outros locais, use o tipo de monitor Globalping ou dê a cada monitor HTTP um proxy em outro país.
Em resumo
Um percentual de uptime só é tão preciso quanto o lugar de onde ele é medido. O Uptime Kuma se instala com um único comando do Docker; dê ao checkout um monitor de palavra-chave, defina Novas tentativas como 1 ou 2 e ligue o alerta de certificado. Para ver o que os seus clientes veem, rode o mesmo monitor por uma saída no país deles, depois de calcular o tráfego. A página dos nossos serviços de proxy lista os tipos de saída.
