Monitorização de SaaS para fundadores a solo: a minha stack de 9 €/mês
Monitorização de SaaS para fundadores a solo: a stack de 9 €/mês que apanhou uma falha em produção às 2h47 e a resolveu em 90 segundos — com dois cliques, sem código.
Um fundador a solo precisa exatamente de quatro monitores — rastreio de erros, analítica, desempenho e registos da base de dados — mais cinco regras de alerta e uma reversão com um clique. Custo total: 9 € por mês. É essa combinação que permite a uma só pessoa gerir um SaaS em produção, fazer 10 a 15 deploys por semana e ainda dormir à noite. Sem equipa de operações.
Aqui está a configuração, e a história das 2h47 que prova porque é que a queres ter antes de precisares dela.
O deploy que se partiu às 2h47
2h47 da manhã. O telemóvel vibra. Um alerta do meu rastreador de erros: "Pico na taxa de erros em produção."
Meio a dormir, abro o dashboard. Erros 500. Um endpoint da API a falhar. Utilizadores reais afetados. Tenho duas opções: depurar às 2 da manhã, meio a dormir — ou reverter para a versão anterior, o que demora dois cliques.
Escolhi a reversão. Resolvido em 90 segundos. De volta à cama. De manhã, descansado, depurei o problema como deve ser, encontrei o bug, corrigi-o e voltei a fazer o deploy. Tempo total em baixo: 90 segundos. Sono total perdido: 3 minutos.
Antes de ter reversões, essa noite teria sido diferente: duas horas a depurar de olhos inchados, seguidas de um dia seguinte inútil. A lição não é que as coisas se partem — vão sempre partir-se. É que a resposta pode ser uma rotina em vez de uma crise.
A stack de monitorização (e quanto custa)
Monitorização soa a território de grandes empresas, mas a versão a solo são quatro ferramentas gratuitas ou baratas, cada uma a vigiar uma camada diferente do teu produto:
| Ferramenta | O que vigia | Custo |
|---|---|---|
| Sentry | Erros — na 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, percursos dos utilizadores, fontes; uma quebra súbita significa páginas avariadas | 9 €/mês |
| Cloudflare Analytics | Desempenho — tempos de resposta, taxas de erro, onde estão os teus utilizadores | Grátis com o alojamento |
| Registos do Supabase | Base de dados — consultas lentas, consultas falhadas, permissões negadas | Grátis com a base de dados |
É essa a conta toda: 9 € por mês. Tudo o resto vive nos planos gratuitos. Por menos do que uma subscrição da Netflix, ficas a saber dos problemas antes de os teus clientes te enviarem um e-mail sobre eles.
Repara no que não está na lista: nenhuma plataforma empresarial de observabilidade, nenhuma escala de piquete, nenhum ecrã dedicado a dashboards a brilhar na parede. A escala de piquete és tu. O único trabalho das ferramentas é garantir que és interrompido quando algo é real — e nunca quando não é.
As cinco regras de alerta que importam
Os dashboards são inúteis se tiveres de te lembrar de olhar para eles. O sistema tem de te interromper — mas só quando importa. Recebo um alerta quando:
- A taxa de erros passa os 5% — alguma coisa está partida
- O tempo de resposta passa os 2 segundos — está a formar-se um problema de desempenho
- O tráfego cai mais de 50% — as páginas não estão a carregar
- As consultas à base de dados começam a falhar — a camada de dados está em apuros
- Há um pico de inícios de sessão falhados — um possível problema de segurança
Cinco regras. Tudo o que fica abaixo desses limites espera pela manhã. Os alertas acordam-me — mas as reversões deixam-me voltar a dormir.
Reversão: o teu botão de anular de 90 segundos
Uma reversão significa voltar a pôr no ar a versão anterior da tua app que funcionava. O alojamento moderno guarda todos os deploys que alguma vez fizeste, por isso anular um mau é mesmo só uma questão de cliques: abres o dashboard, encontras o deploy anterior, escolhes "reverter para este deploy". Feito em cerca de 30 segundos. Sem código, sem terminal, sem pânico.
Aquele momento das duas opções às 2h47 é a filosofia toda em miniatura: primeiro repõe, depois percebe. Os teus utilizadores não querem saber porque é que se partiu — querem que volte a funcionar. Depurar é trabalho de dia; reverter é o turno da noite.
As alterações à base de dados são a única exceção — não se desfaz o que foi feito com a mesma facilidade. É por isso que as alterações à base de dados são testadas primeiro num ambiente de staging, e é para isso que existem as cópias de segurança: se uma alteração correr mesmo mal, repões a partir da cópia de segurança feita antes dela.
A última rede de segurança é uma verificação de saúde: um endpoint minúsculo na tua app que confirma que a base de dados e o sistema de início de sessão estão a responder. A plataforma de alojamento consulta-o de 5 em 5 minutos. Se falhar 3 vezes seguidas, recebo um alerta e o sistema reverte automaticamente — às vezes a correção acontece antes de eu sequer pegar no telemóvel.
Porque é que isto te deixa fazer 10 a 15 deploys por semana
Aqui está a parte contraintuitiva: esta rede de segurança não serve para lançares com menos cuidado. É o que torna seguro lançar muitas vezes. Faço 10 a 15 deploys por semana. A maioria é perfeita — monitorizada, confirmada, feita. De vez em quando, talvez 1 em cada 50, alguma coisa parte-se. A monitorização diz-me de imediato. Uma reversão resolve em 90 segundos. Depois depuro como deve ser, corrijo o problema real e volto a fazer o deploy.
Deploys frequentes mais boa monitorização mais reversões fáceis é igual a lançar com confiança. Se fazer um deploy ainda te parece um salto de fé, começa por fazer deploy sem medo — a stack de monitorização daqui é a segunda metade dessa equação. E se ainda estás a decidir o que construir, o framework BUILD põe este passo em contexto: a monitorização é o que acrescentas na semana em que chegam utilizadores reais, não antes.
Perguntas frequentes
De que monitorização precisa realmente um fundador a solo?
Quatro camadas: rastreio de erros (Sentry), analítica de tráfego (Plausible), métricas de desempenho (Cloudflare) e registos da base de dados (Supabase). Cada uma apanha uma classe de falhas que as outras não apanham. Juntas custam 9 € por mês — tudo exceto o Plausible cabe nos planos gratuitos.
Como corrijo um deploy avariado sem uma equipa de operações?
Primeiro reverte, depois depura. O alojamento moderno guarda os deploys anteriores, por isso repor a última versão que funcionava demora cerca de 30 segundos num dashboard. Nunca depures em produção às 2 da manhã — repõe o serviço em segundos e encontra o bug real na manhã seguinte, de cabeça fresca.
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 a cair mais de 50%, consultas à base de dados a falhar e um pico de inícios de sessão falhados. Qualquer coisa mais granular passa a ser ruído, e os alertas ruidosos acabam ignorados — o que anula o propósito.
Fazer 10 a 15 deploys por semana não é arriscado?
É o contrário. Deploys pequenos e frequentes significam que cada alteração é minúscula e fácil de anular; lançamentos grandes e raros significam que cada deploy é um acontecimento de alto risco. Com monitorização e reversões com um clique, o deploy que se parte, cerca de 1 em cada 50, custa 90 segundos em baixo, não uma noite perdida.