Monitoramento de SaaS para fundador solo: a stack de R$ 54/mês que pegou uma falha às 2h47 e a resolveu em 90 segundos — com dois cliques, sem código.
Um fundador solo precisa de exatamente quatro monitores — rastreamento de erros, analytics, desempenho e logs do banco de dados —, mais cinco regras de alerta e um rollback de um clique. Custo total: R$ 54 por mês. Essa combinação é o que permite a uma pessoa tocar um SaaS em produção, publicar de 10 a 15 vezes por semana e ainda dormir à noite. Sem equipe de operações.
Aqui está a configuração, e a história das 2h47 da manhã que prova por que você a quer antes de precisar dela.
O deploy que quebrou às 2h47
2h47 da manhã. Meu celular vibra. Um alerta do meu rastreador de erros: "Pico na taxa de erros em produção."
Meio dormindo, abro o painel. Erros 500. Um endpoint da API falhando. Usuários reais afetados. Tenho duas opções: depurar às 2 da manhã, meio dormindo — ou voltar para a versão anterior, o que leva dois cliques.
Escolhi o rollback. Resolvido em 90 segundos. De volta para a cama. De manhã, descansado, depurei o problema direito, encontrei o bug, corrigi e publiquei de novo. Tempo total fora do ar: 90 segundos. Sono total perdido: 3 minutos.
Antes de eu ter rollbacks, essa noite teria sido diferente: duas horas de depuração com os olhos embaçados, seguidas de um dia seguinte inútil. A lição não é que as coisas quebram — sempre vão quebrar. É que a resposta pode ser uma rotina em vez de uma crise.
A stack de monitoramento (e quanto custa)
Monitoramento parece coisa de grande empresa, mas a versão solo são quatro ferramentas gratuitas ou baratas, cada uma vigiando uma camada diferente do seu produto:
| Ferramenta | O que vigia | Custo |
|---|---|---|
| Sentry | Erros — no app e na API, com a linha exata que falhou; alerta em picos | Grátis até 5 mil erros/mês |
| Plausible | Tráfego — visualizações de página, fluxos de usuários, origens; uma queda repentina significa páginas quebradas | R$ 54/mês |
| Cloudflare Analytics | Desempenho — tempos de resposta, taxas de erro, onde estão seus usuários | Grátis com a hospedagem |
| Logs do Supabase | Banco de dados — consultas lentas, consultas com falha, acessos negados | Grátis com o banco de dados |
Essa é a conta inteira: R$ 54 por mês. Todo o resto vai nos planos gratuitos. Por menos que uma assinatura da Netflix, você fica sabendo dos problemas antes que seus clientes mandem e-mail sobre eles.
Repare no que não está na lista: nenhuma plataforma corporativa de observabilidade, nenhuma escala de plantão, nenhuma tela de painéis brilhando na parede. A escala de plantão é você. A única função das ferramentas é garantir que você seja interrompido quando algo é real — e nunca quando não é.
As cinco regras de alerta que importam
Painéis são inúteis se você precisa se lembrar de olhar para eles. O sistema tem que te interromper — mas só quando importa. Eu recebo alerta quando:
- A taxa de erros passa de 5% — algo está quebrado
- O tempo de resposta passa de 2 segundos — um problema de desempenho está se formando
- O tráfego cai mais de 50% — as páginas não estão carregando
- As consultas ao banco de dados começam a falhar — a camada de dados está com problemas
- Os logins com falha disparam — possível problema de segurança
Cinco regras. Qualquer coisa abaixo desses limites espera a manhã. Os alertas me acordam — mas os rollbacks me deixam voltar a dormir.
Rollback: seu botão de desfazer de 90 segundos
Fazer rollback significa colocar de volta no ar a versão anterior que funcionava do seu app. A hospedagem moderna guarda todos os deploys que você já fez, então desfazer um deploy ruim é de fato só uma questão de cliques: abra o painel, encontre o deploy anterior, escolha "fazer rollback para este deploy". Pronto em uns 30 segundos. Sem código, sem terminal, sem pânico.
Aquele momento das duas opções às 2h47 é a filosofia inteira em miniatura: restaure primeiro, entenda depois. Seus usuários não se importam com por que quebrou — se importam que volte a funcionar. Depurar é trabalho diurno; rollback é o turno da noite.
Mudanças no banco de dados são a única exceção — não dá para desfazê-las com a mesma facilidade. Por isso as mudanças no banco de dados são testadas antes num ambiente de staging, e por isso existem backups: se uma mudança der muito errado, você restaura o backup feito antes dela.
A última rede de segurança é um health check: um endpoint minúsculo no seu app que confirma que o banco de dados e o sistema de login estão respondendo. A plataforma de hospedagem o consulta a cada 5 minutos. Se ele falhar 3 vezes seguidas, eu recebo um alerta e o sistema faz rollback automaticamente — às vezes a correção acontece antes de eu pegar o celular.
Por que isso permite publicar de 10 a 15 vezes por semana
Esta é a parte contraintuitiva: essa rede de segurança não é para publicar com menos cuidado. É o que torna seguro publicar com frequência. Eu faço deploy de 10 a 15 vezes por semana. A maioria dos deploys é perfeita — monitorada, confirmada, pronta. De vez em quando, talvez 1 em 50, algo quebra. O monitoramento me avisa na hora. Um rollback resolve em 90 segundos. Depois eu depuro direito, corrijo o problema real e publico de novo.
Deploys frequentes mais bom monitoramento mais rollbacks fáceis é igual a publicar com confiança. Se fazer deploy ainda parece um salto de fé, comece por faça deploy sem medo — a stack de monitoramento daqui é a segunda metade dessa equação. E se você ainda está decidindo o que construir, o framework BUILD coloca este passo em contexto: monitoramento é o que você adiciona na semana em que chegam usuários reais, não antes.
Perguntas frequentes
Que monitoramento um fundador solo realmente precisa?
Quatro camadas: rastreamento de erros (Sentry), analytics de tráfego (Plausible), métricas de desempenho (Cloudflare) e logs do banco de dados (Supabase). Cada uma pega um tipo de falha que as outras deixam passar. Juntas custam R$ 54 por mês — tudo, exceto o Plausible, cabe nos planos gratuitos.
Como consertar um deploy quebrado sem equipe de operações?
Faça rollback primeiro, depure depois. A hospedagem moderna guarda os deploys anteriores, então restaurar a última versão que funcionava leva uns 30 segundos num painel. Nunca depure em produção às 2 da manhã — restaure o serviço em segundos e encontre o bug real na manhã seguinte, com a cabeça descansada.
Que alertas devo configurar para o meu SaaS?
Cinco regras cobrem quase tudo: taxa de erros acima de 5%, tempo de resposta acima de 2 segundos, tráfego caindo mais de 50%, consultas ao banco de dados falhando e um pico de logins com falha. Qualquer coisa mais granular vira ruído, e alertas barulhentos são ignorados — o que derrota o propósito.
Fazer deploy de 10 a 15 vezes por semana não é arriscado?
É o contrário. Deploys pequenos e frequentes significam que cada mudança é minúscula e fácil de desfazer; lançamentos grandes e raros fazem de cada deploy um evento de alto risco. Com monitoramento e rollbacks de um clique, o deploy que quebra, cerca de 1 em 50, custa 90 segundos fora do ar, não uma noite perdida.