How to Visualize Cloudflare Workflows Using ASTs

Cloudflare’s new Workflow Diagrams feature allows you to visualize dynamically executed TypeScript and JavaScript workflow code directly in the dashboard. Because Cloudflare Workflows execute dynamically as the runtime encounters steps, rather than relying on declarative YAML or JSON files, generating static visualizations requires parsing the underlying Abstract Syntax Tree (AST). This guide covers how Cloudflare’s parser tracks promises, handles minified code, and scales to support massive workflows.

The Dynamic Execution Challenge

Most workflow engines rely on declarative configurations to build visual interfaces. You define states and transitions in a static file, and the visualizer simply reads the JSON or YAML structure. Cloudflare Workflows follow a dynamic execution model. Steps are written in pure TypeScript or JavaScript, and they execute exactly as the runtime encounters them.

This code-first approach creates a visualization problem. A static file reader cannot map dynamic loops, conditional branches, or nested parallelized tasks natively. To bridge this gap, Cloudflare implemented a specialized parsing engine that derives the workflow structure statically at deployment time.

AST Parsing and Graph Generation

The visualizer relies on Abstract Syntax Trees to map your logic. When you deploy a workflow, Cloudflare fetches the bundled script after it passes through the internal Workers configuration service.

The engine uses an AST parser to scan the codebase for WorkflowEntrypoints and subsequent calls to workflow steps. By traversing the AST, the system generates an intermediate graph representation. This intermediate graph maps the exact execution path the runtime will follow. The Cloudflare dashboard API then renders this intermediate graph as an interactive visual diagram.

Production applications usually rely on bundlers that obfuscate code. The parsing engine is designed to handle dense, minified JavaScript generated by standard build tools. You do not need to ship unminified source maps or alter your build process to generate accurate diagrams.

Promise Tracking for Parallel Execution

The most complex part of mapping dynamic code is determining which steps block execution and which run concurrently. The AST parser solves this by tracking Promise and await relationships within your code.

When the parser detects sequential await calls, it maps them as a linear progression of blocking steps. When the parser encounters a Promise.all pattern, it identifies that multiple steps will execute concurrently. The visual diagram renders these Promise.all blocks as parallel branches, clearly illustrating how multiple tasks operate simultaneously.

This visualization becomes critical when you deploy multi-agent systems where different tasks execute independently before merging back into a central decision loop. The dashboard provides an interactive UI for these structures. You can collapse loops and nested logic for a high-level architectural view, or expand specific parallel branches to inspect the execution status of individual steps.

Supporting AI Agents and Code Mode

The AST visualizer provides a verification layer for automated code generation. As AI agents like Claude Code and Cursor increasingly write complex workflow logic, developers need a reliable way to verify the shape of the application without manually reading thousands of lines of generated code.

The generated diagram acts as the source of truth for what the AI has built. It identifies exactly where the AI decided to connect steps, create conditional branches, or parallelize operations.

This verification capability pairs with Cloudflare’s Dynamic Worker Loader API. The Dynamic Worker Loader allows Workers to instantiate new sandbox Workers on the fly using AI-generated code. Because these dynamic sandboxes spin up significantly faster than traditional containers, AI agents can generate and execute code rapidly. The AST visualizer ensures that the overarching workflow orchestrating these dynamic workers remains observable and comprehensible.

Scaling Limits and Local Lifecycle Management

Cloudflare Workflows now support massive execution chains. The maximum step limit for Workflows is 25,000 steps per instance, with a default limit of 10,000 steps.

Tracking the state of a 20,000-step process through raw logs is highly inefficient. The AST visualizer maps these long-running processes visually, allowing you to pinpoint exactly where a massive workflow currently sits in its execution lifecycle.

To support the development of these massive workflows, the wrangler dev environment includes robust local lifecycle management. You can control the workflow state directly from your local machine using new instance methods.

Lifecycle Method	Description
pause()	Halts the workflow execution at the current step.
resume()	Continues execution from a paused state.
restart()	Terminates the current run and starts the workflow from the beginning.
terminate()	Permanently stops the workflow execution.

These local methods match the full lifecycle capabilities available in the production environment. You can test pause and resume logic locally before deploying complex, long-running processes to Cloudflare.

Tradeoffs and Limitations

The AST-based visualization approach carries specific constraints based on its static analysis foundation. The parser maps the workflow based on the deployed code structure. Highly dynamic step generation, such as dynamically constructing step names or logic at runtime based on external API payloads, may not render completely on the visual graph until execution occurs.

Additionally, the parallelization visualizer requires standard Promise tracking. If your code uses non-standard concurrency models or obscures Promise resolution through complex abstractions, the AST parser may fail to map the parallel execution accurately, defaulting to a sequential representation.

Review the Cloudflare Workflows documentation for full API details on the visualizer, and update your Wrangler CLI to the latest version to access the new local lifecycle methods.