Esecuzione e monitoraggio

Una volta costruito un grafo, tre controlli nella barra degli strumenti decidono se e come viene eseguito, e la vista Activity del builder è il punto in cui osservi cosa è successo davvero.

Panoramica rapida

1. Clicca Validate per intercettare prima i problemi evidenti.
2. Clicca Test per eseguire il grafo una volta subito, indipendentemente dal suo trigger.
3. Clicca Activate per pubblicarlo e iniziare ad ascoltare il suo trigger reale.
4. Apri la vista Activity (la barra delle icone) per la cronologia delle esecuzioni, gli step log e le statistiche per nodo.
5. Clicca Pause in qualsiasi momento per fermare le nuove esecuzioni senza perdere il draft.

Riferimento dettagliato

Test, Activate e Pause

Controllo	Cosa fa
Test	Salva il draft, lo pubblica e mette subito in coda un'esecuzione al nodo trigger. Fallisce con il report di validazione se il grafo non è valido.
Activate	Salva e pubblica il draft come nuova versione, poi imposta l'automazione su Active così inizia a reagire al suo trigger reale.
Pause	Imposta l'automazione su Paused. Smette di avviare nuove esecuzioni ma mantiene intatti il draft e la cronologia; Activate la riprende.

Stato dell'esecuzione

Stato	Significato
Active	Attualmente in corso, ferma su qualche nodo
Completed	Ha raggiunto un nodo di uscita, o è arrivata in fondo al grafo
Exited	Fermata da un nodo Filter la cui condizione non è stata soddisfatta
Failed	Ha incontrato un errore irrecuperabile

Stato del passaggio

Ogni nodo attraversato da un'esecuzione lascia una voce nello step log.

Stato	Significato
ok	Il passaggio è stato eseguito (o, per un trigger o un nodo logico, valutato) con successo
skipped	La condizione del passaggio lo ha filtrato, oppure il suo executor non è ancora collegato, vedi Nodi
error	L'azione del passaggio è fallita, per esempio una chiamata webhook che non ha restituito una risposta di successo

La vista Activity

Pannello	Mostra
Runs	Ogni esecuzione di questa automazione: il suo stato, il nodo su cui si trova (o il suo errore) e quanto tempo fa è iniziata
Recent step logs	Gli eventi nodo per nodo più recenti tra le esecuzioni, con un breve messaggio dove pertinente
Node stats	Contatori per nodo: quante volte ogni nodo è stato attraversato, completato, saltato o è fallito, su tutte le esecuzioni

Un pulsante Refresh ricarica tutti e tre. Prima che un'automazione sia mai stata eseguita, questa vista mostra un semplice stato vuoto invece di pannelli vuoti.

Affidabilità

Le esecuzioni avanzano un nodo alla volta in background, e il passaggio di ciascun nodo viene registrato una sola volta, anche se il processo in background che controlla le esecuzioni dovesse sovrapporsi a se stesso. In pratica questo significa che un'azione come l'invio di un webhook non partirà due volte per lo stesso passaggio solo perché il controllo che lo fa avanzare è stato eseguito più di una volta.

Retry e gestione degli errori per nodo

