Débogage Cloudflare Browser Run : analysez l’échec avant de relancer

Chez Cloudflare, le débogage Cloudflare Browser Run a changé le 18 septembre 2026. Une fois l’exécution terminée, son enregistrement permet désormais de consulter les logs de console, les requêtes réseau et la structure finale de la page. On peut ainsi analyser les traces déjà produites — et déjà payées — avant de lancer un nouveau navigateur.

Le débogage Cloudflare Browser Run gagne un dossier de preuves après l’exécution

Auparavant, une tâche de navigateur laissait derrière elle son résultat, sa gestion des erreurs et, si Session Recording avait été activé, un replay. Quand la cause de l’échec restait obscure, le réflexe consistait généralement à ajouter des logs, puis à relancer la tâche.

Le nouveau panneau Inspect ajoute trois vues à côté d’un enregistrement terminé :

• Logs permet de rechercher dans les sorties de console enregistrées et de les filtrer par niveau.
• Network détaille, pour chaque requête, la méthode, le statut, les en-têtes, le payload, la réponse et la durée. Toute cette activité peut être exportée dans un fichier HAR, le format d’archive standard qui retrace les requêtes d’un navigateur.
• DOM affiche la structure de la page à la fin de l’enregistrement et permet de copier le HTML reconstitué. Le DOM désigne l’arborescence d’éléments construite par le navigateur à partir de la page.

Il s’agit de traces à examiner après l’exécution, et non d’une nouvelle interface de débogage en direct. Le Session Recording de Cloudflare repose sur des événements rrweb structurés, pas sur une vidéo. Il enregistre les modifications du DOM, les actions de la souris et du clavier ainsi que la navigation. Une fois la session fermée, le panneau Inspect complète ce replay avec des indices interrogeables.

C’est ce qui distingue cette version de la précédente évolution de Browser Run chez Cloudflare. Les garde-fous de session et la Live View en lecture seule déterminent les destinations autorisées pour une tâche active et les actions permises au client qui l’observe. Inspect aide plutôt l’équipe à comprendre pourquoi une tâche déjà terminée a échoué.

Quels échecs l’enregistrement peut-il révéler ?

Le panneau est utile dès lors que l’échec a laissé des traces dans le navigateur.

Un fondateur SaaS indépendant peut repérer la requête rejetée

Imaginons qu’une extraction récurrente atteigne bien la page, mais ne renvoie aucune donnée. La vue Network indique si une API a répondu 401, si une limitation de débit a renvoyé 429, si une redirection a conduit le navigateur au mauvais endroit ou si une dépendance a absorbé l’essentiel du temps d’exécution.

Avant d’ajouter des logs temporaires, il devient possible d’examiner le détail des requêtes et des réponses. Le premier diagnostic gagne en précision : il suffit de corriger les identifiants, la temporisation, la redirection ou la dépendance lente déjà mise en évidence par l’exécution existante.

Une agence peut distinguer une page modifiée d’un bug dans le script

Le workflow d’un client peut échouer parce qu’un sélecteur a changé, qu’une page de connexion a remplacé l’écran attendu ou qu’une ressource a renvoyé une erreur. Le DOM final et le HTML copié montrent la page sur laquelle le navigateur s’est réellement arrêté. La trace réseau explique le chemin suivi pour y parvenir.

L’équipe chargée de l’implémentation reçoit alors des éléments concrets. Au lieu d’un vague « l’automatisation ne fonctionne plus », elle dispose de l’arborescence finale et d’un fichier HAR contenant les en-têtes, payloads, statuts et durées disponibles.

Un ingénieur plateforme peut suivre le bon onglet

Dans l’enregistrement, les tableaux d’événements sont indexés par les cibles du Chrome DevTools Protocol, par exemple target-1. Chaque cible correspond généralement à un onglet du navigateur. Les cibles d’un enregistrement multi-onglets sont présentées séparément, et le panneau Inspect du tableau de bord suit l’onglet sélectionné.

