Saltar al contenido principal
Actualizado el Nov 4, 2026

Monitoreo de Ejecución

Lo que aprenderás
  • Cómo acceder al historial de ejecución del workflow desde el icono de historial (reloj)
  • Cómo leer los registros de ejecución y verificar el estado de éxito o fallo
  • Cómo la configuración del nivel de registro afecta los logs de ejecución de la empresa (vista Logs)
  • Cómo solucionar problemas en ejecuciones de workflow fallidas

El monitoreo de ejecución te permite rastrear cada vez que un workflow se ejecuta y ver si tuvo éxito o falló. Úsalo para verificar que tus workflows están funcionando y para diagnosticar problemas cuando algo sale mal.

Acceder al historial de ejecución​

Para ver el historial de ejecución de tus workflows:

  1. Navega a Automatizaciones > Workflows en la barra lateral para abrir la página de lista de workflows.
  2. Haz clic en el icono de historial (reloj) en la parte superior de la página de lista.

Esto abre la vista de historial de ejecución, que muestra un registro de todas las ejecuciones pasadas de los workflows. Cada entrada del historial incluye cuándo se ejecutó el workflow, cuál fue y si la ejecución fue exitosa.

Qué muestran los registros de ejecución​

Cada registro de ejecución resume una ejecución:

  • Timestamp -- La fecha y hora en que se ejecutó el workflow
  • Nombre del workflow -- Qué workflow se ejecutó
  • Estado -- uno de ocho valores, agrupados por ciclo de vida:
    • Aceptado, aún no iniciado: pending (ejecución de hook diferida en la ingesta, a la espera de ser reclamada) y queued (ejecución asíncrona aceptada por la API /v1)
    • En curso: running y luego dispatched, en cuanto la ejecución se entrega al ejecutor
    • Terminales: success, partial, error o skipped (con un skipReason)
  • Metadatos del trigger -- El tipo de trigger y, para los triggers hook, el model y la operación que lo dispararon
  • Resultado -- El campo ok más el mensaje error o skipReason cuando la ejecución falló, terminó partial o se omitió

El registro no almacena la salida de cada paso; captura el resultado general de la ejecución. Cuando un paso falló, también guarda un resumen compacto failedSteps (índice del paso, código de error y mensaje), que la lista del historial de ejecución no muestra -- en la lista, es el mensaje error el que nombra los pasos que fallaron. Para ver el resultado de cada paso individual -- estado por paso, timestamps y safeError -- abre la entrada Logs simple del menú de acciones de la página de edición del workflow (ver más abajo) o el panel de depuración; ese detalle vive en los logs de ejecución de la empresa (log_entries), no en el registro del historial de ejecución.

El estado partial​

partial significa que el motor terminó la ejecución pero al menos un paso dentro de ella no cumplió su función. Cuentan dos cosas:

  • Un paso ordinario falló. El motor registra el fallo y puede continuar con los pasos posteriores. Las denegaciones fatales de alcance/autorización y superar el límite de llamadas a acciones detienen la ejecución y omiten los pasos posteriores.
  • La condición de un paso no pudo evaluarse. El motor omite ese paso, así que nunca se ejecutó aunque nada decidió que no debía hacerlo. Cuenta como fallido, con el código condition_eval_error. Una condición que dio false es una omisión normal y no cuenta.

La ejecución termina entonces con ok: false, un resumen en error que nombra hasta cinco pasos fallidos por índice (contando desde 0) y código -- por ejemplo 1 of 2 steps failed: step 1 (contact_message_send_failed) -- y un resumen failedSteps con entradas {step, code, userMessage}. El historial de ejecución marca una fila partial igual que una fallida.

Los pasos marcados como permitir fallo siguen listados en failedSteps, con handled: true, pero no hacen que la ejecución sea partial: una ejecución cuyos únicos fallos son gestionados sigue siendo success con ok: true. Así que un registro success puede llevar failedSteps -- lee ok, no si la lista está vacía.

Todos los triggers registran este veredicto: las ejecuciones de hook (en línea y diferidas en la ingesta), las ejecuciones temporales (programadas), las ejecuciones manuales con el botón Run, las re-ejecuciones lanzadas desde el panel de administración de AutoTalk y las ejecuciones de la API /v1 en sus dos modos -- una ejecución /v1 síncrona guarda partial en el registro y lo devuelve en la misma respuesta 200, mientras que una ejecución asíncrona lo guarda para quien consulte después. error queda para una ejecución que falló en su conjunto.

Solo el registro de ejecución lleva el veredicto. La respuesta que una ejecución manual da a quien la inició no cambió, así que un workflow padre que ejecuta este mediante Ejecutar Workflow sigue leyendo workflow.step(N).data.ok como true cuando el hijo terminó, aunque el registro del hijo diga partial.

Las ejecuciones iniciadas a través de la API /v1 llevan más: logs (líneas agregadas por paso, con un tope de 200 entradas x 2000 caracteres) y, cuando quien llama lo pide, stepOutputs. Esos campos están ocultos en la lista del historial de ejecución, pero vuelven en la respuesta de la API de la ejecución. failedSteps no es uno de esos extras: una ejecución /v1 solo lo lleva cuando un paso falló, como la de cualquier otro trigger, y en una ejecución sin fallos no aparece en la respuesta de la API.

Cómo el nivel de registro afecta los logs de ejecución​

Dos cosas distintas se llaman Logs

