---
title: "O que é o Uptime Kuma? Instalação e monitoramento via proxy"
description: "O Uptime Kuma é um monitor gratuito e de código aberto que verifica seu site em intervalos e avisa se ele cair. Veja a instalação com Docker e o uso de proxy."
url: https://proxynet.io/pt-br/blog/uptime-kuma
date: 2026-09-25
author: "Enver Kaya"
category: "Casos de uso, Integração"
lang: pt-BR
---

# O que é o Uptime Kuma? Instalação e monitoramento via proxy

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.

> **Nota: Resposta rápida**
>
> O Uptime Kuma é uma ferramenta de monitoramento gratuita e de código aberto que roda no seu próprio servidor. Ele verifica seu site, API ou porta em um intervalo definido (60 segundos por padrão), avisa você por e-mail, Telegram ou um de mais de 90 serviços de notificação quando uma verificação falha e mantém um percentual de uptime. Um uptime de 99,9% permite cerca de 8 horas e 45 minutos de indisponibilidade por ano. O Docker instala a ferramenta com um único comando. Monitores HTTP podem verificar por meio de um proxy, então você também vê se o site abre a partir de uma rede móvel em Türkiye ou do exterior.

## 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](https://sre.google/sre-book/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](https://github.com/louislam/uptime-kuma) 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:

1. **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.
2. **Ele espera.** Se nenhuma resposta chega dentro do **Tempo esgotado da requisição**, 48 segundos por padrão, a verificação falha.
3. **Ele lê a resposta.** O código de status precisa estar dentro de **Códigos HTTP Aceitáveis**, `200-299` por padrão ([Códigos de status HTTP](/pt-br/blog/http-status-codes-web-scraping)). Um monitor de palavra-chave também procura a sua palavra na página, diferenciando maiúsculas de minúsculas.
4. **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.
5. **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").
6. **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](https://letsencrypt.org/2025/12/02/from-90-to-45/)), 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:

```bash
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2
```

- `-d` roda o contêiner em segundo plano, e `--restart=always` o inicia de novo depois de uma falha ou reinicialização.
- `-p 3001:3001` publica a porta padrão 3001.
- `-v uptime-kuma:/app/data` guarda o banco de dados em um volume do Docker, que continua existindo quando o contêiner é removido ([volumes do Docker](https://docs.docker.com/engine/storage/volumes/)). O README diz que pastas de rede (NFS) não são suportadas.
- `louislam/uptime-kuma:2` acompanha 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](https://github.com/louislam/uptime-kuma/wiki/Reverse-Proxy) tem exemplos. As duas direções de proxy são comparadas em [Forward proxy e reverse proxy: qual é a diferença?](/pt-br/blog/forward-vs-reverse-proxy).

## 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?](/pt-br/blog/what-is-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](https://globalping.io/)). 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](/pt-br/localization).

## 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**.

1. Vá em **Configurações > Proxies** e clique em **Configuração do Proxy**.
2. Em **Protocolo Do Proxy**, escolha **HTTP** ou **SOCKS v5 (+DNS)**. A lista também tem HTTPS, SOCKS, SOCKS v5 e SOCKS v4.
3. Em **Servidor Proxy**, digite `pr.proxynet.io` e a porta `8000` para HTTP, ou a porta SOCKS5 que o Gerador de endpoints mostra.
4. 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](/pt-br/blog/proxy-authentication-methods)).
5. **Definir como padrão** atribui o proxy aos novos monitores, e **Aplicar em todos os monitores existentes**, aos atuais.
6. 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](/pt-br/blog/socks-vs-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?](/pt-br/blog/how-to-test-a-proxy)).

O pool de [Proxies móveis](https://proxynet.io/pt-br/mobile-proxy) 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](/pt-br/blog/wget-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](https://proxynet.io/pt-br/residential-proxy) 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](https://proxynet.io/pt-br/sticky-proxy) 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](https://proxynet.io/pt-br/mobile-proxy).
- **Um portal de revendedores para parceiros no exterior:** um monitor por país de revendedor ([testes de localização](/pt-br/localization)).
- **A API do seu aplicativo móvel:** um monitor de Consulta JSON verificado a partir de uma rede móvel ([testes de aplicativos](/pt-br/app-testing)).
- **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](/pt-br/blog/static-ip-vs-dynamic-ip)).
- **Mudanças no conteúdo de uma página:** é outra tarefa, veja [Como monitorar alterações em um site e receber alertas](/pt-br/blog/website-change-monitoring).
- **Uma verificação pontual de "o site caiu?":** veja [Não é possível acessar esse site](/pt-br/blog/this-site-cant-be-reached).

## 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](/pt-br/blog/access-denied-error)). 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?](/pt-br/blog/port-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](/pt-br/proxy) lista os tipos de saída.