Desplegaste tu app Next.js en Vercel. Algo esta roto. Tu primer instinto: revisar los logs. Vercel tiene logging, pero cuando empezas a depender de el en produccion, rapidamente descubris lo que puede y no puede hacer.
Como funciona el logging de Vercel
Vercel provee tres tipos de logs: build logs (salida de next build), runtime logs (logs de tus API routes y SSR), y edge function logs (middleware). Los runtime logs muestran cualquier console.log o console.error de tu codigo server-side.
Accediendo a los logs
Via el dashboard (proyecto > Logs), via CLI (vercel logs --follow), o via la API REST. Podes filtrar por nivel, fuente, status code, path y rango de tiempo.
Log Drains
Los log drains reenvian tus logs a un servicio externo en tiempo real: Datadog, Axiom, Logflare o un webhook generico. Disponibles en planes Pro y Enterprise. Resuelven la retencion pero requieren configurar dashboards y alertas en la herramienta externa.
Limitaciones del logging de Vercel
- Retencion demasiado corta: 1 hora en Hobby, 1 dia en Pro, 3 dias en Enterprise.
- Sin alertas: No hay forma de recibir notificaciones cuando un endpoint falla.
- Sin metricas por ruta: No podes ver P95 response time o error rate por endpoint.
- Sin tendencias historicas: No podes comparar el rendimiento de esta semana con la anterior.
Complementando con monitoreo
No necesitas reemplazar los logs de Vercel. Necesitas una capa complementaria que observe el agregado y te alerte proactivamente.
Hay dos caminos comunes: en Pro o Enterprise, un log drain que mande los logs a un servicio como Datadog o Axiom, donde configurás dashboards y alertas; o, en cualquier plan, instrumentar la app con OpenTelemetry desde instrumentation.ts. En los dos casos, apuntá a tener latencia P50/P95/P99 y tasa de errores por API route, alertas por Slack o email, un check de uptime externo y datos históricos más allá de la retención de Vercel.