Visão geral

Um log é o rastreamento registrado de uma execução de workflow. Toda vez que um workflow roda, o Zoen registra o que o disparou, quais blocos rodaram em que ordem e, para cada bloco, a entrada exata, a saída e qualquer erro. Esse rastreamento é a fonte da verdade para depuração: ele reproduz o que cada bloco recebeu, o que fez e o que devolveu, para você achar onde algo deu errado.

Pense como um replay em vídeo da execução, em que você lê o que de fato aconteceu, bloco a bloco.

A página Logs lista todas as execuções do workspace, uma linha por execução. A referência de Logging cobre a página em si: colunas, filtros e a barra lateral. Esta página cobre o que um log captura e como rastrear uma falha até a causa.

O que um log registra

A execução

Cada linha na página Logs é uma execução (run). Ela registra o trigger que a iniciou (manual, api, schedule, chat, webhook, mcp, mothership, copilot ou workflow), um status, uma duração e o custo em créditos. Também carrega um execution ID que nomeia a execução de forma única.

O status mostra o resultado de relance, com execuções falhas marcadas como Error. Ao caçar uma falha, filtre a lista pelos erros e comece por aí.

Os blocos

Abra uma execução e Log Details mostra o rastreamento. A aba Trace lista cada bloco como um span com o timing, na ordem em que rodaram; cada execução de bloco registra o nome e o tipo do bloco, o próprio status, a entrada, a saída e uma mensagem de erro se falhou.

É nesse nível que você depura, porque uma execução falha quando um dos blocos falha, e um bloco costuma falhar por causa da entrada que recebeu. Nesta execução, um olhar nos spans mostra para onde foi o tempo: o HealingAgent levou 7,83s dos 11,61s totais.

Entrada e saída

Cada bloco na barra lateral tem duas abas. A aba Input mostra os valores resolvidos com que o bloco de fato rodou: os valores literais que você digitou e as saídas anteriores que leu por referência (com chaves de API redactadas). A aba Output mostra o que o bloco produziu, formatado como objeto, com markdown renderizado para texto gerado por agente.

A aba de entrada é a importante. Um bloco lê saídas anteriores pelo nome, escrito <blockName.field>, e a aba de entrada mostra no que essas referências resolveram em tempo de execução. Se uma referência apontou para um valor que não estava lá, você vê aqui como ausente ou errado, não como a tag que escreveu. Veja como os blocos passam dados para como essas referências resolvem.

O mesmo inspetor segue você no editor: em execuções manuais e de chat, o console mostra Output e Input de cada bloco ao vivo, com valores como árvore tipada.

O snapshot

Um workflow muda com o tempo. Um log não. Clicar em View Snapshot abre uma cópia congelada do workflow exatamente como estava quando aquela execução aconteceu: os blocos, as conexões, a configuração. Isso importa quando uma execução falhou na semana passada e você editou o workflow desde então. O snapshot mostra a versão que de fato rodou, não a de hoje.

Rastreando uma falha de trás para frente

A depuração segue o mesmo loop repetível sempre. Você começa no bloco que falhou e caminha de volta até o bloco que causou.

1. Ache o bloco que falhou. Abra a execução com erro. A barra lateral marca o bloco cujo status é error. Leia a mensagem de erro.
2. Leia a entrada. Abra a aba Input do bloco. É com isso que ele de fato rodou, depois que toda referência resolveu.
3. Verifique a entrada. Pergunte se essa entrada é o que o bloco esperava. Campo vazio, valor do tipo errado, chave aninhada ausente: o descompasso costuma aparecer aqui.
4. Volte até a origem. Uma entrada ruim veio de algum lugar. Ache o bloco anterior cuja saída o bloco que falhou referenciou e abra a aba Output desse bloco. Ou ele produziu o valor errado, ou nunca rodou.
5. Corrija e rode de novo. Ajuste a referência, a configuração ou o bloco de cima e execute o workflow outra vez.
6. Compare os rastreamentos. Abra o log da nova execução ao lado do antigo. O bloco que estava error agora está success, e a entrada é o valor que você esperava. Isso confirma a correção.

Falhas comuns

A maioria dos erros se resume a um punhado de descompassos de entrada. Conhecer o formato acelera o passo 3.

• Entrada ausente. Um campo de que o bloco precisa ficou vazio, ou a referência resolveu para nada.
• Referência errada. A tag nomeia uma saída que não existe, ou usa o nome de campo errado.
• Tipo incompatível. Uma string onde se esperava um objeto, ou o inverso.
• Chave aninhada ausente. O objeto referenciado existe, mas o campo específico dentro dele não.
• Mensagem vazia do agente. Um Agent não devolveu nada, então o próximo bloco não tinha o que ler.
• Erro externo. Uma ferramenta ou API que o bloco chamou devolveu um erro próprio, surfado na mensagem de erro do bloco.

Quando um valor está no formato errado, reformate-o em um bloco Function, cujo resultado vira saída própria que blocos seguintes podem ler.

Depuração assistida por IA

O Mothership e o Copilot podem ler os logs de uma execução e propor uma correção a partir do rastreamento: a mensagem de erro, a entrada que o bloco recebeu e a saída que o bloco anterior produziu. Os logs continuam sendo a fonte da verdade. Você confirma uma correção proposta do mesmo jeito que a sua: rode o workflow de novo e compare o novo rastreamento com o que falhou.

Retenção

Os logs são guardados para você depurar uma execução depois que ela aconteceu. Planos Free retêm logs por 7 dias; depois disso são arquivados em armazenamento na nuvem e removidos do banco. Planos Pro, Team e Enterprise retêm logs indefinidamente.

Próximos passos