Como criar uma página de status sem programar em 2026

Como criar uma página de status sem programar em 2026

Você descreve quais partes do seu serviço têm estado próprio e o que cada estado significa. O Zugo gera a página com a situação atual, o histórico de incidentes e o aviso em destaque, verifica numa sandbox e publica em seu-slug.zugo.run ou no seu domínio. A construção custa 6 créditos e cada edição custa 3.

Um ponto precisa ficar claro logo: a página gerada mostra o estado que você informa. Ela não fica pingando seus servidores sozinha, e confundir as duas coisas é o erro mais caro deste assunto.

Para que serve uma página de status e quem realmente lê?

Ela existe para uma situação específica: quando algo quebra e o seu suporte não dá conta do volume de perguntas iguais. Sem página de status, cada cliente descobre a queda sozinho e todos escrevem ao mesmo tempo, exatamente no momento em que o time está ocupado consertando.

Quem lê são três grupos. O usuário que travou no meio de uma tarefa e quer saber se o problema é dele ou seu. O time de suporte, que precisa de um endereço único para colar na resposta. E, em contrato corporativo, a área de tecnologia do cliente, que vai comparar o que você publicou com o que aconteceu.

Tem um efeito indireto que pouca gente calcula: página de status pública muda o comportamento interno. Quando existe um lugar onde a falha aparece com carimbo de hora, o time começa a registrar melhor, e o registro melhor é metade da análise depois.

Se ninguém depende do seu serviço para trabalhar, você provavelmente não precisa disso ainda. Um aviso no topo do site já resolve, e é mais barato de manter.

O que precisa aparecer na tela em dez segundos?

O estado agora, por componente, com data e hora da última atualização. Quem abre a página em pânico não lê parágrafo, procura cor e horário.

Componente é a parte que o cliente reconhece, não o nome do seu microsserviço. "Aplicativo web", "envio de e-mails", "importação de planilha" e "aplicativo do celular" fazem sentido para quem lê. "Fila de eventos v3" não faz.

Abaixo do estado atual vem o incidente aberto, se houver, e depois o histórico. Trinta ou noventa dias de histórico bastam. O carimbo de hora com fuso explícito é obrigatório: página de status sem horário é boato com fundo colorido.

A página de status atualiza sozinha?

Não por conta própria, e esse é o limite mais importante deste guia. O Zugo gera a página, não um sistema de monitoramento que fica testando seus endereços de minuto em minuto.

Existem dois caminhos práticos. O primeiro é atualizar na mão: alguém do plantão entra e muda o estado. Parece pouco sofisticado e funciona bem para equipe pequena, porque quem está de plantão já está no computador quando o problema aparece.

O segundo é ligar a página a um banco pela integração de banco de dados e fazer o seu monitoramento existente escrever ali. Se você já tem alguma checagem rodando, ela pode gravar o estado, e a página passa a só exibir. A checagem continua sendo sua, mas a vitrine sai de graça em termos de trabalho.

O caminho que não existe é a página adivinhar. Vale desconfiar de qualquer promessa em contrário, inclusive das nossas, e a diferença entre exibir estado e verificar estado é o que separa página honesta de página decorativa. O que a integração de banco cobre está detalhado em construtor de apps com IA e Supabase.

Por que a página de status não pode morar junto com o produto?

Porque ela precisa estar no ar justamente quando o produto não está. Página de status hospedada na mesma infraestrutura que caiu vai cair junto, e o cliente encontra erro de conexão no lugar onde deveria encontrar explicação.

Esse é um argumento a favor de gerar a página fora: publicada em seu-slug.zugo.run ou em um subdomínio próprio apontado para lá, ela não compartilha destino com o seu servidor de aplicação. É separação de verdade, não configuração diferente na mesma máquina.

Use um endereço curto e fácil de lembrar sob seu domínio, algo como status.seudominio.com.br. No meio de um incidente, ninguém procura link no e-mail antigo: as pessoas digitam o que imaginam que seja o endereço, e vale que a imaginação delas acerte.

Como descrever a página para a IA gerar a estrutura certa?

