Logs de runtime para agentes IA: Vercel, Workers, Railway y Docker

El healthcheck te dice si el proceso vive. No te dice por qué el webhook devolvió 500 ni qué prompt se mandó. Eso son logs de runtime: stdout/stderr del agente, capturados por la plataforma. La observabilidad cubre traces y evals; esta guía cubre el tubo más tonto y más útil el primer día en producción. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

Qué loguear (y qué no)

Loguea:

• Request id, ruta, status, duración.
• Tool llamada (nombre, no argumentos con secretos).
• Error del SDK sanitizado (sin header Authorization).

No loguees:

• API keys, tokens, CRON_SECRET.
• El prompt completo si trae datos de clientes.
• El entorno (printenv, JSON.stringify(process.env)).

Si se filtró, rota primero — secretos — y corta el logger después.

Dónde se ven, por plataforma

Plataforma	Cómo se capturan	Cómo se ven	Retención / trampa
Vercel Runtime Logs	stdout de la Function	Dashboard → Logs; vercel logs	Hobby 1 hora; Pro 1 día; Observability Plus 30 días
Cloudflare Workers	console.log + errores	Dashboard y wrangler tail	En tráfico alto, real-time entra en sampling: algunos mensajes se descartan
Railway	stdout/stderr de build y deploy	Panel del deployment, Log Explorer, railway logs	Hobby/Trial 7 días; Pro 30 días; Enterprise hasta 90
Docker / VPS	driver json-file (default)	docker compose logs -f	Sin rotación por defecto; max-size/max-file o driver local
Fly.io	stdout de la Machine	fly logs (live tail); Grafana search	Live tail en vivo; búsqueda en Grafana 7 días

Vercel: el dato que más duele

Hobby guarda una hora. Si el agente falla a las 3 AM y lo miras a las 9, ya no está. Para un agente de clientes, Pro (1 día) es el mínimo serio; 30 días pide Observability Plus. No diseñes el postmortem asumiendo que Hobby guarda la noche.

Workers: tail y sampling

Desde el directorio del Worker:

pnpm wrangler tail

Cloudflare documenta que en aplicaciones de mucho tráfico los real-time logs pueden entrar en modo sampling: algunos mensajes no aparecen. Un error intermitente que “no está en el tail” puede estar muestreado, no ausente. Para volumen serio, Workers Logs / Logpush — no el tail del laptop.

Railway y Docker

Railway: console.log llega a tres sitios (deployment, Observability, CLI). Útil el panel cuando el deploy nuevo crashea al arrancar; útil el Explorer cuando el fallo es “en algún servicio del entorno”. La retención oficial es 7 días en Hobby/Trial y 30 días en Pro (Enterprise hasta 90). Subir de plan restaura logs que habían caducado.

Docker: docker compose logs -f agente. El driver por defecto (json-file) escribe a disco sin rotación. Sin max-size/max-file (ejemplo documentado: 10m × 3 archivos) o el driver local, un agente chatty llena el VPS y tumba el propio agente.

Fly: fly logs es live tail. La búsqueda en Grafana retiene 7 días. Más atrás exige exportar (Log Shipper). No diseñes el postmortem sobre fly logs abierto a las 9 AM.

Errores comunes

Síntoma	Causa típica	Fix
“No hay logs” en Vercel Hobby	Pasó más de 1 h	Sube de plan o exporta a un sink el mismo día
Tail de Workers “se come” errores	Sampling en tráfico alto	No depures incidentes solo con tail
Secretos en Runtime Logs	console.log(err) del SDK	Sanitiza; rota la llave
Disco del VPS al 100%	docker logs sin rotación	Driver json-file con max-size o menos log
Logs de Preview mezclados con Prod	Mismo proyecto, mal filtro	Filtra por entorno / deployment

Relación con el resto

• ¿El proceso vive? Healthchecks.
• ¿El agente acierta? Observabilidad.
• ¿El pipeline despliega basura? CI/CD.

Los logs no reemplazan evals. Evitan adivinar el 500.

Un patrón útil el primer día: deja wrangler tail o railway logs abierto mientras mandas un webhook de prueba. Si no sale nada, el request no llegó al proceso (DNS, cron secret, bind). Si sale el stack, el host está bien y el bug es del agente. Esa bifurcación ahorra una hora de “¿será la plataforma?”.

Checklist

• Logger sin secretos ni prompts de clientes
• Sabes la retención real de tu plan (Hobby = 1 h en Vercel)
• Comando de tail documentado (wrangler tail / railway logs / docker compose logs -f)
• En Docker, rotación de logs configurada
• Preview y Production no se leen mezclados

Cuándo NO basta el log de la plataforma

• El incidente fue hace más de 1 h en Vercel Hobby: el dato ya no está. Exporta a un sink (Better Stack, Axiom, un archivo en el VPS) el mismo día que el agente atiende clientes.
• Necesitas correlacionar un request con el prompt y las tools: eso es traza, no log. Ve a observabilidad.
• El Worker está en sampling y el error es 1 en 10,000: wrangler tail no es la herramienta. Workers Logs o Logpush.

El log de plataforma es el botiquín. El sink es el archivo clínico. No construyas el segundo el día 1; constrúyelo el día que Hobby te deje sin evidencia. Hasta entonces, un console.error con request id y nombre de tool cubre el 90% de los incidentes de un agente de un solo inquilino.

---

Siguiente paso: si el 500 ya se ve en logs y el proceso está healthy, el problema es del agente, no del host — vuelve a observabilidad. Si todavía no tienes runtime, el curso gratuito deja un agente local para practicar qué se imprime y qué no.