Como usar Upptime para criar sua própria página de status gratuitamente

18 de jun. de 2026

Participação de IA

A IA ajudou na escrita, edição ou revisão desta página.

Avalie os detalhes importantes com cuidado e confirme decisões críticas em fontes primárias quando necessário.

Como usar Upptime para criar sua própria página de status gratuitamente

Mova toda a monitoração para o repositório GitHub — Actions como sonda, repositório como banco de dados, Pages como CDN, Issues como livro de eventos. Sem servidor, sem mensalidade, criando uma página de status que pode ser visualizada, consultada e que mantém registros. Seja chamado de magia negra ou de sabedoria dos pobres, no fim está funcionando.

Antecedentes

Ao operar uma pequena matriz de produtos composta por mais de dez serviços externos, “está funcionando ou não” frequentemente se tornou uma frase clichê. Clientes relatam que não conseguem acessar, você faz ssh e roda curl e descobre que está funcionando; alguns minutos depois para, mas você não estava observando nesse momento. Monitoramento comercial (Pingdom, nível avançado do UptimeRobot, Datadog) pode resolver isso, mas cobra por site ou por número de requisições, o que não é muito vantajoso em termos de custo e carga mental para um desenvolvedor independente.

O mais importante é que a própria página de status precise ser acessível aos usuários. O cenário ideal seria: um domínio (por exemplo, status.hagicode.com), exibindo em tempo real a disponibilidade de cada serviço, curvas de tempo de resposta, eventos históricos, e capaz de registrar e notificar automaticamente durante falhas. A abordagem tradicional requer quatro componentes — servidor rodando cron, banco de dados para dados históricos, site frontend, CDN. Esses quatro componentes dispostos juntos, os custos de operação imediatamente ultrapassam os próprios serviços monitorados, afinal é usar faca para matar galinha, e a galinha ainda acha apertado.

Para resolver esses pontos de dor, tomamos uma decisão: mover todo o esquema de monitoramento diretamente para o GitHub. Essa decisão trouxe mudanças que podem ser maiores do que você imagina — vou detalhar mais tarde.

Sobre HagiCode

O esquema compartilhado neste artigo vem da experiência que acumulamos no projeto HagiCode. O HagiCode é um projeto de assistente de código AI, que expõe mais de dez serviços públicos como site, documentação, endpoints de download, etc., impulsionado pelo repositório principal HagiCode-org/site. Esses sites devem ser estáveis e disponíveis, então o monitoramento de status para nós não é opcional, mas essencial. O esquema Upptime abaixo é exatamente o que o HagiCode usa em produção — não inventei.

Análise: Como o Upptime realmente funciona

A essência do Upptime é, na verdade, um template de repositório GitHub, mais seis workflows gerados pelo template. A chave para entendê-lo é ver claramente “quem em que momento, chama quem, produz o que e onde cai”. Quando você o desmonta, não é tão misterioso.

Fluxo de dados: Um arquivo de configuração que impulsiona tudo

Todo o sistema gira em torno de um único arquivo de configuração declarativo .upptimerc.yml. A estrutura real da configuração do HagiCode é mais ou menos assim:

owner: HagiCode-org
repo: upptime

sites:
  - name: HagiCode Website
    url: https://www.hagicode.com
  - name: HagiCode Docs
    url: https://docs.hagicode.com
  - name: Server Package Index
    url: https://index.hagicode.com/server/index.json
  # ... 14 sites no total

status-website:
  cname: status.hagicode.com
  logoUrl: https://raw.githubusercontent.com/HagiCode-org/upptime/master/assets/upptime-icon.svg
  name: HagiCode Status
  introTitle: "**HagiCode Status**"
  introMessage: Real-time availability tracking for public HagiCode websites and download endpoints.
  navbar:
    - title: Status
      href: /
    - title: GitHub
      href: https://github.com/$OWNER/$REPO

Há dois pontos que vale destacar. Primeiro, sites pode monitorar páginas (retornando HTML) quanto endpoints JSON puros (como index.json), o Upptime só olha o código de status HTTP e o tempo de resposta, não faz validação de conteúdo. Segundo, cname aponta para status.hagicode.com, o que exige que você possua esse domínio e aponte o DNS para GitHub Pages — afinal, de graça é de graça, mas o domínio você precisa fornecer.

A divisão de trabalho dos seis workflows

