Monitoramento e métricas pós-lançamento: do uptime ao NPS em tempo real

Dashboard completo de métricas: uptime, performance, conversão, churn e NPS. Ferramentas, alertas e como reagir a cada métrica crítica.

Produto no ar sem monitoramento = dirigir vendado.

A maioria dos fundadores investe semanas ou meses construindo um produto, valida hipóteses, faz testes com early adopters e finalmente coloca tudo no ar. Mas no momento mais crítico — o pós-lançamento — opera no escuro. Sem dados concretos, decisões viram achismo. Você não sabe se o sistema está lento, se usuários abandonam no onboarding, se a taxa de erro subiu depois do último deploy. Monitoramento pós-lançamento não é um “nice to have” de empresa grande. É a diferença entre corrigir um problema em 10 minutos e descobrir três semanas depois que metade da base desistiu.

Realidade: 60% das PMEs lançam produto e não monitoram nenhuma métrica além de “quantos cadastros teve hoje”.

Resultado: Descobrem problemas quando 40% dos usuários já churned.

O que deveria monitorar (mínimo obrigatório):

  1. Uptime (sistema está no ar?)
  2. Performance (P95 latency, error rate)
  3. Conversão (cadastros, ativações, pagamentos)
  4. Retenção (DAU, churn, cohorts)
  5. Satisfação (NPS, feedback)

Este artigo mostra dashboard completo de métricas pós-lançamento — ferramentas, alertas automáticos e como reagir a cada sinal de alerta.

As 4 categorias de métricas

Para não se perder em dezenas de números, organizamos as métricas em 4 categorias que seguem uma lógica de pirâmide. A base é a infraestrutura: se o sistema está fora do ar ou lento, nada mais importa. Acima vem o produto: se está no ar mas ninguém usa, o problema é outro. Depois vem o negócio: usuários ativos que não geram receita não pagam as contas. E no topo, satisfação: se o cliente paga mas está insatisfeito, o churn é questão de tempo. Cada categoria depende da anterior. Não adianta medir NPS se você nem sabe que o sistema ficou 2 horas offline ontem. Comece de baixo para cima.

1. Métricas de infra (produto funciona?)

Uptime (disponibilidade):

  • Meta: maior que 99,5% (máximo 3,6h de downtime/mês)
  • Ferramenta: Better Uptime, Pingdom
  • Alerta: Se maior que 2min offline

Error rate:

  • Meta: menor que 0,5% (menos de 1 erro a cada 200 requests)
  • Ferramenta: Sentry
  • Alerta: Se maior que 2% em 5min

Latency P95:

  • Meta: menor que 500ms (95% das requests levam menor que 500ms)
  • Ferramenta: Datadog, New Relic
  • Alerta: Se maior que 1s

Com a infraestrutura monitorada, você tem a garantia básica de que o produto está acessível e respondendo em tempo aceitável. Mas estar no ar não significa estar funcionando para o usuário. O próximo passo é entender se as pessoas que chegam ao seu produto realmente o utilizam, completam o fluxo principal e voltam no dia seguinte.

2. Métricas de produto (usuários usam?)

DAU/MAU (Daily/Monthly Active Users):

  • Meta: maior que 20% (20% dos usuários mensais voltam todo dia)
  • Ferramenta: Mixpanel, Amplitude
  • Alerta: Se menor que 15%

Taxa de ativação:

  • Meta: maior que 40% (40% completam onboarding)
  • Ferramenta: Mixpanel
  • Alerta: Se menor que 30%

Retention (retenção):

  • Meta Semana 1: maior que 70%
  • Meta Semana 4: maior que 40%
  • Ferramenta: Mixpanel (cohorts)

Usuários ativos e engajados são um ótimo sinal, mas por si só não sustentam a operação. O próximo nível de monitoramento conecta comportamento de uso a resultado financeiro. Aqui você descobre se o produto que funciona bem e que as pessoas usam também consegue se pagar — e gerar margem para crescer.

3. Métricas de negócio (gera receita?)

MRR (Monthly Recurring Revenue):

  • Crescimento: maior que 15%/mês
  • Ferramenta: Stripe Dashboard + ChartMogul

Churn (cancelamentos):

  • Meta: menor que 5%/mês
  • Alerta: Se maior que 8%

LTV/CAC (Lifetime Value / Customer Acquisition Cost):

  • Meta: maior que 3x
  • Cálculo: (MRR × 1/churn) / CAC

