São três da manhã e a API de pagamentos parou de responder. O cliente abre o app, vê um erro, tenta de novo, recarrega o navegador e só então escreve para o suporte. Se nesse momento existir um endereço público informando que o problema já foi identificado e que a equipe está trabalhando nele, boa parte dessas mensagens nem chega a ser enviada. Sem esse endereço, o silêncio vira desconfiança, e o atendimento passa a madrugada respondendo à mesma pergunta.
Neste guia, vamos montar uma página de status do zero em um servidor virtual. Instalamos o Uptime Kuma em um contêiner Docker, publicamos a ferramenta atrás de um Nginx com HTTPS, conectamos um domínio próprio, cadastramos os monitores, configuramos alertas e vemos como comunicar incidentes e janelas de manutenção. Ao longo do texto, comparamos a solução própria com serviços hospedados e listamos os erros que mais aparecem na prática.
Para acompanhar, você precisa de um VPS com Ubuntu ou Debian, acesso por SSH, um domínio sob seu controle e alguma familiaridade com o terminal. O processo completo leva cerca de uma hora.
Definições básicas: o que a página pública mostra
Uma página de status é um endereço público, como status.suaempresa.com.br, que mostra em tempo real se os serviços de uma empresa estão funcionando. Em inglês, o termo mais usado é status page. Cada componente (site, API, painel, banco de dados, e-mail) aparece com um indicador de cor, o histórico de disponibilidade dos últimos dias e a lista de incidentes recentes, com horário e explicação.
Vale separar três coisas que costumam se misturar. O monitoramento de VPS coleta dados: verifica de tempos em tempos se a porta responde, se o site devolve código 200 e se o certificado ainda é válido. O alerta avisa a equipe interna quando uma verificação falha. A página pública comunica o resultado para quem está de fora. Os três trabalham juntos, mas cada um tem público e linguagem próprios: o alerta fala com o engenheiro de plantão, a página fala com o cliente.
Na maior parte dos casos, a página usa um conjunto pequeno de estados. Padronizar os nomes logo no início evita que cada pessoa da equipe invente um vocabulário diferente a cada incidente.
| Estado | O que significa | Exemplo |
|---|---|---|
| Operacional | Todas as verificações passam dentro do limite esperado | Site responde em menos de 1 segundo |
| Desempenho degradado | O serviço funciona, mas com lentidão ou falhas intermitentes | API com tempo de resposta acima de 5 segundos |
| Interrupção parcial | Parte dos usuários ou dos recursos está afetada | Login funciona, mas o checkout retorna erro 500 |
| Interrupção total | O serviço não responde | Servidor sem resposta ao ping e à porta 443 |
| Manutenção | Parada programada e comunicada com antecedência | Atualização do banco de dados no domingo, às 2h |
Outro número que costuma aparecer na página é o percentual de uptime, ou seja, a fração do tempo em que o serviço esteve disponível. À primeira vista, 99% e 99,99% parecem quase iguais, mas a diferença em minutos é grande:
| Disponibilidade | Tempo fora do ar por mês (≈730 h) | Tempo fora do ar por ano |
|---|---|---|
| 99% | cerca de 7 h 18 min | cerca de 3 dias e 15 h 36 min |
| 99,9% | cerca de 44 min | cerca de 8 h 46 min |
| 99,99% | cerca de 4 min 23 s | cerca de 52 min 34 s |
| 99,999% | cerca de 26 s | cerca de 5 min 15 s |
Em outras palavras, se o contrato promete 99,9%, o orçamento mensal de falhas é de apenas 44 minutos. Uma única reinicialização mal planejada consome boa parte dele, e a página pública mostra esse consumo para todo mundo.
Como montar a página, passo a passo
A arquitetura é simples. Um servidor dedicado executa o Uptime Kuma, que faz verificações periódicas nos seus serviços, guarda o histórico em um banco SQLite local e desenha a página pública com os monitores que você escolher. A área administrativa fica protegida por login, e só a página pública fica aberta para visitantes.
Passo 1. Escolha onde a página vai rodar
Essa decisão pesa mais do que parece. Se a página ficar no mesmo servidor dos serviços que ela observa, ela cai junto com eles, justamente quando é mais necessária. O ideal é um VPS separado, de preferência em outro datacenter ou, no mínimo, em outra máquina e em outra rede. A configuração pode ser modesta: 1 vCPU, 1 GB de RAM e 10 GB de disco dão conta de dezenas de monitores. Um VPS na Serverspace com Ubuntu ou Debian atende bem a esse papel, e o custo de manter uma máquina pequena só para isso costuma ser baixo diante do prejuízo de ficar sem comunicação durante uma queda.
Passo 2. Prepare o sistema
Conecte por SSH e instale Docker, Nginx e Certbot. O comando abaixo resolve tudo de uma vez em Ubuntu e Debian:
Em seguida, libere no firewall apenas o que é necessário: SSH, HTTP e HTTPS. A porta 3001, usada pelo Uptime Kuma, permanece fechada para a internet e será acessada somente pelo Nginx.
Passo 3. Suba o Uptime Kuma
A imagem oficial é publicada como louislam/uptime-kuma. O comando a seguir cria o contêiner, ativa o reinício automático e guarda os dados em um volume Docker. O trecho 127.0.0.1 antes da porta é proposital: sem ele, o Docker publica a porta em todas as interfaces e passa por cima das regras do ufw.
Se o usuário atual não pertencer ao grupo docker, acrescente sudo no início. Depois de um minuto, confira se o contêiner aparece como saudável:
Passo 4. Configure o Nginx e o HTTPS
Antes de tudo, crie no painel do seu domínio um registro A que aponte o subdomínio (por exemplo, status.seudominio.com.br) para o IP do VPS. O Certbot só emite o certificado quando o DNS já responde corretamente.
Depois, crie um arquivo de site em /etc/nginx/sites-available/status com um bloco server que escute a porta 80 e tenha um location / com as diretivas da tabela. Os cabeçalhos de WebSocket são obrigatórios, porque o painel do Uptime Kuma depende dessa conexão para atualizar os dados em tempo real.
| Diretiva | Valor | Para que serve |
|---|---|---|
| server_name | status.seudominio.com.br | Define o domínio atendido pelo bloco |
| proxy_pass | http://127.0.0.1:3001 | Encaminha o tráfego para o contêiner |
| proxy_http_version | 1.1 | Necessária para o WebSocket funcionar |
| proxy_set_header Upgrade | $http_upgrade | Repassa o pedido de troca de protocolo |
| proxy_set_header Connection | "upgrade" | Mantém a conexão do painel aberta |
| proxy_set_header Host | $host | Permite que o Uptime Kuma identifique o domínio mapeado à página |
| proxy_set_header X-Forwarded-For | $proxy_add_x_forwarded_for | Preserva o IP real do visitante |
| proxy_set_header X-Forwarded-Proto | $scheme | Informa se a requisição chegou por HTTP ou HTTPS |
Com o arquivo pronto, ative o site, teste a sintaxe e recarregue o Nginx:
Agora o Certbot emite o certificado, ajusta o bloco para a porta 443 e agenda a renovação automática:
Passo 5. Crie o administrador e os monitores
Abra o endereço no navegador. Na primeira visita, o Uptime Kuma pede a criação de um usuário administrador. Escolha uma senha longa e, assim que entrar, ative a autenticação em dois fatores nas configurações do perfil. O painel de administração é a parte mais sensível de toda a instalação.
Em seguida, clique em adicionar monitor. O tipo escolhido define o que será verificado, e a variedade é grande:
| Tipo de monitor | O que verifica | Quando usar |
|---|---|---|
| HTTP(s) | Código de resposta de uma URL | Sites, APIs e painéis |
| HTTP(s) com palavra-chave | Presença de um texto na resposta | Páginas que devolvem 200 mesmo quando a aplicação falha |
| TCP | Se uma porta aceita conexões | Bancos de dados, SMTP, SSH |
| Ping | Resposta ICMP do servidor | Disponibilidade básica da máquina |
| DNS | Resolução de um registro | Confirmar que o domínio aponta para o IP esperado |
| Push | O próprio serviço envia um sinal periódico | Tarefas do cron, backups e rotinas internas |
Alguns ajustes fazem diferença desde o primeiro dia. O intervalo padrão é de 60 segundos, um bom ponto de partida. O campo de novas tentativas deve ficar em 2 ou 3, para que um tropeço isolado de rede não gere alerta nem marque a página como interrompida. Nos monitores HTTP, vale ativar o aviso de expiração do certificado, que evita o clássico susto de um site fora do ar por causa de um HTTPS vencido. Por fim, use nomes que o cliente entenda: "API de pagamentos" funciona melhor do que "api-prod-02".
Passo 6. Configure as notificações
Em Configurações, na seção de notificações, o Uptime Kuma oferece Telegram, Discord, Slack, e-mail por SMTP, webhook e dezenas de outros canais. Cadastre pelo menos dois, de naturezas diferentes. Um alerta que chega só por e-mail pode passar despercebido num domingo, e um bot de chat também pode ficar indisponível. Use o botão de teste para confirmar a entrega e marque a opção que aplica o canal a todos os monitores novos, para que nenhum fique sem aviso por esquecimento.
Passo 7. Monte a página pública
No menu de páginas de status, crie uma nova página, informe o nome e o slug (o endereço fica no formato /status/slug). Na tela de edição, organize os monitores em grupos que façam sentido para quem lê, como "Site e loja", "API" e "Infraestrutura". Adicione descrição, logotipo e texto de rodapé. Também é possível desativar a linha "powered by" e aplicar CSS próprio para combinar com a identidade visual da empresa.
Para usar um endereço próprio, abra a configuração de domínios da página e cadastre o subdomínio. A partir daí, o endereço raiz desse domínio exibe a página diretamente, sem o /status/slug. É aqui que o cabeçalho Host repassado pelo Nginx se mostra indispensável: sem ele, o Uptime Kuma não sabe qual página servir.
Passo 8. Prepare a comunicação de incidentes e manutenções
Os monitores atualizam as cores sozinhos, mas a explicação humana depende de você. Na edição da página, o botão de novo incidente abre um formulário com título, mensagem e estilo (informativo, aviso ou crítico). O incidente fica fixado no topo até ser removido. Já as paradas programadas ficam no menu de manutenção, onde é possível definir janelas únicas ou recorrentes. Durante a janela, os monitores afetados aparecem como "em manutenção" e deixam de disparar alertas.
Ter modelos de mensagem prontos acelera a resposta e padroniza o tom. Os textos abaixo servem de ponto de partida:
| Etapa | Exemplo de mensagem |
|---|---|
| Investigando | Estamos investigando lentidão na API de pagamentos, observada a partir das 14h05. |
| Causa identificada | Identificamos sobrecarga no banco de dados. A correção está em andamento. |
| Monitorando | A correção foi aplicada e o serviço voltou ao normal. Seguimos acompanhando. |
| Resolvido | Incidente encerrado às 14h52. Pedimos desculpas pelo transtorno e publicaremos um resumo da causa. |
Passo 9. Garanta backup e atualização
Todo o histórico e as configurações ficam no volume uptime-kuma. Um backup simples copia esse volume para um arquivo compactado na pasta atual:
Para atualizar, faça o backup, baixe a imagem nova, remova o contêiner antigo e execute de novo o mesmo comando docker run do passo 3. O volume permanece intacto, então nada se perde.
Vantagens e desvantagens de hospedar a própria página
Rodar a ferramenta no seu servidor dá liberdade, mas traz responsabilidades. Os pontos fortes da abordagem são estes:
- controle total sobre dados, domínio e aparência;
- nenhuma cobrança por quantidade de monitores ou de visitantes;
- integração direta com os canais de alerta que a equipe já usa;
- suporte a vários tipos de verificação em uma única interface;
- possibilidade de manter páginas separadas para clientes ou produtos diferentes.
Do outro lado, existem custos que não aparecem na fatura:
- você mesmo cuida de atualizações, certificados e backups;
- as verificações partem de um único ponto, o que limita a visão de problemas regionais;
- a comunicação de incidentes é manual;
- não há suporte comercial para dúvidas urgentes.
Antes de decidir, compare com as alternativas. A tabela reúne as opções mais citadas:
| Solução | Modelo | Ponto forte | Ponto de atenção |
|---|---|---|---|
| Uptime Kuma | Auto-hospedado, código aberto | Interface completa e instalação rápida com Docker | Manutenção do servidor fica com você |
| Gatus | Auto-hospedado, configuração em YAML | Leve e fácil de versionar no Git | Exige edição de arquivo para cada mudança |
| Cachet | Auto-hospedado, PHP | Foco em componentes e comunicação de incidentes | Costuma depender de outra ferramenta para coletar as verificações |
| Upptime | GitHub Actions e GitHub Pages | Dispensa servidor próprio | Intervalos de verificação mais longos, de cerca de 5 minutos |
| Atlassian Statuspage | Serviço hospedado | Assinatura de avisos por e-mail e integrações prontas | Cobrança mensal por plano |
| Instatus | Serviço hospedado | Configuração rápida e visual limpo | Recursos avançados ficam em planos pagos |
| Better Stack | Serviço hospedado | Monitoramento, alertas e página na mesma plataforma | Custo cresce com o número de monitores |
Limitações e riscos
O primeiro limite é o ponto de observação. Com uma única instância, o Uptime Kuma enxerga seus serviços de um lugar só. Se a rede do próprio servidor de status tiver um problema, ele pode registrar uma falha que os clientes não estão sentindo. As tentativas extras reduzem esse risco, e uma segunda instância em outro datacenter reduz ainda mais, já que o alerta só procede quando as duas concordam.
O segundo risco é o monitor que ninguém monitora. Se o VPS de status travar, a página fica congelada em "tudo operacional" e passa uma falsa sensação de segurança. Uma solução prática é criar no Uptime Kuma um monitor do tipo Push e, em um serviço externo, configurar um alerta para o caso de o sinal parar de chegar. Outra saída é usar um segundo servidor que vigie o primeiro.
Há também o cuidado com o que se publica. Nomes de componentes internos, endereços IP e detalhes de infraestrutura ajudam um atacante e não interessam ao cliente. Mostre somente o que o público entende e usa. Em paralelo, mantenha o painel administrativo com senha forte, autenticação em dois fatores e atualizações em dia, porque uma ferramenta de monitoramento comprometida entrega um mapa completo da sua operação.
Por fim, existe o peso do compromisso. Uma página que exibe o uptime de cada serviço cria expectativa e, em contratos com SLA, serve de referência em discussões. Convém alinhar com a área comercial quais números aparecem e quais verificações entram no cálculo, para evitar discordâncias depois.
Cenários práticos
Agência que hospeda sites de vários clientes
Uma agência com 30 sites em VPS diferentes precisa responder rápido à pergunta "meu site caiu?". O Uptime Kuma aceita várias páginas de status na mesma instalação, e cada uma pode ter domínio próprio. A agência cria uma página por cliente, com o logotipo dele, e envia o link no onboarding. Quando algo falha, o cliente consulta o endereço antes de abrir chamado, e o time ganha tempo para resolver.
Loja virtual com API de pagamentos
Em um e-commerce, "o site está no ar" não basta, porque a home pode carregar enquanto o checkout falha. A solução combina monitores HTTP com palavra-chave (por exemplo, o texto "Finalizar compra" na página do carrinho), uma verificação TCP no banco de dados e um monitor Push que recebe sinal do job de conciliação de pedidos. Na página, os grupos aparecem como "Vitrine", "Checkout" e "Pagamentos". Em datas de pico, como a Black Friday, vale avisar a janela de manutenção com antecedência e manter um canal de alerta extra ativo.
Empresa de software com SLA de 99,9%
Com meta de 99,9%, o orçamento mensal de falhas é de cerca de 44 minutos. A equipe publica o histórico de 90 dias na página, registra cada incidente com horário de início e fim e usa esses registros nas revisões pós-incidente. Quando um cliente questiona um período específico, a resposta já está documentada, com linha do tempo e causa. Essa transparência costuma gerar mais confiança do que a promessa de que nada nunca falha.
Painel interno para a equipe de TI
Nem toda página precisa ser pública. Para serviços internos, como VPN, servidor de arquivos e sistemas de RH, a equipe publica a página em uma rede restrita ou coloca autenticação básica no Nginx, com a diretiva auth_basic. Os funcionários consultam o painel antes de abrir chamado, e a TI deixa de receber vinte mensagens iguais quando o servidor de arquivos reinicia.
Erros comuns
A maior parte dos problemas se repete de instalação para instalação. A tabela relaciona os sintomas mais frequentes com a causa provável e a correção:
| Sintoma | Causa provável | Solução |
|---|---|---|
| O painel carrega, mas fica reconectando | Nginx sem os cabeçalhos de WebSocket | Adicionar Upgrade e Connection e recarregar o Nginx |
| O domínio próprio abre a tela de login em vez da página | Cabeçalho Host não repassado ou domínio não cadastrado na página | Incluir proxy_set_header Host $host e cadastrar o domínio na configuração da página |
| Alertas falsos de madrugada | Nenhuma nova tentativa antes de acusar falha | Definir 2 ou 3 tentativas e revisar o limite de tempo |
| O Certbot não emite o certificado | DNS ainda não propagado ou porta 80 bloqueada | Conferir o registro A e as regras do firewall |
| A porta 3001 responde pela internet | Contêiner criado sem o prefixo 127.0.0.1 | Recriar o contêiner com -p 127.0.0.1:3001:3001 |
| Histórico perdido após a atualização | Contêiner iniciado sem volume | Sempre usar -v uptime-kuma:/app/data e fazer backup antes |
| A página cai junto com o serviço | Hospedada no mesmo servidor monitorado | Migrar para um VPS separado, em outra rede |
Os erros de comunicação são mais discretos e, na prática, custam mais confiança do que qualquer falha técnica. Os mais frequentes são mensagens vagas como "estamos com instabilidade", incidentes que ficam abertos por dias sem atualização e páginas que continuam verdes enquanto os clientes reclamam nas redes sociais. Um bom hábito é atualizar o incidente a cada 30 ou 60 minutos, mesmo que a única novidade seja "seguimos investigando". Quem lê prefere uma atualização curta a um vazio.
Conclusão
Uma página de status bem montada reduz chamados repetidos, dá ao time de atendimento uma fonte de verdade e mostra ao cliente que há alguém cuidando do serviço. A parte técnica cabe em uma tarde: um VPS pequeno, o Uptime Kuma em Docker, Nginx com HTTPS e um domínio próprio. O trabalho contínuo está na disciplina de manter os monitores atualizados, testar os alertas e comunicar cada incidente com clareza.
Um bom monitoramento de VPS começa com poucos monitores bem escolhidos, cresce conforme o serviço cresce e nunca depende do mesmo servidor que ele vigia. Se você quer montar esse ambiente em uma máquina separada, o VPS da Serverspace atende à configuração descrita neste guia, e no blog da Serverspace há outros materiais sobre administração de servidores, segurança e DevOps.
Perguntas frequentes
Preciso de um servidor exclusivo para a página de status?
Não é obrigatório, mas é altamente recomendável. Se a página rodar no mesmo servidor dos serviços monitorados, ela fica indisponível junto com eles. Um VPS pequeno, em outro datacenter, resolve o problema por um custo baixo.
O Uptime Kuma é gratuito?
Sim. O projeto é de código aberto, sob licença MIT, e você paga apenas pela infraestrutura em que ele roda. Para dezenas de monitores, um VPS com 1 vCPU e 1 GB de RAM costuma ser suficiente.
Posso criar mais de uma página de status na mesma instalação?
Pode. O Uptime Kuma permite várias páginas, cada uma com seus grupos de monitores, aparência e domínio. Isso ajuda quem atende vários clientes ou mantém produtos diferentes.
Como monitorar um serviço que fica em uma rede privada?
Há duas saídas. Você pode conectar o servidor de status à rede privada por VPN e usar monitores comuns, ou usar o tipo Push: o serviço interno envia um sinal periódico ao Uptime Kuma, e a ausência do sinal gera o alerta.
Com que frequência devo verificar os serviços?
Para serviços críticos, como API e checkout, intervalos de 30 a 60 segundos funcionam bem. Para componentes secundários, 5 minutos costumam bastar e poupam recursos. Combine o intervalo com 2 ou 3 novas tentativas para reduzir alertas falsos.
Vale usar um subdomínio ou o domínio principal?
Um subdomínio como status.seudominio.com.br é a escolha mais comum. Ele isola a página do site principal e evita que uma queda do site leve a página junto, caso os dois estejam em servidores diferentes.