Todos os arquivos em .github/workflows/ têm no topo uma linha de aviso Do not edit this file directly! — eles são atualizados automaticamente pelo template semanalmente, você só edita .upptimerc.yml. Cada workflow é acionado por cron, chamando diferentes subcomandos da mesma action upptime/uptime-monitor@v1.42.6, com divisão clara de trabalho, o que também economiza preocupações:

Workflow	cron	comando	função
uptime.yml	*/5 * * * *	update	Verifica a cada 5 minutos, escreve history/*.yml
response-time.yml	—	response-time	Calcula estatísticas de tempo de resposta
graphs.yml	—	graphs	Gera curvas PNG diárias/semanais/mensais/anuais
summary.yml	—	summary	Atualiza tabela de status no README
site.yml	0 1 * * *	site	Constrói site estático diariamente, implanta no Pages
update-template.yml	0 0 * * *	—	Sincroniza template upstream semanalmente

O trecho principal do uptime.yml mostra como a “sonda” funciona:

on:
  schedule:
    - cron: "*/5 * * * *"
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          token: ${{ secrets.GH_PAT || github.token }}
      - name: Check endpoint status
        uses: upptime/uptime-monitor@v1.42.6
        with:
          command: "update"
        env:
          GH_PAT: ${{ secrets.GH_PAT || github.token }}
          SECRETS_CONTEXT: ${{ toJson(secrets) }}

O site.yml tem um passo adicional, usando peaceiris/actions-gh-pages@v4 para enviar o build para o branch gh-pages:

- uses: peaceiris/actions-gh-pages@v4
  with:
    github_token: ${{ secrets.GH_PAT || github.token }}
    publish_dir: "site/status-page/__sapper__/export/"
    user_name: "Upptime Bot"
    user_email: "73812536+upptime-bot@users.noreply.github.com"

Persistência de dados: Arquivos como banco de dados

Os resultados de monitoramento não são armazenados em banco de dados, mas comitados de volta ao repositório como arquivos. Isso soa um pouco selvagem, mas na prática é bastante confiável. Cada site tem três tipos de produtos.

Snapshot de status history/{slug}.yml, por exemplo history/hagi-code-website.yml:

url: https://www.hagicode.com
status: up
code: 200
responseTime: 96
lastUpdated: 2026-06-17T00:22:34.485Z
startTime: 2026-03-24T10:07:32.531Z

Fonte de dados para badges de endpoint do shields.io api/{slug}/response-time.json, uptime.json:

{"schemaVersion":1,"label":"response time","message":"739 ms","color":"yellow"}

E gráficos de curva de tempo de resposta graphs/{slug}/response-time-{day,week,month,year}.png.

Essa troca de “arquivos como banco de dados” é bastante clara: muitas escritas poucas leituras, escala controlável (cerca de 288 amostras por site por dia, armazenando incrementos em vez de totais), histórico de versões nativo, infraestrutura zero. O custo é que o repositório cresce continuamente, e ocasionalmente você precisa verificar seu tamanho.

Eventos e notificações: Issues como livro de eventos

O registro de falhas depende do GitHub Issues, com dois templates embutidos no repositório: .github/ISSUE_TEMPLATE/bug_report.md (relatório de bug do usuário) e maintainance-event.md (manutenção planejada). O template de manutenção usa frontmatter para expressar janelas de tempo:

<!--
start: 2021-08-24T13:00:00.220Z
end: 2021-08-24T14:00:00.220Z
expectedDown: google, hacker-news
-->

O Upptime analisa essas Issues e renderiza “em manutenção” e “eventos ocorridos” na página de status e no README. As notificações dependem do mecanismo de watch do Issue, além de webhook configurável, Slack, Telegram (declarando notifications no topo de .upptimerc.yml, o repositório de exemplo do HagiCode atualmente não ativou, afinal quanto menos, melhor).

Solução: Cinco passos para replicar uma página de status

Para replicar uma página de status igual à do HagiCode, do zero ao online, são cinco passos. Cinco passos, mas cada um não é longo, vá com calma.

Passo 1: Criar repositório a partir do template

Não faça git clone e edite, crie um repositório diretamente usando o “Use this template” do GitHub (por exemplo, your-org/upptime). O template já tem todos os workflows, templates de Issue e o esqueleto do site estático embutidos. Depois de clonar localmente, a única coisa que você precisa editar manualmente é .upptimerc.yml — o resto, deixe como está.