Receita crescente pode mascarar insatisfação. Um cliente pode continuar pagando por inércia, por contrato ou por falta de alternativa — mas estar ativamente procurando um concorrente. Métricas de satisfação funcionam como um termômetro do futuro: se o NPS cai hoje, o churn sobe daqui a 2-3 meses. Medir satisfação regularmente permite agir antes que o cancelamento aconteça.

4. Métricas de satisfação (usuários gostam?)

NPS (Net Promoter Score):

  • Meta: maior que 30 (B2B SaaS)
  • Ferramenta: Typeform, Delighted
  • Frequência: Trimestral

Support tickets:

  • Meta: menor que 5% dos usuários abrem ticket/mês
  • Ferramenta: Intercom, Zendesk

Setup completo de monitoramento

A escolha das ferramentas abaixo segue três critérios: custo zero ou muito baixo para começar (essencial para PMEs e startups early-stage), facilidade de integração com stacks modernas (Next.js, Vercel, AWS) e capacidade de escalar junto com o produto sem exigir migração. Não existe stack perfeita, mas essa combinação cobre os 4 níveis de métricas que discutimos acima e pode ser configurada em menos de um dia por um único desenvolvedor.

1. Uptime: Better Uptime (R$ 0)

# Configuração
Monitors:
  - URL: https://api.exemplo.com/health
    Interval: 30 segundos
    Timeout: 5s
    Expected: 200 OK
    Alertas: Slack #incidents

  - URL: https://exemplo.com
    Interval: 60 segundos
    Keyword: "OrientMe" (verifica se página carrega)

Endpoint de health check:

// app/api/health/route.ts
export async function GET() {
  // Verifica conexões essenciais
  const dbOk = await checkDatabase();
  const redisOk = await checkRedis();

  if (!dbOk || !redisOk) {
    return Response.json({ status: 'unhealthy' }, { status: 503 });
  }

  return Response.json({
    status: 'healthy',
    uptime: process.uptime(),
    timestamp: new Date().toISOString(),
  });
}

2. Erros: Sentry

// sentry.client.config.ts
import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,

  // Filtrar erros irrelevantes
  beforeSend(event) {
    if (event.exception) {
      const error = event.exception.values?.[0];
      // Ignorar erros de extensões do browser
      if (error?.value?.includes('chrome-extension://')) {
        return null;
      }
    }
    return event;
  },
});

Alertas automáticos:

# Sentry Alert Rules
- Condition: error_count mais de 50 in 5 minutes
  Action: Slack #incidents + PagerDuty
  Severity: Critical

- Condition: new_error_detected
  Action: Slack #bugs
  Severity: Low

3. Analytics de produto: Mixpanel

// lib/analytics.ts
import mixpanel from 'mixpanel-browser';

mixpanel.init(process.env.NEXT_PUBLIC_MIXPANEL_TOKEN!);

export function trackEvent(eventName: string, properties?: object) {
  mixpanel.track(eventName, properties);
}

export function identifyUser(userId: string, traits?: object) {
  mixpanel.identify(userId);
  mixpanel.people.set(traits);
}

// Uso
trackEvent('User Signed Up', {
  plan: 'premium',
  source: 'google_ads',
});

identifyUser('user-123', {
  email: 'joao@exemplo.com',
  createdAt: new Date(),
});

Events obrigatórios:

// Lifecycle
trackEvent('User Signed Up');
trackEvent('User Activated'); // Completou onboarding
trackEvent('User Converted'); // Primeiro pagamento

// Feature usage
trackEvent('Feature Used', { featureName: 'agendamento' });
trackEvent('Search Performed', { query: 'manicure' });
trackEvent('Booking Created', { professionalId: '123' });

// Revenue
trackEvent('Payment Successful', { amount: 199, plan: 'premium' });
trackEvent('Subscription Cancelled', { reason: 'price' });

Dashboard executivo (CEO/founder)

Métricas diárias:

=== CRESCIMENTO ===
Novos usuários (hoje): 47 (+12% vs ontem)
MRR: R$ 34.500 (+8% vs mês passado)
Churn (mês atual): 4,2% ✅

=== SAÚDE ===
Uptime (7 dias): 99,97% ✅
Error rate: 0,3% ✅
NPS (último trimestre): 42 ✅

=== PIPELINE ===
Leads (semana): 320
Conversão lead→cliente: 8,2%
CAC: R$ 180
LTV/CAC: 12,3x ✅

