Cloudflare Workflows: la nuova retention richiede una scelta esplicita

Cloudflare Workflows: cambia il default, non il limite massimo

Un Workflow di Cloudflare è un'attività durevole composta da più passaggi. La piattaforma conserva lo stato necessario per riprendere l'esecuzione dopo un'attesa o un nuovo tentativo, quindi mantiene l'istanza conclusa per un periodo di retention dopo il completamento o l'errore.

Quell'istanza conservata è una prova operativa. L'API delle istanze di Cloudflare può restituire stato, parametri, output, dettagli dei passaggi, tentativi, tempi ed errori. Se una vecchia riconciliazione di pagamenti, un'importazione cliente o un processo di pubblicazione non è andato a buon fine, è questo il registro che aiuta a ricostruire l'accaduto.

La modifica di settembre ha tre confini precisi:

• Un Workflow su Workers Paid creato il 10 settembre o in seguito conserva per default lo stato delle istanze completate e in errore per sette giorni.
• Un Workflow esistente mantiene il comportamento di retention attuale. Cloudflare non ha accorciato retroattivamente la retention dei vecchi Workflow.
• Workers Free resta a tre giorni, sia come impostazione predefinita sia come limite.

Il piano Paid consente ancora di conservare lo stato fino a 30 giorni. Cloudflare ha quindi ridotto il valore predefinito, non il massimo.

Questa distinzione risolve un'incongruenza nella documentazione. La pagina dei prezzi, aggiornata l'ultima volta il 21 luglio, indica ancora 30 giorni come default del piano Paid. Il riferimento API di Workers, aggiornato il 12 agosto, afferma che, se l'impostazione di retention viene omessa, si applica il massimo dell'account. Entrambe le pagine precedono il changelog del 10 settembre.

Vale quindi la regola più recente e specifica: sette giorni sono il default per i nuovi Workflow Paid. Quelli esistenti non cambiano e il limite del piano Paid resta di 30 giorni.

Sette giorni diventano la scadenza per gestire un incidente

La domanda concreta non è se sette giorni sembrino pochi. È se il team scopra gli errori importanti prima dello scadere del settimo giorno.

Chi guida il backend di processi relativi a pagamenti o ordini potrebbe venire a sapere di una discrepanza soltanto quando l'assistenza o l'amministrazione riconciliano i dati. Se ciò accade dopo la scadenza dell'istanza conservata, il team può ancora disporre della transazione nel sistema esterno ma non più dei tentativi dei passaggi, dei dettagli dell'errore e degli output del Workflow che spiegano il percorso di esecuzione.

Per un SRE c'è una seconda insidia. Cloudflare mantiene interrogabili per 31 giorni le metriche dei Workflow, ma quella finestra analitica non coincide con la retention dello stato dettagliato delle istanze. Una metrica può mostrare che si è verificato un errore; non dimostra che siano ancora disponibili parametri, output, tentativi ed errori della vecchia istanza.

È la stessa regola operativa valida per gli strumenti di analisi degli errori degli agenti AI: la durata delle prove deve coprire il tempo che passa tra il guasto e il momento in cui qualcuno capisce che è rilevante.

Per il responsabile tecnico di un'agenzia, il rischio è l'incoerenza. Un Workflow cliente longevo, creato prima della modifica, può conservare la vecchia finestra; uno sostitutivo creato dopo passa invece, senza preavviso, a sette giorni. Il runbook del cliente può così diventare errato anche se il percorso nel codice appare identico.

Riduci la cronologia dei successi, proteggi quella degli errori

Cloudflare offre due controlli distinti per un motivo:

• successRetention stabilisce per quanto tempo resta disponibile lo stato dopo un completamento riuscito.
• errorRetention stabilisce per quanto tempo resta disponibile lo stato dopo una conclusione con errore o interruzione.

Le esecuzioni riuscite spesso lasciano il risultato operativo durevole altrove: una riga d'ordine, una chiave oggetto, l'ID di un messaggio inviato o il record di un'importazione completata. Quando quel sistema esterno è la fonte attendibile, una finestra breve per i successi può bastare per i controlli immediati di assistenza e replay.

Per le esecuzioni in errore è diverso. Il loro valore spesso risiede proprio nel percorso rimasto incompleto. Il passaggio fallito, i tentativi precedenti, i parametri di input e l'output intermedio possono essere indispensabili per l'indagine. Se i problemi possono emergere in ritardo, è più facile giustificare una finestra più lunga per gli errori che conservare per lo stesso periodo ogni esecuzione riuscita.

L'esempio ufficiale della modifica applica direttamente questa separazione:

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

È un esempio, non una raccomandazione universale. La finestra degli errori va scelta in base al massimo ritardo realistico con cui il problema viene scoperto e analizzato. Quella dei successi dipende invece da quanto a lungo gli operatori devono consultare il record del Workflow dopo che il risultato effettivo è arrivato nel sistema di riferimento.