Passo 2: Editar .upptimerc.yml

Mude owner/repo para os seus, liste os endereços para monitorar em sites, configure o site em status-website. A versão mínima funcional é mais ou menos assim:

owner: your-org
repo: upptime

sites:
  - name: Main Site
    url: https://example.com
  - name: API Health
    url: https://api.example.com/health
    expectedStatusCodes:
      - 200

status-website:
  cname: status.example.com   # Se não tiver domínio, pode remover, usar o padrão your-org.github.io/upptime
  name: Example Status
  introTitle: "**Example Status**"
  introMessage: Monitoramento em tempo real de disponibilidade de serviços
  navbar:
    - title: Status
      href: /
    - title: GitHub
      href: https://github.com/$OWNER/$REPO

Itens avançados: expectedStatusCodes limita códigos de status aceitáveis (padrão 200-399); headers personaliza cabeçalhos de requisição (para endpoints que exigem autenticação); maxResponseTime marca respostas lentas. Todos dependem das suas necessidades, use conforme necessário.

Passo 3: Configurar Secret e permissões

Os workflows usam por padrão ${{ secrets.GH_PAT || github.token }}. O github.token consegue executar o fluxo básico, mas há duas limitações que vão te pegar:

1. Workflows acionados pelo token padrão não acionam workflows downstream (para evitar loops), fazendo com que a cadeia “verificação → criar Issue → notificar” quebre no meio.
2. Permissão insuficiente para operações entre repositórios (como múltiplas organizações).

Recomenda-se criar um novo PAT (precisa de permissões repo + workflow), armazenado como Secret do repositório GH_PAT. No update-template.yml há uma verificação específica: sem GH_PAT pula a atualização automática do template e imprime um aviso, então esse secret não é apenas opcional, mas a chave para menos preocupações.

Passo 4: Ativar GitHub Pages

Repositório Settings → Pages → Source escolha Deploy from a branch, branch escolha gh-pages, diretório /root. O site.yml automaticamente envia o build para esse branch todos os dias às 1 da manhã. Se configurou cname, vá ao seu provedor DNS e adicione um registro CNAME apontando para your-org.github.io.

Também vale a pena acionar manualmente uma vez: Actions página encontre “Static Site CI” → Run workflow, não fique esperando a tarefa agendada, afinal quanto mais cedo ver o resultado, mais cedo fica tranquilo.

Passo 5: Verificação e manutenção

Depois de enviar a configuração, vá ao Actions ver se “Uptime CI” roda a cada 5 minutos, se history/ começa a aparecer arquivos *.yml. O endereço da página de status é https://<your-org>.github.io/upptime/ ou seu domínio personalizado. Depois para adicionar sites, mudar domínio, só precisa editar um arquivo .upptimerc.yml, workflows são totalmente automáticos. O HagiCode usa esse mecanismo para manter a disponibilidade de 14 endpoints há mais de um ano, praticamente sem se preocupar.

Prática: Os buracos que pisamos, já atravessamos para você

A seguir, alguns pontos que o HagiCode acumulou durante a operação real, escrevi para você evitar desvios.

Prática 1: Escolha da granularidade de monitoramento