Ferramenta: Databox, Geckoboard (conecta com Stripe, Mixpanel, Google Analytics).

O dashboard executivo não é só um painel bonito para mostrar para investidor. Ele deve ser o primeiro lugar que o fundador ou CEO olha toda manhã, antes de qualquer reunião. A rotina recomendada: 5 minutos por dia revisando os números de crescimento e saúde, 15 minutos por semana analisando tendências e comparando com a semana anterior. Se algo caiu mais de 10% em relação à média, já justifica investigação. Além do fundador, o líder técnico deve acompanhar as métricas de infra e erros, enquanto o responsável por produto foca em ativação e retenção. O importante é que cada métrica tenha um dono — alguém que é responsável por reagir quando o número sai do esperado.

Alertas críticos e ações

1. Uptime menor que 99%

Alerta: Sistema está caindo frequentemente.

Ações:

  • Verificar logs (Sentry, Datadog)
  • Escalar recursos (CPU, memória)
  • Adicionar health checks
  • Implementar auto-scaling

2. Error rate maior que 2%

Alerta: Bugs em produção afetando usuários.

Ações:

  • Identificar erro no Sentry
  • Reproduzir localmente
  • Hotfix (deploy em menor que 2h)
  • Post-mortem (evitar recorrência)

3. Churn maior que 7%/mês

Alerta: Usuários cancelando em massa.

Ações:

  • Entrevistar 10 usuários que cancelaram (por quê?)
  • Analisar cohorts (qual grupo churn mais?)
  • A/B test retenção (e-mails, onboarding)
  • Oferecer desconto para reter (win-back campaign)

4. NPS menor que 20

Alerta: Usuários insatisfeitos.

Ações:

  • Ler todos os comentários do NPS
  • Agrupar reclamações (quais problemas mais citados?)
  • Priorizar top 3 problemas
  • Comunicar melhorias aos usuários

Configurar alertas é só metade do trabalho. A outra metade é construir uma cultura de resposta a incidentes, mesmo em times pequenos. Defina um canal dedicado (como um #incidents no Slack) onde todos os alertas críticos chegam. Estabeleça um protocolo simples: quem está de plantão reconhece o alerta em até 5 minutos, faz o diagnóstico inicial em 15 minutos e comunica o status para o time. Depois que o incidente é resolvido, faça um post-mortem rápido — não precisa ser um documento de 10 páginas, mas registre o que aconteceu, por que aconteceu e o que vai ser feito para evitar que se repita. Essa disciplina transforma erros em aprendizado e reduz drasticamente o tempo de resposta ao longo do tempo.

Custos de monitoramento

Uma preocupação comum é o custo dessas ferramentas, especialmente para quem está começando e cada real conta. A tabela abaixo mostra que é possível começar com custo zero e só investir conforme a base cresce. Compare esses valores com o custo real de um problema não detectado: uma hora de downtime pode significar dezenas de vendas perdidas, usuários frustrados que nunca voltam, e dano à reputação que leva meses para recuperar. Monitoramento não é gasto — é o investimento com melhor ROI que você pode fazer no pós-lançamento.

Ferramenta0-1K usuários1K-10K10K-100K
Better UptimeR$ 0R$ 0R$ 100
SentryR$ 0R$ 120R$ 600
MixpanelR$ 0R$ 0R$ 1.200
DataboxR$ 0R$ 200R$ 400
TOTALR$ 0R$ 320R$ 2.300

Monitorar não é custo, é seguro. Cada hora de downtime custa 10-50x mais que ferramenta de monitoramento.

Conclusão

Não deixe métricas para depois. Configure no dia 1 do lançamento. O monitoramento pós-lançamento é o que separa produtos que crescem de forma sustentável daqueles que apagam incêndio toda semana. Comece pela base da pirâmide — garanta que o sistema está no ar e respondendo rápido. Depois suba para métricas de produto, negócio e satisfação. Não tente monitorar tudo de uma vez: escolha 2-3 métricas por categoria, configure alertas automáticos e revise os números diariamente. Em 30 dias você vai ter mais clareza sobre o seu produto do que a maioria dos fundadores tem em 6 meses. O segredo não é ter o dashboard mais sofisticado — é olhar para os dados todos os dias e agir sobre eles.

Pronto para sair do manual?

Agende o diagnóstico gratuito. Vamos mapear o gargalo, estimar o impacto e definir o primeiro resultado mensurável.

Você sai com clareza — não com um pitch de vendas.