I conti dello storage tornano solo separando lo stato attivo

Cloudflare fattura lo storage dei Workflow in GB-month. Con Workers Paid, una prima quota di 1 GB-month è inclusa; lo storage aggiuntivo costa $0.20 per GB-month. Cloudflare calcola la misura facendo la media del picco di storage giornaliero su un periodo di fatturazione di 30 giorni.

Il totale dello storage comprende le istanze in esecuzione, in attesa, in errore e completate. Una retention più breve degli stati terminali può quindi ridurre lo spazio occupato dalle esecuzioni concluse, ma non elimina lo stato dei processi ancora attivi o in attesa.

La pagina dei prezzi attuale indica che la fatturazione dei passaggi e dello storage di Workflows si applica dal 10 agosto 2026. Il precedente avviso di fatturazione di luglio prometteva soltanto che non sarebbe iniziata prima di quella data. La pagina attuale fissa la data di avvio pubblicata, ma non prova ancora cosa comparirà nella prossima fattura di uno specifico account.

Quello che segue è un modello dichiaratamente ipotetico, non un benchmark di Cloudflare né un risparmio promesso.

Supponiamo che, con un volume costante, le esecuzioni riuscite aggiungano ogni giorno 1 GB di nuovo stato conservato. Le istanze attive, in esecuzione e in attesa contribuiscono per altri 0.5 GB-month in entrambi gli scenari. Per isolare l'effetto della retention dei successi, il confronto esclude lo storage degli stati in errore. Se errorRetention resta a 30 giorni, misura quello stato e aggiungi la stessa voce relativa alla cronologia degli errori in entrambi gli scenari.

La differenza stimata è di $4.60. Proprio per questo è essenziale dichiarare gli input. Un team con output dei passaggi molto piccoli potrebbe non risparmiare quasi nulla. Un Workflow ad alto volume che conserva risultati pesanti può invece avere una voce molto più grande per i successi mantenuti. Il nuovo default cambia il moltiplicatore, ma sono le dimensioni dello stato e il tasso di completamento a determinare la fattura.

I limiti da considerare senza scorciatoie

Trenta giorni restano il massimo del piano Paid. Se un cliente, un'autorità di regolamentazione o una riconciliazione mensile può far emergere un problema oltre quella finestra, lo stato delle istanze di Workflows non può essere l'unico archivio. Esporta le sole prove necessarie in un sistema dotato di una propria policy di retention e accesso.

Una retention più lunga degli errori conserva anche più stato relativo agli errori. La policy corretta non è «errori per sempre»: deve offrire il tempo sufficiente per scoprire e ricostruire l'incidente, lasciando poi un record durevole e compatto, come l'ID dell'istanza, la versione del workflow, i timestamp, lo stato, l'errore con i dati sensibili rimossi e l'oggetto di business coinvolto.

Anche una retention breve dei successi ha un prerequisito: l'esito positivo deve già risiedere in un sistema affidabile. Se l'output del Workflow è l'unica prova che un'azione sia avvenuta, eliminarlo più presto riduce sia lo storage sia le prove.

Infine, gli override per singola istanza possono frammentare la policy. Un'agenzia con più percorsi di creazione può configurare correttamente il default nella dashboard, mentre una singola chiamata continua a richiedere un'altra finestra. La retention deve entrare nella code review, nel runbook e nel modello dei costi, non vivere soltanto in un'impostazione della dashboard.

Cosa fare adesso con Cloudflare Workflows

È il momento di intervenire questa settimana se hai creato un Workflow Paid il 10 settembre o in seguito, se un errore può arrivare al responsabile dopo sette giorni o se lo stato completato è una voce visibile dello storage. Imposta separatamente la retention dei successi e quella degli errori.

Puoi rimandare l'ottimizzazione se il Workflow è ancora un progetto pilota a basso volume e il suo stato conservato rientra nel primo 1 GB-month incluso. Conviene comunque rendere esplicita la policy: la finestra di indagine conta anche quando l'eccedenza di storage è pari a zero.

La modifica del default non riguarda un Workflow già esistente prima del 10 settembre. Anche Workers Free resta invariato, con default e limite di tre giorni. In nessuno dei due casi viene meno la necessità di un record esterno quando l'azienda deve poter indagare oltre la finestra della piattaforma.

Lunedì, verifica ogni percorso usato per creare un nuovo Workflow. Imposta esplicitamente sia successRetention sia errorRetention, quindi simula in sicurezza un errore e conferma fino a quale giorno il suo stato dettagliato rimarrà consultabile. Inserisci quella data nel runbook prima che sia il primo incidente reale a metterla alla prova.

Ricevi nella newsletter la prossima modifica pratica alle piattaforme.