Liste seus componentes com o nome que o cliente usa, os estados possíveis e o que aparece durante um incidente. Quanto mais concreta a lista, menos edição depois.

Página de status para um sistema de gestão usado por escritórios contábeis.
Componentes: aplicativo web, login, importação de arquivos, envio de
e-mails, integração com prefeitura.
Estados: operacional, degradado, fora do ar, manutenção programada.
No topo: aviso destacado quando existe incidente aberto, com horário da
última atualização e fuso de Brasília.
Abaixo: histórico dos últimos 90 dias, com título, duração e o que foi
feito. Formulário para receber avisos por e-mail.
Visual sóbrio, legível no celular, sem animação.

Peça o histórico desde a primeira versão mesmo que ele comece vazio. Adicionar isso depois muda a estrutura da página, e mudar estrutura custa mais edições que já ter nascido com o espaço reservado.

Como avisar quem depende de você durante um incidente?

Com um campo de inscrição por e-mail na própria página, ligado à integração de e-mails. A pessoa se cadastra uma vez e passa a receber aviso de abertura e de resolução, sem precisar ficar recarregando.

Três mensagens costumam bastar por incidente. A primeira reconhece o problema e diz que vocês estão olhando, mesmo sem saber a causa. A segunda traz uma previsão realista ou a informação de que ainda não há previsão. A terceira encerra e diz o que foi feito.

Escreva sem eufemismo. "Estamos enfrentando instabilidade pontual em alguns cenários específicos" quando o sistema está fora do ar destrói mais confiança do que a queda em si. Quem lê já sabe que está fora, o texto só está confirmando se dá para acreditar em você.

Depois do incidente resolvido, o resumo do que mudou pode virar entrada de changelog, e os dois documentos se apoiam. O formato de changelog está em como criar uma página de changelog.

Quanto custa em créditos montar e manter?

O gasto é pequeno porque a página muda pouco depois de pronta. Publicar não consome crédito.

O plano gratuito dá 5 créditos, menos que uma construção completa. O Pro custa $25 por mês com 200 créditos, algo em torno de 16 plataformas multipágina, 33 construções ou 66 edições. O Business custa $99 por mês com 800 créditos.

Na prática, você gasta na montagem e depois quase nada. Cada componente novo que entrar na sua arquitetura custa uma edição de 3 créditos, e isso acontece poucas vezes por ano na maioria dos produtos.

Quanto tempo leva para ter a página no ar?

Uma construção simples fica pronta em torno de um minuto. Uma versão multipágina com histórico e inscrição leva alguns minutos. Antes da entrega o projeto passa por uma sandbox: build que não abre não é entregue.

Reserve mais tempo para o combinado do que para a página. Quem tem permissão de mudar o estado, em quanto tempo o primeiro aviso precisa sair, quem escreve o encerramento. Sem isso definido, a página fica verde durante a queda, que é o pior resultado possível.

Teste antes de precisar. Simule um incidente num horário calmo, mude o estado, confira o e-mail de aviso e volte ao normal. A primeira vez que você usar a página não pode ser a primeira vez que ela é usada.

O que o Zugo não faz aqui?

Ele não monitora, não mede tempo de resposta e não calcula disponibilidade acumulada. Se o seu contrato prevê relatório de disponibilidade, esse número sai do seu monitoramento, não desta página.

Ele também não substitui um time de desenvolvimento num produto complexo. Página de status é justamente um caso em que a geração serve bem, porque a complexidade está no seu sistema e não na vitrine, mas a fronteira precisa ficar visível para não gerar expectativa errada.

Regra específica, como calcular automaticamente o estado a partir de vários sinais, se resolve em rodadas de edição junto com um banco, e não em um prompt único. Vale começar simples e complicar depois, se realmente fizer falta.

Por onde começar?

Liste seus componentes com o nome que o cliente usa e decida quem tem a caneta para mudar o estado. Essas duas decisões valem mais que qualquer escolha visual, e nenhuma ferramenta toma elas por você.

Depois gere a primeira versão, aponte um subdomínio e faça um teste com incidente de mentira. Dá para começar em zugo.dev pelo plano gratuito.