📺 El panel de ejecuciones
¿Eres nuevo aquí? Uno panel (o dashboard) es la pantalla donde la plataforma de ejecución muestra todo lo que se ejecutó: cada vez que se activa tu automatización, aparece una línea nueva, con fecha, hora y un estado (éxito o error). Es el «extracto bancario» de tu automatización: no necesitas entender cómo procesa las cosas el banco por dentro, solo sabes leer si la cuenta cerró correctamente.
En el panel de Trigger.dev (la plataforma usada en el módulo 4.6), cada ejecución aparece como una fila en la que puedes hacer clic. Al hacer clic, se abren los detalles, incluido el log, que es el tema del siguiente apartado.
Leyenda: a la izquierda, la lista de ejecuciones con estados de colores. A la derecha, lo que aparece al hacer clic en una ejecución que falló: el log, línea por línea, que muestra exactamente dónde y por qué se detuvo.
📜 Qué es un log, de verdad
¿Eres nuevo aquí? Uno log es la lista de eventos que la automatización fue anotando mientras se ejecutaba, como un diario de navegación. Cada línea registra «lo que pasó» y «a qué hora». No es código: es texto simple, en orden cronológico, que cuenta la historia de lo que la automatización intentó hacer.
No necesitas saber leer TypeScript. Necesitas saber leer el log. Es la frase más importante de este módulo. El log cuenta la historia en portugués (o con mensajes claros), incluso cuando el código detrás es técnico, porque quien escribió la task (Claude Code, siguiendo tus instrucciones) normalmente deja mensajes legibles en cada etapa importante.
💡 Concepto principal
- •Cada línea del registro tiene: hora + lo que ocurrió.
- •Las líneas normales muestran el progreso («buscando...», «enviando...»).
- •Las líneas de error (normalmente resaltadas en rojo o con la palabra «ERRO») indican dónde se trabó.
🔴 Encontrando la línea roja
Cuando una ejecución aparece con estado de error en el panel, el proceso es siempre el mismo: haz clic en ella, abre el log y baja hasta encontrar la primera línea marcada como error. No hace falta leerlo todo con la misma atención: las líneas normales solo confirman que «hasta aquí, todo bien»; lo que importa es dónde cambia el rumbo de la historia.
¿Recuerdas el módulo 4.5? Si la automatización está bien diseñada, con reintentos, verás algunos intentos registrados en el log antes del error final. Es normal y no significa que todo esté roto: significa que el sistema intentó recuperarse por sí solo y esa vez no lo logró.
✓ Lectura eficiente del log
- ✓Va directamente a la primera línea marcada como error
- ✓Lee el mensaje que lo rodea para entender el contexto (qué estaba intentando hacer)
- ✓Copia la línea de error completa, sin resumirla de memoria
✗ Perderse en el registro
- ✗Intenta leer línea por línea desde el inicio, se cansa y se da por vencido
- ✗Ves una palabra técnica y crees que necesitas entender de código para continuar
- ✗Describe el error de memoria a Claude Code, sin pegar el texto exacto
💡 Consejo práctico
La mayoría de los paneles de ejecución tiene un botón «copiar log» o permite seleccionar el texto directamente. Úsalo — copiar el fragmento exacto es mucho más eficaz que intentar resumir el error de memoria.
🤝 Llevar el error de vuelta al agente
¿Encontraste la línea roja? No necesitas descifrarla por tu cuenta. Vuelve a Claude Code, pega el fragmento del log (con contexto de algunas líneas antes y después) y pide una investigación — lee código con naturalidad y te explica el problema en portugués.
Objetivo: pedirle a Claude Code que investigue un fallo real, usando como evidencia el registro copiado del panel, sin que tengas que entender primero el error técnico.
Minha automação "" falhou na execução de
. Colei abaixo o trecho
do log a partir de onde os erros aparecem. Me explique, em português
simples, o que provavelmente deu errado e sugira uma correção. Se for
algo relacionado a uma variável de ambiente/chave de API, me diga qual
delas conferir no painel — sem eu precisar mexer no código.
--- log colado ---
--- fim do log --- Cómo verificar: la respuesta del agente debe señalar una causa probable en lenguaje sencillo (p. ej., "la clave de API parece estar equivocada o vencida" o "el servicio externo tardó más que el tiempo límite") y una acción concreta: corregir el código, registrar una clave de nuevo o aumentar el tiempo de espera. Si la respuesta es vaga, pide: "señala exactamente qué línea del log te llevó a esa conclusión".
⚠️ Atención
Al pegar un log, comprueba antes que no incluya por error una clave de API real: algunos errores de autenticación muestran parte de la clave utilizada. Si aparece, borra ese fragmento antes de pegarlo en cualquier lugar, incluso en una conversación con el agente.
🔄 El hábito de verificación
La observabilidad no es un evento único: es un hábito. Una automatización publicada sin que nadie revise el panel de vez en cuando puede llevar días fallando sin que lo sepas.
La buena noticia: no tienes que revisar todo manualmente cada día. La mayoría de las plataformas permite configurar una alerta (por correo electrónico o mensaje) que avisa automáticamente cuando falla una ejecución. Así, el panel solo requiere tu atención cuando algo realmente lo necesita.
Primera semana: revisa todos los días
Después de publicar una automatización nueva, revisa el panel a diario hasta tener confianza en que está estable.
Después: configura una alerta y relájate
Pídele a Claude Code que configure una alerta automática de fallas; así solo revisas cuando hace falta.
Cuando llegue la alerta: primero los logs, después el código
Sigue el proceso de los puntos 1 a 4 — panel, registro, línea roja, agente.
🏁 Cerrando la Ruta 4
Recorriste todo el camino: entendiste por qué lo local no basta (4.1), el pipeline código → repositorio → nube (4.2), la separación entre pruebas y producción (4.3), cómo proteger secretos (4.4), por qué dividir todo en tareas pequeñas con reintentos (4.5), publicaste una automatización real (4.6) y ahora sabes leer el panel cuando algo falla (4.7).
Este es el conjunto completo de habilidades para que cualquier automatización tuya salga de tu laptop y se convierta en algo que funciona de verdad, por sí solo y con seguridad. La próxima trilha cambia de tema: cómo darle a tu agente la capacidad de ver pantallas y construir interfaces visuales.
🎯 Concepto principal
- •El panel muestra el resultado. El log muestra el historial. No necesitas TypeScript para leer ninguno de los dos.
- •Falla aislada + reintento + registro claro = automatización confiable incluso sin supervisión constante.
Tu automatización falló. ¿Cuál es el primer paso correcto?