Cloudflare Workflows : comment adapter la rétention

Cloudflare Workflows : le plafond ne change pas, le réglage par défaut oui

Un Workflow Cloudflare est une tâche durable composée d’étapes. La plateforme conserve assez d’état pour reprendre la tâche après une attente ou une nouvelle tentative, puis garde l’instance pendant une durée de rétention une fois celle-ci terminée ou en erreur.

Cette instance conservée constitue une preuve opérationnelle. L’API des instances de Cloudflare peut renvoyer son statut, ses paramètres, sa sortie, le détail des étapes, les tentatives, les données temporelles et les erreurs. Si un ancien rapprochement de paiements, un import client ou une tâche de publication a échoué, c’est ce journal qui permet de reconstituer les faits.

Le changement de septembre obéit à trois limites :

• Pour un Workflow Workers Paid créé le 10 septembre ou après, l’état des instances terminées ou en erreur est conservé sept jours par défaut.
• Un Workflow existant garde sa politique de rétention actuelle. Cloudflare n’a pas raccourci rétroactivement celle des anciens Workflows.
• Workers Free reste limité à trois jours, à la fois comme réglage par défaut et comme plafond.

L’offre Paid permet toujours de conserver l’état jusqu’à 30 jours. Cloudflare a donc abaissé la valeur par défaut, pas le maximum.

Cette nuance permet de trancher une contradiction embarrassante dans la documentation. La page des tarifs, mise à jour pour la dernière fois le 21 juillet, présente encore 30 jours comme la valeur par défaut de l’offre Paid. La référence de l’API Workers, mise à jour le 12 août, indique qu’en l’absence de paramètre de rétention, le maximum du compte s’applique. Ces deux pages sont antérieures au journal des modifications du 10 septembre.

Il faut donc retenir la règle la plus récente et la plus précise : sept jours par défaut pour les nouveaux Workflows Paid. Rien ne change pour les Workflows Paid existants, et leur plafond reste fixé à 30 jours.

Sept jours : la nouvelle échéance pour enquêter sur un incident

La vraie question n’est pas de savoir si sept jours paraissent courts. Il faut déterminer si votre équipe repère les échecs importants avant la fin du septième jour.

Le responsable backend de tâches de paiement ou de commande peut n’apprendre l’existence d’un écart qu’au moment où le support ou la finance rapproche les écritures. Si l’instance a déjà expiré, l’équipe disposera peut-être encore de la transaction dans un système externe, mais plus des tentatives par étape, des erreurs ni des sorties du Workflow qui expliquent le chemin d’exécution.

Un autre piège guette les SRE. Cloudflare laisse les métriques des Workflows interrogeables pendant 31 jours, mais cette fenêtre analytique ne correspond pas à la rétention détaillée de l’état des instances. Une métrique peut confirmer qu’un échec s’est produit. Elle ne prouve pas que les paramètres, sorties, tentatives et erreurs de l’ancienne instance sont encore accessibles.

Le même principe opérationnel vaut pour les outils d’analyse des échecs d’agents IA : la durée de conservation des preuves doit couvrir le délai entre l’échec et le moment où quelqu’un comprend qu’il compte.

Pour le responsable technique d’une agence, le risque vient aussi des incohérences. Un Workflow client ancien, créé avant le changement, peut conserver sa précédente durée tandis que son remplaçant, créé après, passe silencieusement à sept jours. Le runbook du client peut alors devenir faux sans que le chemin d’exécution du code ait changé.

Dissocier l’historique bon marché des succès de celui, précieux, des erreurs

Cloudflare propose deux réglages pour une bonne raison :

• successRetention détermine combien de temps l’état reste disponible après une exécution réussie.
• errorRetention détermine combien de temps il reste disponible après une fin en erreur ou une interruption.

Les exécutions réussies laissent souvent leur résultat métier durable dans un autre système : enregistrement de commande, clé d’objet, identifiant de message envoyé ou trace d’import terminé. Lorsque ce système externe fait foi, une courte fenêtre pour les succès peut suffire aux contrôles immédiats du support et de rejeu.

La situation diffère pour les exécutions en erreur. C’est souvent leur chemin inachevé qui a de la valeur. L’enquête peut nécessiter l’étape en échec, les tentatives précédentes, les paramètres d’entrée et la sortie intermédiaire. Quand un incident peut remonter tardivement, une rétention plus longue des erreurs se justifie mieux que la conservation de toutes les réussites pendant la même durée.

L’exemple officiel accompagnant le changement dissocie directement les deux :

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

Ce code est un exemple, pas une recommandation universelle. Calibrez la fenêtre des erreurs sur votre délai maximal réaliste de détection et d’investigation. Pour les succès, partez du temps pendant lequel les équipes ont encore besoin du journal du Workflow après l’enregistrement du véritable résultat dans le système de référence.