La página de edición del workflow ofrece las dos, en el mismo menú de acciones junto al título de la página -- así que distínguelas por el icono, no por la página en la que estás:

  • Logs con el icono de lista (también ofrecida en cada fila de la lista de workflows) abre el historial de ejecución filtrado por ese workflow -- los mismos registros agregados de workflow_executions que muestra el icono de historial (reloj), sin desglose por paso.
  • La entrada Logs simple, que solo tiene la página de edición, abre los logs de ejecución de la empresa (log_entries) filtrados por ese workflow -- esas son las filas verbosas, paso a paso.

Todo lo que sigue sobre el nivel de registro y el diagnóstico por paso se refiere al segundo.

La configuración de Nivel de registro en cada workflow controla cuánto detalle se escribe en los logs de ejecución de la empresa (log_entries) -- los registros verbosos, paso a paso, que abres desde la entrada Logs simple del menú de acciones de la página de edición del workflow. No cambia los registros del historial de ejecución que muestra el icono de historial (reloj): esos solo llevan un estado agregado y se escriben igual, sin importar el nivel de registro.

  • Los niveles de registro más altos escriben información más detallada, paso a paso, en la vista Logs, incluyendo valores de entrada, valores de salida y datos intermedios. Esto es muy útil durante el desarrollo y las pruebas.
  • Los niveles de registro más bajos escriben solo información esencial, como el estado de éxito/fallo. Esto reduce el ruido y el almacenamiento una vez que el workflow está estable y en producción.
tip

Establece el nivel de registro en una configuración más alta (más verbosa) mientras construyes y pruebas un nuevo workflow, y luego redúcelo una vez que el workflow se ejecute de manera confiable, para mantener la vista Logs limpia y manejable.

Solucionar problemas en ejecuciones fallidas​

Cuando la ejecución de un workflow falla, sigue estos pasos para identificar y corregir el problema:

  1. Abre el historial de ejecución desde el icono de historial (reloj) en la página de lista de workflows.
  2. Encuentra la ejecución fallida en la lista. Una ejecución que falló en su conjunto tiene estado error; una que terminó con un paso fallido, o con un paso cuya condición no pudo evaluarse, tiene estado partial. Las dos se marcan como fallidas, y el mensaje error de una fila partial nombra los pasos que fallaron y sus códigos.
  3. Abre los logs por paso para encontrar qué paso falló. El registro del historial de ejecución solo muestra el estado general y un único mensaje error -- en una ejecución partial ese mensaje nombra los índices y códigos de los pasos que fallaron, pero no hay detalle por paso (entradas, salidas, timestamps). Para identificar el paso que falló, abre la página de edición del workflow, abre el menú de acciones junto al título de la página y elige la entrada Logs simple (o usa el panel de depuración): esa vista lista los log_entries por paso (estado, timestamps y executionContext.safeError) filtrados por ese workflow. La otra entrada Logs -- la del icono de lista, ofrecida también en la fila del workflow -- es otra vista: reabre el historial de ejecución que ya estás mirando.
  4. Revisa los detalles del error. Según el nivel de registro, el registro puede incluir mensajes de error, los datos que se pasaron al paso y metadatos compartidos de ejecución como executionContext.status, timestamps y executionContext.safeError.
  5. Corrige el problema en el workflow. Algunos problemas comunes son:
    • Expresiones CEL en los campos de un paso que referencian datos no disponibles (por ejemplo, un campo contact vacío en esta ejecución)
    • Una condición de paso que no puede evaluarse -- el paso se omite y la ejecución termina partial con el código condition_eval_error
    • Campos obligatorios faltantes en la configuración de un paso
    • Servicios externos (webhooks) que no están disponibles o que devuelven errores
    • Formatos de datos inválidos pasados entre pasos
  6. Vuelve a probar el workflow después de aplicar tu corrección (el workflow debe estar habilitado para las ejecuciones bajo demanda). Para los workflows manuales y temporales, usa el botón Ejecutar. Para los workflows hook, activa de nuevo el evento relevante. Para los workflows temporales no tienes que esperar a la próxima ejecución programada -- el mismo botón Ejecutar funciona bajo demanda -- aunque también puedes esperarla o ajustar el cronograma.

Mejores prácticas para el monitoreo​

  • Revisa el historial de ejecución con regularidad durante los primeros días después de activar un nuevo workflow. La detección temprana de problemas evita que se acumulen.
  • Usa el botón Iniciar depuración en la sección Pasos del formulario del workflow para probar tu workflow antes de activarlo. Ten en cuenta que ejecuta cada paso de forma real (se realizan llamadas HTTP, escrituras y mensajes) -- no es una simulación -- así que apúntalo a objetivos seguros o de prueba mientras depuras.
  • Ajusta los niveles de registro según sea necesario. Aumenta la verbosidad al solucionar un problema específico y luego redúcela una vez que el problema esté resuelto.
  • Revisa la lista de workflows periódicamente para asegurarte de que todos los workflows habilitados se ejecutan como se espera, usando las herramientas de filtro e historial de la página de lista.

Los metadatos de ejecución que se muestran en la interfaz están sanitizados para una depuración segura. Están pensados para ayudarte a entender qué falló sin exponer stack traces crudos, secretos o payloads de proveedores.

info

El icono de historial (reloj) en la página de lista de workflows muestra las ejecuciones de todos los workflows en un solo lugar. Esto facilita detectar patrones, como un workflow que falla cada vez que se ejecuta, o uno que no se ha ejecutado en mucho tiempo.

Próximos pasos​

Última actualización en
En esta página