Cloudflare Browser Run: analizzare un job fallito prima di rieseguirlo

Il 18 settembre 2026, Cloudflare ha cambiato il flusso di analisi dei job non riusciti in Cloudflare Browser Run. Ora, al termine di una registrazione, è possibile consultare log della console, richieste di rete e struttura finale della pagina: così si esaminano le prove già raccolte e pagate prima di avviare un altro browser.

Cloudflare Browser Run: le prove restano disponibili a fine esecuzione

In passato, un job nel browser lasciava soltanto il proprio output, la gestione degli errori e, se Session Recording era stato attivato, un replay. Quando il motivo del problema non era evidente, la prassi consisteva nell'aggiungere altri log e rieseguire il job.

Il nuovo pannello Inspect affianca tre viste a una registrazione completata:

• Logs permette di cercare nell'output della console acquisito e di filtrarlo per livello.
• Network mostra metodo, stato, header, payload, risposta e tempi di ogni richiesta. L'attività può essere esportata in un file HAR, il formato di archivio standard per la cronologia delle richieste di un browser.
• DOM mostra la struttura della pagina al termine della registrazione e consente di copiare l'HTML ricostruito. DOM indica l'albero degli elementi creato dal browser a partire dalla pagina.

Si tratta di prove disponibili dopo l'esecuzione, non di un'altra interfaccia per il debug in tempo reale. Session Recording di Cloudflare produce dati strutturati di eventi rrweb, non un video. Registra modifiche al DOM, eventi di mouse e tastiera e navigazione. Quando la sessione è ormai chiusa, il pannello Inspect aggiunge indizi ricercabili attorno a quel replay.

Per questo la novità è diversa dal precedente aggiornamento di Browser Run. Le restrizioni di sessione e la Live View in sola lettura stabiliscono dove può arrivare un job attivo e quali azioni può compiere un cliente mentre lo osserva. Inspect, invece, aiuta il team interno a capire perché un job già concluso è fallito.

Quali errori può chiarire una registrazione

Il pannello è utile quando il problema ha lasciato tracce nel browser.

Un founder SaaS può individuare la richiesta rifiutata

Immaginiamo che un job di estrazione ricorrente raggiunga la pagina ma non restituisca dati. La vista Network può mostrare se un'API ha risposto con 401, se un limite di frequenza ha prodotto 429, se un reindirizzamento ha portato il browser altrove o se una singola dipendenza ha assorbito gran parte dell'esecuzione.

Prima di inserire log temporanei, si possono esaminare i dettagli di richiesta e risposta. La prima diagnosi diventa così più circoscritta: correggere la credenziale, il backoff, il reindirizzamento o la dipendenza lenta che l'esecuzione esistente ha già messo in evidenza.

Un responsabile di agenzia può distinguere una modifica alla pagina da un bug nello script

Un workflow per un cliente può fallire perché è cambiato un selettore, perché al posto della schermata prevista è comparsa una pagina di login o perché la richiesta di una risorsa ha restituito un errore. Il DOM finale e l'HTML copiato mostrano dove è arrivato davvero il browser. La cronologia delle richieste ricostruisce il percorso seguito.

Il team di implementazione riceve così un passaggio di consegne concreto. Non più un generico «l'automazione non funziona», ma l'albero finale degli elementi e un HAR con gli header, i payload, gli stati e i tempi disponibili.

Un platform engineer può seguire la scheda corretta

La registrazione associa gli array di eventi ai target del Chrome DevTools Protocol, per esempio target-1; in genere ogni target corrisponde a una scheda del browser. In una registrazione con più schede, questi target sono esposti separatamente e il pannello Inspect della dashboard segue la scheda selezionata.

È un dettaglio importante nei passaggi di autenticazione e nei workflow degli agenti. La scheda di login può completare l'operazione mentre quella di lavoro fallisce. Le prove separate per target evitano di confondere le due sequenze.

Come registrare un job e recuperarne la traccia di rete

La registrazione è facoltativa. Deve essere abilitata quando la sessione del browser viene acquisita per la prima volta e non può essere attivata in seguito durante la riconnessione a una sessione esistente.

Il punto di partenza più semplice è una singola Browser Session ricorrente i cui errori oggi richiedono una riproduzione manuale.

1. 1

   Abilita la registrazione all'avvio

   Nell'esempio Puppeteer di Cloudflare, la chiamata iniziale a launch riceve recording: true. Prima di chiudere il browser, conserva l'ID della sessione:

   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 usa la stessa opzione di avvio. Una connessione CDP usa recording=true nel proprio URL WebSocket.

2. 2

   Richiedi la registrazione completata

   Dopo la chiusura della sessione, richiedi la registrazione tramite il relativo ID:

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

   La risposta inserisce gli array di eventi in result.events. Le relative chiavi, come target-1, sono gli ID dei target necessari per la richiesta di rete. Una registrazione appena creata può restituire brevemente 404 mentre Cloudflare ne completa l'elaborazione: in quel caso, ripeti la richiesta anziché interpretare il primo 404 come un'esecuzione inesistente.

3. 3

   Recupera le richieste grezze del target

   Scegli uno dei target restituiti dalla risposta della registrazione. Il parametro target è obbligatorio:

   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 risposta contiene in JSON le richieste acquisite, compresi i dettagli disponibili di richieste e risposte.