Le calcul du stockage impose d’isoler l’état actif

Cloudflare facture le stockage des Workflows en GB-months. Avec Workers Paid, le premier 1 GB-month est inclus, puis le stockage supplémentaire coûte $0.20 par GB-month. Cloudflare calcule cette mesure en faisant la moyenne du pic de stockage quotidien sur une période de facturation de 30 jours.

Le total englobe les instances en cours d’exécution, en veille, en erreur et terminées. Une rétention terminale plus courte peut donc réduire le stockage des états achevés, mais elle ne supprime pas l’état des tâches encore actives ou en veille.

La page tarifaire actuelle indique que la facturation des étapes et du stockage des Workflows s’applique à compter du 10 août 2026. L’ancien avis de facturation de juillet promettait seulement qu’elle ne commencerait pas avant cette date. La page actuelle tranche donc la date de début publiée, sans pour autant prouver ce qui figurera sur la prochaine facture d’un compte donné.

Voici un modèle explicitement hypothétique : il ne s’agit ni d’un benchmark Cloudflare, ni d’une économie promise.

Supposons qu’à volume constant, les exécutions réussies ajoutent chaque jour 1 GB d’état nouvellement conservé. Dans les deux scénarios, les instances actives, en cours d’exécution et en veille représentent 0.5 GB-month supplémentaire. Pour isoler l’effet de la rétention des succès, le stockage des états en erreur est exclu de la comparaison. Si errorRetention reste fixé à 30 jours, mesurez cet état et ajoutez la même ligne d’historique des erreurs aux deux scénarios.

L’écart modélisé est de $4.60. Voilà pourquoi il faut expliciter les hypothèses. Une équipe dont les étapes produisent de minuscules sorties n’économisera peut-être presque rien. À l’inverse, un Workflow à fort volume qui conserve des résultats volumineux peut afficher une ligne bien plus importante pour les succès. La nouvelle valeur par défaut modifie le multiplicateur ; ce sont toutefois la taille de vos états et le rythme des exécutions terminées qui déterminent la facture.

Les limites à présenter sans détour

Trente jours restent le maximum de l’offre Paid. Si un client, un régulateur ou un rapprochement mensuel peut faire remonter un problème au-delà de cette fenêtre, l’état des instances Workflows ne peut pas constituer votre seule archive. Exportez les preuves strictement nécessaires vers un système doté de sa propre politique de rétention et d’accès.

Une rétention plus longue des erreurs occupe aussi davantage de stockage. La bonne politique n’est pas « les erreurs pour toujours », mais une durée suffisante pour détecter et reconstituer l’incident, suivie d’un journal durable et compact : identifiant de l’instance, version du workflow, horodatages, statut, erreur expurgée et objet métier concerné.

La rétention courte des succès suppose également que leur résultat se trouve déjà dans un emplacement fiable. Si la sortie du Workflow constitue l’unique preuve qu’une action a bien eu lieu, la supprimer plus tôt réduit à la fois le stockage et les éléments de preuve.

Enfin, les réglages par instance peuvent morceler la politique. Une agence qui dispose de plusieurs chemins de création peut configurer correctement la valeur par défaut dans le dashboard tout en laissant un appelant demander une autre durée. La rétention doit donc figurer dans la revue de code, le runbook et le modèle de coûts, pas seulement dans un réglage du dashboard.

Que faire maintenant ?

Agissez cette semaine si vous avez créé un Workflow Paid le 10 septembre ou après, si un échec peut parvenir à son responsable après sept jours ou si les états terminés représentent une ligne visible de stockage. Définissez séparément la rétention des succès et celle des erreurs.

Vous pouvez différer l’optimisation si le Workflow reste un pilote à faible volume et si son état conservé tient dans le premier 1 GB-month inclus. La politique doit néanmoins être explicite : la fenêtre d’enquête compte même lorsque le surcoût de stockage est nul.

Le changement de valeur par défaut ne vous concerne pas si le Workflow existait déjà avant le 10 septembre. Workers Free ne change pas non plus : sa valeur par défaut et son plafond restent fixés à trois jours. Dans les deux cas, un journal externe demeure nécessaire si l’activité doit pouvoir enquêter au-delà de la fenêtre offerte par la plateforme.

Lundi, auditez tous les chemins de création des nouveaux Workflows. Définissez explicitement successRetention et errorRetention, puis provoquez un échec sans risque et confirmez le dernier jour où son état détaillé restera consultable. Inscrivez cette date dans le runbook avant que le premier incident réel ne mette la politique à l’épreuve.

Recevez la prochaine évolution de plateforme vraiment utile dans la newsletter.