Voce fez deploy da sua app Next.js na Vercel. Algo esta quebrado. Seu primeiro instinto: verificar os logs. A Vercel tem logging, mas quando voce comeca a depender dele em producao, rapidamente descobre o que ele pode e nao pode fazer.
Como funciona o logging da Vercel
A Vercel fornece tres tipos de logs: build logs (saida do next build), runtime logs (logs das suas API routes e SSR), e edge function logs (middleware). Os runtime logs mostram qualquer console.log ou console.error do seu codigo server-side.
Acessando os logs
Via dashboard (projeto > Logs), via CLI (vercel logs --follow), ou via a API REST. Voce pode filtrar por nivel, fonte, status code, path e intervalo de tempo.
Log Drains
Log drains encaminham seus logs para um servico externo em tempo real: Datadog, Axiom, Logflare ou um webhook generico. Disponiveis nos planos Pro e Enterprise. Resolvem a retencao mas requerem configurar dashboards e alertas na ferramenta externa.
Limitacoes do logging da Vercel
- Retencao muito curta: 1 hora no Hobby, 1 dia no Pro, 3 dias no Enterprise.
- Sem alertas: Nao ha forma de receber notificacoes quando um endpoint falha.
- Sem metricas por rota: Nao e possivel ver P95 response time ou error rate por endpoint.
- Sem tendencias historicas: Nao e possivel comparar o desempenho desta semana com a anterior.
Complementando com monitoramento
Voce nao precisa substituir os logs da Vercel. Precisa de uma camada complementar que observe o agregado e alerte proativamente.
Há dois caminhos comuns: no Pro ou Enterprise, um log drain que envia os logs para um serviço como Datadog ou Axiom, onde você configura dashboards e alertas; ou, em qualquer plano, instrumentar o app com OpenTelemetry via instrumentation.ts. Nos dois casos, busque ter latência P50/P95/P99 e taxa de erros por API route, alertas por Slack ou email, um check de uptime externo e dados históricos além da retenção da Vercel.