4. 4

   Esporta il file HAR

   Quando uno sviluppatore deve aprire la traccia nel visualizzatore di rete di un browser o in un altro strumento di analisi, aggiungi format=har:

   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>"

   Considera il file un artefatto di debug da rendere accessibile soltanto per il tempo necessario. La risposta documentata può contenere header e payload disponibili, quindi va protetta come i dati del job che descrive.

L'errore più comune è attivare la registrazione soltanto dopo il primo problema: a quel punto non esistono prove retroattive da ispezionare. Conviene partire da un job ricorrente per il quale il prossimo errore avrà conseguenze concrete.

Il costo del browser non è la voce principale

L'attuale listino di Browser Run di Cloudflare non indica costi separati per la registrazione o la sua archiviazione. Una Browser Session registrata continua a rientrare nella normale fatturazione per ore di browser e concorrenza. Session Recording è in beta: si tratta quindi del prezzo pubblicato oggi, non di una promessa permanente.

Workers Free include 10 minuti di browser al giorno e tre browser simultanei. Workers Paid prevede un minimo mensile di $5 per account, comprende 10 ore di browser e 10 browser simultanei, quindi addebita $0.09 per ogni ora di browser aggiuntiva e $2 per ogni browser simultaneo aggiuntivo, calcolato sulla media mensile del picco giornaliero.

Il prezzo diretto di una singola riesecuzione diagnostica è minimo; non lo è il lavoro necessario per gestirla. Quello che segue è un modello di pianificazione, non un benchmark Cloudflare:

• L'account ha già superato le 10 ore di browser incluse.
• Un job ricorrente dura 10 minuti e fallisce 12 volte in un mese.
• Riprodurre e diagnosticare ogni errore richiede 20 minuti di lavoro di un operatore.
• Esaminare la registrazione esistente richiede 5 minuti di lavoro di un operatore.
• Il costo complessivo ipotizzato per il lavoro dell'operatore è di $75 all'ora.
• L'ispezione evita una riesecuzione diagnostica, anche se potrebbe comunque servire un'esecuzione successiva per verificare la correzione.

Di questa differenza, soltanto 18 centesimi derivano dal tempo grezzo del browser; gli altri $225 sono tempo dell'operatore. Inoltre, Cloudflare arrotonda l'utilizzo del browser a livello di account dopo aver sommato l'intero ciclo di fatturazione: non aspettarti quindi di vedere in fattura 1.5 centesimi per una singola esecuzione di 10 minuti.

La conseguenza economica è questa. Il pannello Inspect non trasforma il calcolo del browser in una fonte di grandi risparmi; può però eliminare da un incidente un intero ciclo di strumentazione, riproduzione e attesa.

Cosa non può mostrare la registrazione

La registrazione acquisisce lo stato e gli eventi del documento, non ogni pixel renderizzato.

Questi limiti definiscono i problemi che richiedono ancora un altro metodo diagnostico. Un grafico disegnato su canvas, un modulo di checkout in un iframe di terze parti, lo stato di un video, una scena WebGL o un valore digitato in un campo mascherato possono essere errati anche quando il resto della registrazione sembra normale.

La vista DOM mostra inoltre la struttura al termine della registrazione. Può spiegare su quale pagina si è concluso il job, ma non è uno screenshot pixel-perfect di ogni stato precedente.

Esistono anche limiti operativi. Le registrazioni restano disponibili per 30 giorni, durano almeno 1 secondo e al massimo 2 ore e funzionano con le Browser Sessions tramite launch() o CDP. Quick Actions non può crearle. Una pagina molto attiva può generare un flusso di eventi voluminoso, perché ogni modifica frequente al DOM diventa un dato della registrazione.

Chi dovrebbe cambiare subito il workflow

È il momento di intervenire se vengono eseguiti job ricorrenti con Puppeteer, Playwright o CDP e, dopo un errore, il primo passo è quasi sempre tentare di riprodurlo. Aggiungi la registrazione a un job, non a tutti, quindi misura se le prove raccolte rispondono alla prima domanda diagnostica.

Meglio aspettare se lo stato importante si trova soprattutto in canvas, WebGL, contenuti multimediali, un iframe cross-origin o campi di modulo mascherati. In quel percorso vanno mantenuti screenshot, log applicativi e strumentazione mirata, perché la registrazione non può sostituirli.

Il cambiamento non riguarda chi lavora soltanto con Quick Actions. Passare alle Browser Sessions esclusivamente per registrare modifica l'implementazione e aggiunge la concorrenza al modello tariffario: il vantaggio diagnostico deve giustificare la scelta.

La mossa da fare lunedì

Scegli una Browser Session ricorrente che sia già fallita più di una volta. Aggiungi recording: true alla chiamata iniziale di avvio, salva l'ID della sessione accanto all'ID del tuo job e lascia che la prossima esecuzione pianificata si chiuda normalmente.

Poi recupera la registrazione, prendi il primo ID target pertinente e richiedi la traccia di rete grezza o il file HAR. Misura quanto tempo serve per individuare la richiesta che non è andata a buon fine o lo stato finale della pagina. Se queste prove evitano una riesecuzione diagnostica, mantieni attiva la registrazione per quel job e includi la traccia nel relativo registro degli incidenti. Se non basta, disattivala e aggiungi il segnale mancante nel punto in cui si trova davvero il limite di osservabilità.

Per ricevere altre analisi operative sui cambiamenti delle piattaforme, iscriviti alla newsletter.