Atualizado em Sep 17, 2026

Monitoramento de Execução

O que você vai aprender

• Como acessar o histórico de execução do workflow pelo ícone de histórico (relógio)
• Como ler os registros de execução e verificar status de sucesso ou falha
• Como a configuração de nível de log afeta os logs de execução da empresa (visualização Logs)
• Como solucionar problemas em execuções de workflow que falharam

O monitoramento de execução permite acompanhar toda vez que um workflow executa e ver se foi bem-sucedido ou falhou. Use-o para verificar que seus workflows estão funcionando e para diagnosticar problemas quando algo dá errado.

Acessando o histórico de execução

Para visualizar o histórico de execução dos seus workflows:

1. Navegue até Automações > Workflows na barra lateral para abrir a página de lista de workflows.
2. Clique no ícone de histórico (relógio) no topo da página de lista.

Isso abre a visualização do histórico de execução, que mostra um log de todas as execuções passadas dos workflows. Cada entrada no histórico inclui quando o workflow executou, qual workflow foi e se a execução foi bem-sucedida.

O que os registros de execução mostram

Cada registro de execução resume uma execução:

• Timestamp -- A data e hora em que o workflow executou
• Nome do workflow -- Qual workflow foi executado
• Status -- um de oito valores, agrupados por ciclo de vida:
  • Aceito, ainda não iniciado: pending (execução de hook adiada na ingestão, aguardando ser reivindicada) e queued (execução assíncrona aceita pela API /v1)
  • Em andamento: running e depois dispatched, assim que a execução é entregue ao executor
  • Terminais: success, partial, error ou skipped (com um skipReason)
• Metadados do trigger -- O tipo de trigger e, para triggers de hook, o model e a operação que o dispararam
• Resultado -- O campo ok mais a mensagem error ou skipReason quando a execução falhou ou foi ignorada

Para execuções disparadas pela interface, o registro não armazena o resultado de cada etapa individual; ele captura o resultado geral da execução. Para ver o resultado de cada etapa individual -- status por etapa, timestamps e safeError -- abra a entrada Logs simples no menu de ações da página de edição do workflow (veja abaixo) ou o painel de depuração; esse detalhe fica nos logs de execução da empresa (log_entries), não no registro do histórico de execução.

O status partial

partial significa que o motor terminou a execução, mas ao menos uma etapa dentro dela falhou: o motor absorve a falha da etapa e continua, então a execução termina com ok: false e um resumo failedSteps nomeando as etapas que quebraram. Etapas marcadas como permitir falha aparecem nesse resumo como tratadas e não tornam a execução partial.

partial só é escrito por execuções da API /v1, e os dois modos de execução o escrevem: uma execução síncrona o grava no registro e o devolve na mesma resposta 200, enquanto uma execução assíncrona o grava para quem consulta depois. Execuções de hook, o cron de hooks adiados, execuções temporais (agendadas) e execuções manuais pelo botão Run nunca o produzem -- nesses casos, uma etapa que falha encerra a execução como error.

Execuções iniciadas pela API /v1 são a exceção: elas carregam além disso failedSteps (sempre), logs (linhas agregadas por etapa, limitadas a 200 entradas x 2000 caracteres) e, quando quem chama opta por isso, stepOutputs. Esses campos ficam ocultos na lista do histórico de execução, mas voltam na resposta da API da execução.

Como o nível de log afeta os logs de execução

Duas coisas diferentes se chamam Logs

A página de edição do workflow oferece as duas, no mesmo menu de ações ao lado do título da página -- então distinga pelo ícone, não pela página em que você está:

• Logs com o ícone de lista (também oferecido em cada linha da lista de workflows) abre o histórico de execução filtrado por esse workflow -- os mesmos registros agregados de workflow_executions que o ícone de histórico (relógio) mostra, sem detalhamento por etapa.
• A entrada Logs simples, que só a página de edição tem, abre os logs de execução da empresa (log_entries) filtrados por esse workflow -- essas são as linhas verbosas, etapa por etapa.

Tudo abaixo sobre nível de log e diagnóstico por etapa se refere ao segundo.