Cette distinction compte dans les workflows d’authentification et d’agents. L’onglet de connexion peut réussir tandis que celui du travail échoue. Des traces séparées par cible évitent de confondre ces deux scénarios.

Enregistrer une tâche et récupérer sa trace réseau

L’enregistrement est facultatif. Il doit être activé au moment de l’acquisition initiale de la session du navigateur ; impossible de l’ajouter ensuite lors de la reconnexion à une session existante.

Le meilleur point de départ est une seule Browser Session récurrente dont les échecs imposent aujourd’hui une reproduction manuelle.

1. 1

   Activer l’enregistrement dès le lancement

   Dans l’exemple Puppeteer de Cloudflare, l’appel de lancement initial reçoit l’option recording: true. Conservez l’identifiant de session avant de fermer le navigateur :

   import puppeteer from "@cloudflare/puppeteer";
   
   interface Env {
   	MYBROWSER: Fetcher;
   }
   
   export default {
   	async fetch(request: Request, env: Env): Promise<Response> {
   		const browser = await puppeteer.launch(env.MYBROWSER, { recording: true });
   		const page = await browser.newPage();
   
   		await page.goto("https://example.com");
   		// ... your automation steps ...
   
   		const sessionId = browser.sessionId();
   		await browser.close();
   
   		return new Response(`Session recorded: ${sessionId}`);
   	},
   };

   Playwright utilise la même option au lancement. Avec une connexion CDP, ajoutez recording=true à l’URL WebSocket.

2. 2

   Récupérer l’enregistrement terminé

   Une fois la session fermée, demandez l’enregistrement à l’aide de son identifiant :

   curl https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID> \
     -H "Authorization: Bearer <API_TOKEN>"

   La réponse place les tableaux d’événements sous result.events. Leurs clés, comme target-1, sont les identifiants de cible nécessaires à la requête réseau. Cloudflare peut brièvement répondre 404 pour un nouvel enregistrement encore en cours de finalisation : réessayez cette requête au lieu de conclure dès le premier 404 que l’exécution a disparu.

3. 3

   Récupérer les requêtes brutes de la cible

   Choisissez l’une des cibles renvoyées avec l’enregistrement. Le paramètre target est obligatoire :

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>' \
     -H "Authorization: Bearer <API_TOKEN>"

   La réponse contient les requêtes capturées au format JSON, avec les détails disponibles sur chaque requête et chaque réponse.

4. 4

   Exporter le fichier HAR

   Ajoutez format=har lorsqu’un développeur doit ouvrir la trace dans l’outil réseau d’un navigateur ou dans un autre outil d’analyse :

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>&format=har' \
     -H "Authorization: Bearer <API_TOKEN>"

   Traitez ce fichier comme un artefact de débogage dont l’accès doit rester étroitement limité. La réponse documentée peut contenir les en-têtes et les payloads disponibles ; elle mérite donc les mêmes précautions que les données de la tâche.

L’erreur la plus facile à commettre consiste à n’activer l’enregistrement qu’après le premier échec. Aucune trace rétroactive ne sera alors disponible. Commencez plutôt avec une tâche récurrente dont le prochain échec aura de l’importance.

Le coût du navigateur n’est pas la dépense principale

La tarification actuelle de Browser Run chez Cloudflare ne prévoit pas de frais distincts pour l’enregistrement ou son stockage. Une Browser Session enregistrée reste facturée selon les heures de navigateur et le nombre d’exécutions simultanées. Session Recording étant en bêta, considérez ce tarif comme celui publié aujourd’hui, pas comme un engagement définitif.

Workers Free inclut 10 minutes de navigateur par jour et trois navigateurs simultanés. Workers Paid impose un minimum mensuel de $5 par compte, avec 10 heures de navigateur et 10 navigateurs simultanés inclus. Au-delà, le tarif est de $0.09 par heure de navigateur supplémentaire et de $2 par navigateur simultané supplémentaire, selon la moyenne mensuelle du pic quotidien.

Le coût direct d’une relance de diagnostic est minime. Le temps humain qui l’entoure ne l’est pas. Voici un modèle de planification, et non un benchmark Cloudflare :

