Métricas Técnicas que Todo CTO de SaaS Deve Monitorar

Por que métricas técnicas importam além do produto

MRR, churn e NPS são métricas de resultado. Métricas técnicas são métricas de processo — elas dizem se você está construindo o caminho certo para os resultados que quer.

Um CTO que só olha métricas de produto vai ser surpreendido por degradação de performance, queda de velocidade de desenvolvimento ou acúmulo silencioso de dívida técnica. Métricas técnicas são o sistema imunológico do produto.

Grupo 1: DORA Metrics (velocidade de entrega)

As DORA Metrics (criadas pelo DevOps Research and Assessment) são o padrão de mercado para medir maturidade de engenharia:

Deployment Frequency (frequência de deploy)

Com que frequência você coloca código em produção?

| Classificação | Frequência | |---|---| | Elite | Múltiplas vezes por dia | | High | Uma vez por dia a uma vez por semana | | Medium | Uma vez por semana a uma vez por mês | | Low | Menos de uma vez por mês |

SaaS competitivos miram Elite ou High. Se você faz deploy menos de uma vez por semana, a velocidade de iteração está comprometida.

Como melhorar: feature flags para separar deploy de release, testes automatizados para dar confiança, pipeline de CI/CD rápido (< 10 minutos).

Lead Time for Changes (tempo de ciclo)

Quanto tempo leva desde o primeiro commit até o código estar em produção?

| Classificação | Tempo | |---|---| | Elite | < 1 hora | | High | 1 dia a 1 semana | | Medium | 1 semana a 1 mês | | Low | > 1 mês |

Lead time alto indica: pull requests grandes que demoram para revisar, pipeline de CI lento, processo de aprovação burocrático, ou medo de deploy.

Change Failure Rate (taxa de falhas)

Qual percentual de deploys resulta em incidente ou rollback?

| Classificação | Taxa | |---|---| | Elite | 0–5% | | High | 5–10% | | Medium | 10–15% | | Low | > 15% |

Taxa alta indica: falta de testes, staging que não representa produção, ou scope de mudança muito grande por deploy.

Mean Time to Restore (tempo de recuperação)

Quando um incidente acontece, quanto tempo leva para restaurar o serviço?

| Classificação | Tempo | |---|---| | Elite | < 1 hora | | High | < 1 dia | | Medium | 1 dia a 1 semana | | Low | > 1 semana |

Melhora com: runbooks documentados, alertas que chegam antes do cliente reclamar, capacidade de rollback rápido.

Grupo 2: Métricas de infraestrutura (saúde do sistema)

Uptime / Availability

99.9% = 8.7 horas de downtime/ano. 99.95% = 4.4 horas. 99.99% = 52 minutos.

Para SaaS B2B com clientes enterprise, 99.9% é o mínimo esperado. Meça por serviço crítico, não pelo sistema inteiro.

Ferramentas: Better Uptime, StatusPage, AWS CloudWatch Synthetics.

P95 e P99 de latência

Média de latência esconde o problema. O usuário no P99 — 1% pior dos requests — é frequentemente o usuário com mais dados, ou num horário de pico, ou num plano enterprise que mais importa.

Targets típicos para SaaS B2B:

API routes principais: P95 < 300ms, P99 < 800ms
Dashboard / listagens: P95 < 500ms
Exports / relatórios: podem ser assíncronos

Taxa de erros por endpoint

Monitore separadamente:

5xx: bugs do servidor, banco fora do ar, memória esgotada — sempre ruim
4xx: erros do cliente — 429 (rate limit) e 422 (validação) são normais; pico de 401/403 pode indicar ataque

Alerta: taxa de 5xx > 0.5% em qualquer endpoint crítico.

Uso de recursos por serviço

CPU: alerta em > 80% por 5 minutos
Memória: alerta em > 85%
Conexões ao banco: alerta em > 80% do pool
Disk (RDS): alerta em > 80%

Grupo 3: Métricas de qualidade de código

Cobertura de testes (nos caminhos críticos)

100% de cobertura é inatingível e desnecessário. O que importa é cobertura nos fluxos que mais afetam o negócio:

Fluxo de pagamento: > 90%
Autenticação e autorização: > 90%
Core do produto (o que os usuários mais usam): > 80%
Utilitários e helpers: 60–70% é suficiente

Sinal de alerta: cobertura caindo sprint após sprint — indica que features novas chegam sem testes.

Tempo de build/CI

Se o pipeline de CI leva > 15 minutos, desenvolvedores vão parar de esperar e fazer merges sem feedback completo.

Target: < 10 minutos para o CI completo. Use paralelização e cache de dependências.

Número de dependências desatualizadas (com vulnerabilidades)

Dependabot ou Snyk reportam dependências com CVEs. O que monitorar:

Critical CVEs: zero tolerância, patch em < 7 dias
High CVEs: patch em < 30 dias
Medium/Low: backlog normal, patch em próxima janela de manutenção

Grupo 4: Métricas de produtividade do time

Cycle time de pull requests

Quanto tempo um PR fica aberto antes de ser mergeado?

Target: < 24 horas para PRs normais (não grandes features). PRs que ficam abertos por dias são sinal de: escopo grande demais, falta de processo de review, ou contexto insuficiente na descrição.

Distribuição de tamanho de PRs

PRs grandes (> 400 linhas de mudança) são difíceis de revisar bem. Incentive PRs menores e mais frequentes.

Como medir: git log --shortstat | grep -E "files? changed" ou dashboard no GitHub/GitLab.

Bugs em produção por sprint

Quantos bugs chegam em produção por sprint? Se o número sobe consistentemente, é sinal de que o pace de desenvolvimento está superando a capacidade de garantia de qualidade.

Dashboard mínimo para o CTO

Se você vai começar a medir agora, priorize:

Semanal (reunião de engenharia):
  ✓ Deployment frequency desta semana
  ✓ Incidentes e MTTRs
  ✓ Taxa de erros 5xx (médias e picos)

Mensal (revisão técnica):
  ✓ Lead time tendência (subindo ou descendo?)
  ✓ Change failure rate
  ✓ Cobertura de testes (tendência)
  ✓ CVEs pendentes
  ✓ Custo de infra vs. mês anterior

Trimestral:
  ✓ DORA score geral (classificação Elite/High/Medium/Low)
  ✓ Technical debt backlog (estimativa de esforço acumulado)
  ✓ Capacidade do time vs. roadmap planejado

Quer implementar observabilidade e métricas de engenharia no seu SaaS? A Codevops configura dashboards e alertas como parte da infraestrutura cloud ou como projeto dedicado.

Solicitar configuração de observabilidade → · Infraestrutura cloud AWS para SaaS → · Technical debt: como gerenciar →