Un nodo di azione può essere configurato, nel suo inspector, per riprovare da solo (da 0 a 5 volte, con un'attesa tra i tentativi) prima di ricadere sul comportamento On error: proseguire oltre il fallimento, fermare l'intera esecuzione, o instradare verso un percorso di errore dedicato. Anche le Settings dell'automazione hanno un Default on-error behavior usato da qualsiasi azione che non ne abbia impostato uno proprio. Vedi Creare un flusso di lavoro per sapere esattamente dove si trovano.

Le Node stats in Activity sono cumulative su ogni versione pubblicata di un'automazione, non azzerate ogni volta che attivi una modifica; un picco nel conteggio dei fallimenti di un nodo può derivare dal comportamento di una vecchia versione tanto quanto da quello attuale, quindi confrontalo con i timestamp del pannello Runs.

Passo dopo passo

Guida pratica: testa, leggi il risultato, poi attiva

1. Costruisci un grafo e clicca Validate; correggi ciò che segnala prima di procedere.
2. Clicca Test. Questo salva il draft, ne pubblica una nuova versione e mette subito in coda un'esecuzione al nodo trigger, indipendentemente dal trigger reale.
3. Passa all'icona Activity nella barra. Alla primissima esecuzione di un'automazione vedrai brevemente un semplice stato vuoto invece di pannelli vuoti; clicca Refresh se l'esecuzione non compare subito, dato che il tick fa avanzare le esecuzioni in background invece che istantaneamente.
4. Apri l'esecuzione nel pannello Runs per vedere su quale nodo è ferma in quel momento (o il suo errore), poi controlla Recent step logs per un resoconto nodo per nodo, compresi eventuali passaggi skipped e il loro messaggio.
5. Quando si comporta come ti aspetti, clicca Activate. Questo pubblica un'altra versione, anche se nulla è cambiato da Test, e porta lo stato dell'automazione su Active così il suo trigger reale prende il controllo da qui in poi.

Guida pratica: diagnosticare un'esecuzione che non avanza

1. Apri Activity e trova l'esecuzione; il suo stato e il nodo corrente ti dicono esattamente dove è ferma.
2. Se è Active ma non si muove da un po', verifica se quel nodo è un Delay o un Tarihe kadar bekle (Wait until a date); quelli sono fatti per restare fermi lì, a volte per giorni, e riprendono da soli.
3. Se è ferma su un nodo di azione, controlla in Node stats i contatori di fallimenti/salti di quel nodo; un nodo con un Retry configurato continuerà a ritentare sulla propria pianificazione di attesa prima ancora di raggiungere il suo comportamento On error.
4. Se non si muove nulla su tutte le automazioni contemporaneamente, quasi sempre è il tick periodico che non gira affatto (vedi il consiglio sul self-hosting più sotto), non un problema di questo singolo grafo.

Risoluzione dei problemi

• Lo stato di un'esecuzione resta Active per sempre. O sta davvero aspettando su un Delay, un Wait-until-date o una pianificazione di retry (controlla il nodo corrente), oppure il tick periodico che fa avanzare le esecuzioni non gira affatto; vedi il consiglio sul self-hosting più sotto.
• Gli step log sono vuoti anche se l'esecuzione ha chiaramente fatto qualcosa. Controlla nelle Settings dell'automazione l'opzione Save execution data: Errors only nasconde i passaggi riusciti, e None nasconde tutto, entrambe pensate per risparmiare spazio o evitare di registrare payload sensibili.
• Un'esecuzione è fallita con "zaman aşımı" (timeout). Le Settings hanno un Max run duration; un'esecuzione più vecchia di quel numero di secondi viene fatta fallire automaticamente anche a metà di un delay. Aumentalo, o lascialo non impostato (off) per le automazioni pensate per attendere a lungo.
• L'automazione si è messa in pausa da sola. Il Circuit breaker nelle Settings mette in pausa automaticamente un'automazione dopo che quel numero di esecuzioni fallisce di seguito. Controlla il motivo del fallimento in Activity, correggilo, poi usa di nuovo Activate quando sei sicuro che sia risolto.
• Un webhook o un evento intenso ha prodotto più esecuzioni del previsto. Controlla l'opzione Concurrency nelle Settings; il valore predefinito, Free, consente esecuzioni illimitate di una stessa automazione in parallelo. Single at a time, Skip if busy o Queue all limitano quante possono essere in corso insieme.
• Non gira nulla su un'installazione self-hosted. Questa è la lacuna più comune del self-hosting: nessuno ha pianificato il job periodico. Vedi il consiglio qui sotto.

Consigli

Prima Test, poi Activate

Test viene eseguito subito senza toccare lo stato dell'automazione, così puoi controllare il risultato in Activity prima di portarla su Active.

Deployment self-hosted

Su un'installazione self-hosted, un amministratore deve pianificare il job periodico che fa avanzare le esecuzioni e controlla le pianificazioni in scadenza; vedi Self-Hosting. Sul servizio gestito è automatico.

Correlati

• Creare un flusso di lavoro
• Trigger
• Versioni e condivisione