O HagiCode coloca páginas (https://www.hagicode.com) e endpoints de dados puros (https://index.hagicode.com/server/index.json) na mesma lista sites. Para endpoints JSON, o Upptime fará a requisição e analisará o código de status HTTP, mas não valida a estrutura do conteúdo. Se você precisa de verificação profunda como “retorna 200 mas conteúdo errado”, use expectedStatusCodes com sonda externa para complementar, o Upptime só faz verificação HTTP de caixa preta — ele só olha a cara, não lê a mente.

Prática 2: O uso inteligente de badges de tempo de resposta

api/{slug}/response-time.json é a fonte de dados para badges de endpoint do shields.io. O README do HagiCode usa muito esse tipo de URL:

https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2FHagiCode-org%2Fupptime%2FHEAD%2Fapi%2Fhagi-code-website%2Fresponse-time.json

Assim, você pode incorporar badges de tempo de resposta em tempo real em qualquer Markdown (README do projeto, blog, páginas de terceiros), a cor é impulsionada pelo valor em message e pelo campo color. Note que usar HEAD em vez de master/main para referenciar arquivos raw evita falhas em massa após renomear branch — nos detalhes, esconde-se a estabilidade.

Prática 3: Controle de tamanho do repositório

Uma amostra a cada 5 minutos, ao longo de um ano history/ acumulará um volume considerável. O Upptime usa YAML incremental em vez de logs completos, relativamente contido, mas ainda recomenda verificar ocasionalmente o tamanho do repositório. Se o valor de monitoramento de um site diminuiu, basta removê-lo de sites, os arquivos históricos correspondentes também podem ser limpos manualmente, afinal se não conseguir excluir, o repositório cedo ou tarde ficará inchado para você ver.

Prática 4: Uso real de eventos de manutenção

maintainance-event.md não é enfeite. Antes de planejar uma release, abra uma Issue seguindo o template, preencha start/end/expectedDown, o Upptime marcará os sites correspondentes durante esse período como “manutenção planejada”, não contando nas estatísticas de disponibilidade, evitando que uma release normal puxe o SLA anual para baixo. O expectedDown do HagiCode suporta lista de nomes de sites separada por vírgula, correspondendo um a um com sites[].name.

Prática 5: Fronteira entre atualização de template e personalização

Todos os Do not edit this file directly! no topo de .github/workflows/*.yml não são para assustar. O update-template.yml substituirá esses arquivos semanalmente com o template upstream. Quando precisar personalizar comportamentos, a abordagem correta é usar itens de configuração oficialmente suportados em .upptimerc.yml (como skipTopics, customStatusWebsite, runnerSettings), em vez de editar workflows. Se realmente precisar editar workflows, ou desative update-template.yml, ou faça fork e mantenha o template você mesmo — o último perde atualizações sem dor, entre ganhos e perdas, você mesmo avalia.

Prática 6: Restrições reais da cota gratuita

O GitHub Actions é gratuito para repositórios públicos, sem limite de tempo, o design do Upptime aproveita exatamente isso. Repositórios privados têm 2000 minutos gratuitos por mês, enquanto uptime.yml roda a cada 5 minutos, cada vez cerca de 1 minuto, só esse item já aproximadamente 8640 minutos por mês, vai exceder. Então o repositório Upptime deve ser público, essa é a premissa de “gratuito” — não tente fazer privado por causa de sigilo e depois receber a conta, isso ficaria constrangedor.

Resumo

Voltando à pergunta inicial: monitorar um monte de serviços externos, existe uma solução barata? A resposta do HagiCode é — existe, e tão barata que você duvida se é de verdade. O Upptime decompõe o monitoramento em quatro componentes nativos do GitHub:

• Sonda = cron do GitHub Actions
• Banco de dados = arquivos YAML/JSON no repositório
• CDN = GitHub Pages
• Livro de eventos = GitHub Issues

Você obtém: disponibilidade em tempo real, curvas de tempo de resposta, eventos históricos, badges de disponibilidade, domínio personalizado, notificações automáticas, tudo sem servidor, sem mensalidade. O custo é manter o repositório público, e ocasionalmente verificar o tamanho do repositório. Na verdade, esse custo em comparação com criar um monitoramento do zero, já é muito mais leve.

A razão pela qual esse esquema funciona é a generosidade do ecossistema GitHub em subsidiar projetos open source. Se você também mantém uma pequena matriz de produtos multi-sites, recomendo fortemente gastar uma tarde para configurar, muito menos preocupante do que criar monitoramento do zero.

Referências

• Repositório oficial do Upptime
• Documentação de badges de endpoint do shields.io
• Documentação de tarefas agendadas do GitHub Actions
• Exemplo de página de status do HagiCode

Conclusão

Em torno de “como usar Upptime para criar sua própria página de status gratuitamente”, a forma mais sólida de avançar é primeiro fazer funcionar gradualmente as configurações-chave, limites de dependências e caminhos de implementação, depois complementar os detalhes de otimização.

Quando os objetivos, passos e pontos de aceitação estão claros, esse tipo de esquema geralmente pode entrar em entrega real com mais fluidez.

Tradução por IA

Esta página foi traduzida do original em chinês simplificado com ajuda de IA.

Consulte o original se precisar confirmar a redação, nuances técnicas ou as atualizações mais recentes.

Ver original em chinês simplificado

Tags:

• Upptime
• GitHub Actions
• monitoramento de status
• página de status
• GitHub Pages
• HagiCode
• DevOps

Como publicar aplicativos Electron na Microsoft Store: do empacotamento MSIX ao envio

Como Electron chama APIs nativas do Windows