Como adicionar observabilidade no seu SaaS sem montar um Datadog

SaaS pequeno não precisa de APM, dezena de dashboard e um time de SRE pra saber se o produto está de pé. Precisa de três coisas no primeiro dia: alguém batendo de fora na URL crítica, alguém sabendo se o job de madrugada rodou, e um alerta que chega na pessoa certa. O resto é vaidade.

Datadog, Grafana e New Relic são ferramentas sérias. O GetMonitor existe pra outro recorte: time SaaS sem SRE dedicado, que quer ir do alerta à resolução sem trocar de contexto a cada cinco minutos.

O que monitorar no primeiro dia

Não comece pelo cluster. Comece pelo caminho do dinheiro e pelo que o cliente vê.

• A homepage e o app logado, com HTTP 200 de verdade, não só DNS no ar
• A rota de health da API, de preferência /health ou /status
• O checkout, a criação de cobrança ou o webhook que confirma pagamento
• O job que manda e-mail, PIX ou relatório
• O certificado SSL do domínio, porque certificado vencido derruba HTTPS sem recado

Se você só pode criar três monitores hoje, escolha site, API de health e o job que ninguém lembra. Uptime de URL não vê cron parado. Homepage verde com worker morto é mentira que o cliente descobre antes de você.

Tudo que o usuário abre no browser entra na lista de uptime. Tudo que só a máquina deveria ter executado entra na lista de heartbeat. Postgres, Redis e fila não precisam de monitor isolado no dia um se o /health já falhar quando eles caírem. Se o health continua 200 com o banco morto, conserte o endpoint antes de abrir mais ferramenta.

Uptime de fora, heartbeat de dentro

Uptime é o check externo. O GetMonitor bate na sua URL a partir de São Paulo, Virginia ou Frankfurt. Pra um SaaS brasileiro isso importa: queda só nos Estados Unidos é um problema, queda em São Paulo é o cliente ligando no WhatsApp.