• Le compte a déjà dépassé ses 10 heures de navigateur incluses.
• Une tâche récurrente dure 10 minutes et échoue 12 fois dans le mois.
• Reproduire et diagnostiquer chaque échec demande 20 minutes de travail.
• Examiner l’enregistrement existant demande 5 minutes de travail.
• Le coût horaire chargé est fixé à $75.
• L’inspection évite une relance de diagnostic, même si une exécution ultérieure peut rester nécessaire pour valider le correctif.

Sur cet écart, seuls 18 cents correspondent au temps de navigateur brut. Les $225 restants sont du temps de travail. Cloudflare arrondit en outre l’usage du navigateur au niveau du compte, après totalisation du cycle de facturation : il ne faut donc pas s’attendre à voir 1.5 cents pour une exécution de 10 minutes apparaître comme une ligne sur une facture.

Voilà l’enjeu économique. Le panneau Inspect ne transforme pas le calcul navigateur en source majeure d’économies. En revanche, il peut supprimer une boucle complète d’instrumentation, de reproduction et d’attente pendant un incident.

Ce que l’enregistrement ne peut pas montrer

L’enregistrement capture l’état du document et les événements, pas chaque pixel affiché.

Ces limites indiquent quels échecs exigent encore une autre méthode de diagnostic. Un graphique dessiné dans un canvas, un formulaire de paiement intégré à une iframe tierce, l’état d’une vidéo, une scène WebGL ou une valeur saisie dans un champ masqué peuvent être incorrects alors que le reste de l’enregistrement semble normal.

La vue DOM ne montre par ailleurs que la structure présente à la fin de l’enregistrement. Elle peut expliquer sur quelle page la tâche s’est achevée, mais ne restitue pas au pixel près chacun des états antérieurs.

D’autres limites concernent l’exploitation. Les enregistrements restent disponibles pendant 30 jours, durent au minimum 1 seconde et au maximum 2 heures, et fonctionnent avec les Browser Sessions ouvertes via launch() ou CDP. Les Quick Actions ne peuvent pas en produire. Une page très active peut générer un flux d’événements volumineux, car chaque modification fréquente du DOM devient une donnée d’enregistrement.

Qui devrait modifier son workflow dès maintenant ?

Passez à l’action cette semaine si vous exécutez régulièrement des tâches Puppeteer, Playwright ou CDP et qu’un échec conduit d’ordinaire quelqu’un à le reproduire. Activez l’enregistrement sur une seule tâche, pas sur toutes, puis mesurez si les traces répondent à la première question du diagnostic.

Attendez si l’état décisif se trouve surtout dans un canvas, WebGL, un média, une iframe cross-origin ou des champs de formulaire masqués. Conservez les captures d’écran, les logs applicatifs et l’instrumentation ciblée sur ce parcours : l’enregistrement ne peut pas les remplacer.

Vous n’êtes pas concerné si vous utilisez uniquement les Quick Actions. Passer aux Browser Sessions dans le seul but d’enregistrer modifie l’implémentation et ajoute le nombre d’exécutions simultanées au modèle tarifaire ; le bénéfice pour le débogage doit donc justifier ce changement.

L’action à mener lundi

Choisissez une Browser Session récurrente qui a déjà échoué plus d’une fois. Ajoutez recording: true à son lancement initial, enregistrez l’identifiant de session avec celui de votre propre tâche, puis laissez la prochaine exécution planifiée se fermer normalement.

Récupérez ensuite l’enregistrement, sélectionnez son premier identifiant de cible pertinent et demandez la trace réseau brute ou le fichier HAR. Chronométrez le temps nécessaire pour identifier la requête défaillante ou l’état final de la page. Si ces traces évitent une relance de diagnostic, conservez l’enregistrement pour cette tâche et intégrez la trace à son dossier d’incident. Dans le cas contraire, désactivez-le et ajoutez le signal manquant là où se trouve réellement l’angle mort.

Pour recevoir d’autres analyses opérationnelles des évolutions de plateformes, inscrivez-vous à la newsletter.