A configuração de Log Level em cada workflow controla quanto detalhe é escrito nos logs de execução da empresa (log_entries) -- os registros verbosos, etapa por etapa, que você abre pela entrada Logs simples no menu de ações da página de edição do workflow. Ela não altera os registros do histórico de execução mostrados pelo ícone de histórico (relógio): esses carregam apenas um status agregado e são escritos da mesma forma independentemente do nível de log.

• Níveis de log mais altos escrevem informações mais detalhadas por etapa na visualização Logs, incluindo valores de entrada, valores de saída e dados intermediários. Isso é muito útil durante desenvolvimento e testes.
• Níveis de log mais baixos escrevem apenas informações essenciais como status de sucesso/falha. Isso reduz ruído e armazenamento quando o workflow está estável e em produção.

dica

Defina o nível de log para uma configuração mais alta (mais verbosa) enquanto você está construindo e testando um novo workflow, depois reduza-o quando o workflow estiver executando de forma confiável para manter a visualização Logs limpa e gerenciável.

Solucionando problemas em execuções que falharam

Quando a execução de um workflow falha, siga estes passos para identificar e corrigir o problema:

1. Abra o histórico de execução pelo ícone de histórico (relógio) na página de lista de workflows.
2. Encontre a execução que falhou na lista. Execuções com falha são marcadas com um status de erro.
3. Abra os logs por etapa para encontrar qual etapa falhou. O registro do histórico de execução mostra apenas o status geral e uma única mensagem error -- ele não tem um detalhamento por etapa. Para identificar a etapa que falhou, abra a página de edição do workflow, abra o menu de ações ao lado do título da página e escolha a entrada Logs simples (ou use o painel de depuração): essa visualização lista os log_entries por etapa (status, timestamps e executionContext.safeError) filtrados por esse workflow. A outra entrada Logs -- a que tem o ícone de lista, também oferecida na linha do workflow -- é outra visualização: ela reabre o histórico de execução que você já está olhando.
4. Revise os detalhes do erro. Dependendo do nível de log, o registro pode incluir mensagens de erro, os dados que foram passados para a etapa e metadados compartilhados de execução como executionContext.status, timestamps e executionContext.safeError.
5. Corrija o problema no workflow. Problemas comuns incluem:
   • Expressões CEL nos campos de uma etapa que referenciam dados indisponíveis (por exemplo um campo contact vazio nesta execução)
   • Campos obrigatórios faltando na configuração de uma etapa
   • Serviços externos (webhooks) que estão indisponíveis ou retornando erros
   • Formatos de dados inválidos passados entre etapas
6. Re-teste o workflow após fazer a correção (o workflow precisa estar habilitado para execuções sob demanda). Para workflows manuais e temporais, use o botão Executar. Para workflows hook, acione o evento relevante novamente. Para workflows temporais você não precisa aguardar a próxima execução agendada -- o mesmo botão Executar funciona sob demanda -- embora você também possa aguardá-la ou ajustar o cronograma.

Melhores práticas para monitoramento

• Verifique o histórico de execução regularmente durante os primeiros dias após ativar um novo workflow. A detecção precoce de problemas evita que eles se acumulem.
• Use o botão Iniciar Debug na seção Etapas do formulário do workflow para testar seu workflow antes de ativá-lo. Note que ele executa cada etapa de forma real (chamadas HTTP, gravações e mensagens são disparadas) -- não é uma simulação -- então aponte-o para alvos seguros/de teste enquanto depura.
• Ajuste os níveis de log conforme necessário. Aumente a verbosidade ao solucionar um problema específico, depois reduza quando o problema for resolvido.
• Revise a lista de workflows periodicamente para garantir que todos os workflows habilitados estão executando como esperado, usando as ferramentas de filtro e histórico na página de lista.

Os metadados de execução mostrados na interface são sanitizados para depuração segura. Eles são destinados a ajudá-lo a entender o que falhou sem expor stack traces brutos, segredos ou payloads de provedores.

informação

O ícone de histórico (relógio) na página de lista de workflows mostra as execuções de todos os workflows em um só lugar. Isso facilita identificar padrões, como um workflow que falha toda vez que executa, ou um que não executou há muito tempo.

Próximos passos

• Criando um workflow
• Tipos de trigger
• Entradas do workflow