No console você cria o monitor com nome claro, URL completa (com https://), tipo de check, código HTTP esperado, timeout e quantas falhas seguidas disparam alerta. A documentação recomenda timeout de 30 segundos e 3 ou 4 retries na maioria dos serviços. API crítica aguenta timeout menor. Site de marketing aguenta mais. Comece no meio e ajuste depois de ver o tempo real na tela de estatísticas.

Dois tipos de check HTTP valem o primeiro setup:

• Monitor de uptime: o endpoint responde e está acessível
• Check de conteúdo: além de responder, o corpo tem o que você espera

Use o check de conteúdo quando um 200 vazio ainda conta como "no ar". Health que devolve {"ok":true} é o caso clássico: se a chave sumiu, o status code pode continuar 200.

Heartbeat é o inverso. Seu processo precisa se apresentar. Job de fatura, worker de fila, backup. Se o ping não chega no intervalo, o monitor marca falha. No GetMonitor os heartbeats ficam numa seção própria, pensados pra tarefa agendada e job de fundo. O intervalo vai de 1 minuto a 7 dias, com grace period de até uma hora pra não acordar o time por atraso de rede.

A regra prática:

• Se o cliente acessa no browser, é uptime
• Se só a máquina deveria ter rodado, é heartbeat
• Se a dependência cair e o health continuar verde, o health está errado, não o monitor

O plano Professional cobre HTTP, heartbeat, monitor de banco e checagem de SSL ou domínio, com até 50 monitores e verificação a cada 2 minutos em 3 regiões. Tem trial de 30 dias. Business sobe o intervalo para 1 minuto, 10 regiões e monitores ilimitados. Você não precisa disso no dia um. Precisa dos três checks certos e de um canal que alguém leia de madrugada.

Como montar o básico no GetMonitor

Passo a passo curto.

• Entre em console.getmonitor.io. Dá pra entrar com magic link, GitHub ou Google. A documentação diz que dá pra começar sem cartão.
• No onboarding, informe a empresa e a primeira URL. O produto cria o primeiro monitor nessa hora.
• Abra Monitores e clique em Adicionar monitor ou + New.
• Nomeie como o time fala no Slack: "API produção /health", não "Monitor 1".
• Cole a URL completa. Prefira o health check se a homepage pode ficar no ar com a API morta.
• Código esperado: 200 na maioria dos casos. Só mude se o endpoint devolve 204 de propósito.
• Timeout de 30 segundos e sensitividade de alerta em 3 retries.
• Espere alguns minutos e abra Statistics. Confirme status Operational, tempo de resposta e código real. Se já veio Down, o problema é URL, redirect ou timeout.
• Repita para o app, o checkout e o que recebe pagamento.
• Em Heartbeats, crie um monitor para cada cron importante. Coloque o ping no final do job, depois do trabalho de verdade. Job que avisa e depois falha é falso positivo invertido.

Redirect merece um minuto. Se http redireciona para https e o follow redirects está desligado, o check pode falhar com 301. Ligue o follow quando você quer o destino final. Desligue quando o próprio redirect é o que você está testando.

Depois do check verde, o monitor ainda não serve de nada se o alerta for um e-mail que ninguém abre.

Alerta que chega em quem está de plantão

Abra o monitor, vá em Alerts, clique em Add Integration. Comece por e-mail. Aí acrescente o canal onde o time já vive.

Canais que o produto lista hoje: e-mail, SMS, Slack, webhook, Microsoft Teams, Discord e Telegram. Na home, WhatsApp também entra como destino, junto de plantão e status page. Datadog, Grafana, Sentry, Prometheus, New Relic e webhooks entram. Não precisa jogar o stack antigo fora. A própria home diz: seu stack continua o mesmo.

Comportamento esperado:

• Alerta quando o monitor vai de Operational para Down, depois das falhas consecutivas
• Alerta de recovery no primeiro check que volta
• Estado Degraded quando há falha parcial ou tempo estourado

Pra serviço que recebe dinheiro, e-mail sozinho é fraco. Some Slack e, se o on-call for real, SMS. Paging por voz existe no plano Business. Escala de plantão, política de escalonamento e confirmação de alerta existem no produto. On-call é add-on, R$25 por usuário por mês na tabela em reais. Se vocês são duas pessoas e o grupo do WhatsApp já é o plantão, não compre paging no primeiro dia. Configure o canal e um responsável.

Runbook, checklist e linha do tempo do incidente moram no mesmo produto. A promessa da home é detectar, entender, acionar, organizar, comunicar e aprender sem pular de ferramenta. AI SRE, no plano Business e ainda em beta, resume o contexto. Mudança só com aprovação humana. Útil depois. Não é o setup de hoje.

Se o alerta dispara demais, não desligue o monitor. Suba a sensitividade (mais retries) e confira timeout. Check hipersensível em endpoint lento vira ruído, e ruído é o jeito mais rápido de o time silenciar o canal.

Status page e o que vem na sequência

Quando o check e o alerta existem, o próximo buraco é o cliente descobrindo a queda no Twitter. Status page pública no GetMonitor liga o monitor a um componente, mostra uptime, incidente e manutenção, aceita inscritos e domínio próprio. Professional inclui até 5 páginas públicas.

Coloque o link no rodapé do app e na docs da API. Durante incidente, atualize a página antes de responder ticket. Silêncio custa mais que downtime curto. A página pública mostra banner de status, componente com badge, histórico visual e inscrição por e-mail ou Slack.

Ordem que funciona:

• Semana 1: uptime das URLs críticas, heartbeat dos crons, alerta no canal do time
• Semana 2: status page com os mesmos componentes, SSL e o health que enxerga o banco
• Quando o volume de incidente crescer: plantão, runbook, correlação. Aí sim Business e AI SRE entram na conversa

Não monte um Datadog no primeiro dia. Monte o recorte que te acorda quando o checkout para e quando o cron de madrugada some. O GetMonitor cabe exatamente nesse recorte: uptime, heartbeat, alerta e status page no mesmo produto, com check saindo de São Paulo.

O GetMonitor já ocupou o mapa do Os 27. Quem quiser ver a ocupação passa no histórico ou volta ao mapa.