Como montar uma página de status para os seus serviços em VPS

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.

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:

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.

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:

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:

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:

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:

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