Blog

Each Workflow on Workers Paid now supports 10,000 steps by default, configurable up to 25,000 steps in your wrangler.jsonc file:

{
  "workflows": [
    {
      "name": "my-workflow",
      "binding": "MY_WORKFLOW",
      "class_name": "MyWorkflow",
      "limits": {
        "steps": 25000
      }
    }
  ]
}

Previously, each instance was limited to 1,024 steps. Now, Workflows can support more complex, long-running executions without the additional complexity of recursive or child workflow calls.

Note that the maximum persisted state limit per Workflow instance remains 100 MB for Workers Free and 1 GB for Workers Paid. Refer to Workflows limits for more information.

Radar now includes a Network Quality Test page. The tool measures Internet connection quality and performance, showing connection details such as IP address, server location, network (ASN), and IP version. For more detailed speed test results, the page links to speed.cloudflare.com.

Sandboxes now support real-time filesystem watching via sandbox.watch(). The method returns a Server-Sent Events stream backed by native inotify, so your Worker receives create, modify, delete, and move events as they happen inside the container.

sandbox.watch(path, options)

Pass a directory path and optional filters. The returned stream is a standard ReadableStream you can proxy directly to a browser client or consume server-side.

• JavaScript

  // Stream events to a browser client
  const stream = await sandbox.watch("/workspace/src", {
    recursive: true,
    include: ["*.ts", "*.js"],
  });
  
  return new Response(stream, {
    headers: { "Content-Type": "text/event-stream" },
  });

• TypeScript

  // Stream events to a browser client
  const stream = await sandbox.watch("/workspace/src", {
    recursive: true,
    include: ["*.ts", "*.js"],
  });
  
  return new Response(stream, {
    headers: { "Content-Type": "text/event-stream" },
  });

Server-side consumption with parseSSEStream

Use parseSSEStream to iterate over events inside a Worker without forwarding them to a client.

• JavaScript

  import { parseSSEStream } from "@cloudflare/sandbox";
  const stream = await sandbox.watch("/workspace/src", { recursive: true });
  
  for await (const event of parseSSEStream(stream)) {
    console.log(event.type, event.path);
  }

• TypeScript

  import { parseSSEStream } from "@cloudflare/sandbox";
  import type { FileWatchSSEEvent } from "@cloudflare/sandbox";
  
  const stream = await sandbox.watch("/workspace/src", { recursive: true });
  
  for await (const event of parseSSEStream<FileWatchSSEEvent>(stream)) {
    console.log(event.type, event.path);
  }

Each event includes a type field (create, modify, delete, or move) and the affected path. Move events also include a from field with the original path.

Options

Upgrade

To update to the latest version:

npm i @cloudflare/sandbox@latest

For full API details, refer to the Sandbox file watching reference.

You can now copy Cloudflare One resources as JSON or as a ready-to-use API POST request directly from the dashboard. This makes it simple to transition workflows into API calls, automation scripts, or infrastructure-as-code pipelines.

To use this feature, click the overflow menu (⋮) on any supported resource and select Copy as JSON or Copy as POST request. The copied output includes only the fields present on your resource, giving you a clean and minimal starting point for your own API calls.

Initially supported resources:

• Access applications
• Access policies
• Gateway policies
• Resolver policies
• Service tokens
• Identity providers

We will continue to add support for more resources throughout 2026.

AI Gateway now automatically creates a gateway for you on your first request. When you use default as a gateway ID, it will be created if it does not already exist — no need to set one up through the dashboard or API first.

The auto-created default gateway has authentication and log collection turned on, with caching and rate limiting turned off.

For more information, refer to Default gateway.

The latest release of the Agents SDK rewrites observability from scratch with diagnostics_channel, adds keepAlive() to prevent Durable Object eviction during long-running work, and introduces waitForMcpConnections so MCP tools are always available when onChatMessage runs.

Observability rewrite

The previous observability system used console.log() with a custom Observability.emit() interface. v0.7.0 replaces it with structured events published to diagnostics channels — silent by default, zero overhead when nobody is listening.

Every event has a type, payload, and timestamp. Events are routed to seven named channels:

Use the typed subscribe() helper from agents/observability for type-safe access:

• JavaScript

  import { subscribe } from "agents/observability";
  
  const unsub = subscribe("rpc", (event) => {
    if (event.type === "rpc") {
      console.log(`RPC call: ${event.payload.method}`);
    }
    if (event.type === "rpc:error") {
      console.error(
        `RPC failed: ${event.payload.method} — ${event.payload.error}`,
      );
    }
  });
  
  // Clean up when done
  unsub();

• TypeScript

  import { subscribe } from "agents/observability";
  
  const unsub = subscribe("rpc", (event) => {
    if (event.type === "rpc") {
      console.log(`RPC call: ${event.payload.method}`);
    }
    if (event.type === "rpc:error") {
      console.error(
        `RPC failed: ${event.payload.method} — ${event.payload.error}`,
      );
    }
  });
  
  // Clean up when done
  unsub();

In production, all diagnostics channel messages are automatically forwarded to Tail Workers — no subscription code needed in the agent itself:

• JavaScript

  export default {
    async tail(events) {
      for (const event of events) {
        for (const msg of event.diagnosticsChannelEvents) {
          // msg.channel is "agents:rpc", "agents:workflow", etc.
          console.log(msg.timestamp, msg.channel, msg.message);
        }
      }
    },
  };

• TypeScript

  export default {
    async tail(events) {
      for (const event of events) {
        for (const msg of event.diagnosticsChannelEvents) {
          // msg.channel is "agents:rpc", "agents:workflow", etc.
          console.log(msg.timestamp, msg.channel, msg.message);
        }
      }
    },
  };

The custom Observability override interface is still supported for users who need to filter or forward events to external services.

For the full event reference, refer to the Observability documentation.

keepAlive() and keepAliveWhile()

Durable Objects are evicted after a period of inactivity (typically 70-140 seconds with no incoming requests, WebSocket messages, or alarms). During long-running operations — streaming LLM responses, waiting on external APIs, running multi-step computations — the agent can be evicted mid-flight.

keepAlive() prevents this by creating a 30-second heartbeat schedule. The alarm firing resets the inactivity timer. Returns a disposer function that cancels the heartbeat when called.

• JavaScript

  const dispose = await this.keepAlive();
  try {
    const result = await longRunningComputation();
    await sendResults(result);
  } finally {
    dispose();
  }

• TypeScript

  const dispose = await this.keepAlive();
  try {
    const result = await longRunningComputation();
    await sendResults(result);
  } finally {
    dispose();
  }

keepAliveWhile() wraps an async function with automatic cleanup — the heartbeat starts before the function runs and stops when it completes:

• JavaScript

  const result = await this.keepAliveWhile(async () => {
    const data = await longRunningComputation();
    return data;
  });

• TypeScript

  const result = await this.keepAliveWhile(async () => {
    const data = await longRunningComputation();
    return data;
  });

Key details:

• Multiple concurrent callers — Each keepAlive() call returns an independent disposer. Disposing one does not affect others.
• AIChatAgent built-in — AIChatAgent automatically calls keepAlive() during streaming responses. You do not need to add it yourself.
• Uses the scheduling system — The heartbeat does not conflict with your own schedules. It shows up in getSchedules() if you need to inspect it.

For the full API reference and when-to-use guidance, refer to Schedule tasks — Keeping the agent alive.

waitForMcpConnections

AIChatAgent now waits for MCP server connections to settle before calling onChatMessage. This ensures this.mcp.getAITools() returns the full set of tools, especially after Durable Object hibernation when connections are being restored in the background.

• JavaScript

  export class ChatAgent extends AIChatAgent {
    // Default — waits up to 10 seconds
    // waitForMcpConnections = { timeout: 10_000 };
  
    // Wait forever
    waitForMcpConnections = true;
  
    // Disable waiting
    waitForMcpConnections = false;
  }

• TypeScript

  export class ChatAgent extends AIChatAgent {
    // Default — waits up to 10 seconds
    // waitForMcpConnections = { timeout: 10_000 };
  
    // Wait forever
    waitForMcpConnections = true;
  
    // Disable waiting
    waitForMcpConnections = false;
  }

For lower-level control, call this.mcp.waitForConnections() directly inside onChatMessage instead.

Other improvements

• MCP deduplication by name and URL — addMcpServer with HTTP transport now deduplicates on both server name and URL. Calling it with the same name but a different URL creates a new connection. URLs are normalized before comparison (trailing slashes, default ports, hostname case).
• callbackHost optional for non-OAuth servers — addMcpServer no longer requires callbackHost when connecting to MCP servers that do not use OAuth.
• MCP URL security — Server URLs are validated before connection to prevent SSRF. Private IP ranges, loopback addresses, link-local addresses, and cloud metadata endpoints are blocked.
• Custom denial messages — addToolOutput now supports state: "output-error" with errorText for custom denial messages in human-in-the-loop tool approval flows.
• requestId in chat options — onChatMessage options now include a requestId for logging and correlating events.

Upgrade

To update to the latest version:

npm i agents@latest @cloudflare/ai-chat@latest

Radar now tracks post-quantum encryption support on origin servers, provides a tool to test any host for post-quantum compatibility, and introduces a Key Transparency dashboard for monitoring end-to-end encrypted messaging audit logs.

Post-quantum origin support

The new Post-Quantum API provides the following endpoints:

• /post_quantum/tls/support – Tests whether a host supports post-quantum TLS key exchange.
• /post_quantum/origin/summary/{dimension} – Returns origin post-quantum data summarized by key agreement algorithm.
• /post_quantum/origin/timeseries_groups/{dimension} – Returns origin post-quantum timeseries data grouped by key agreement algorithm.

The new Post-Quantum Encryption page shows the share of customer origins supporting X25519MLKEM768, derived from daily automated TLS scans of TLS 1.3-compatible origins. The scanner tests for algorithm support rather than the origin server’s configured preference.

A host test tool allows checking any publicly accessible website for post-quantum encryption compatibility. Enter a hostname and optional port to see whether the server negotiates a post-quantum key exchange algorithm.

Key Transparency

A new Key Transparency section displays the audit status of Key Transparency logs for end-to-end encrypted messaging services. The page launches with two monitored logs: WhatsApp and Facebook Messenger Transport.

Each log card shows the current status, last signed epoch, last verified epoch, and the root hash of the Auditable Key Directory tree. The data is also available through the Key Transparency Auditor API.

Learn more about these features in our blog post and check out the Post-Quantum Encryption and Key Transparency pages to explore the data.

Gateway Protocol Detection now supports seven additional protocols in beta:

These protocols join the existing set of detected protocols (HTTP, HTTP2, SSH, TLS, DCERPC, MQTT, and TPKT) and can be used with the Detected Protocol selector in Network policies to identify and filter traffic based on the application-layer protocol, without relying on port-based identification.

If protocol detection is enabled on your account, these protocols will automatically be logged when detected in your Gateway network traffic.

For more information on using Protocol Detection, refer to the Protocol detection documentation.

Radar now tracks post-quantum encryption support on origin servers, provides a tool to test any host for post-quantum compatibility, and introduces a Key Transparency dashboard for monitoring end-to-end encrypted messaging audit logs.

Post-quantum origin support

The new Post-Quantum API provides the following endpoints:

• /post_quantum/tls/support – Tests whether a host supports post-quantum TLS key exchange.
• /post_quantum/origin/summary/{dimension} – Returns origin post-quantum data summarized by key agreement algorithm.
• /post_quantum/origin/timeseries_groups/{dimension} – Returns origin post-quantum timeseries data grouped by key agreement algorithm.

The new Post-Quantum Encryption page shows the share of customer origins supporting X25519MLKEM768, derived from daily automated TLS scans of TLS 1.3-compatible origins. The scanner tests for algorithm support rather than the origin server’s configured preference.

A host test tool allows checking any publicly accessible website for post-quantum encryption compatibility. Enter a hostname and optional port to see whether the server negotiates a post-quantum key exchange algorithm.

Key Transparency

A new Key Transparency section displays the audit status of Key Transparency logs for end-to-end encrypted messaging services. The page launches with two monitored logs: WhatsApp and Facebook Messenger Transport.

Each log card shows the current status, last signed epoch, last verified epoch, and the root hash of the Auditable Key Directory tree. The data is also available through the Key Transparency Auditor API.

Learn more about these features in our blog post and check out the Post-Quantum Encryption and Key Transparency pages to explore the data.

Radar now tracks post-quantum encryption support on origin servers, provides a tool to test any host for post-quantum compatibility, and introduces a Key Transparency dashboard for monitoring end-to-end encrypted messaging audit logs.

Post-quantum origin support

The new Post-Quantum API provides the following endpoints:

• /post_quantum/tls/support – Tests whether a host supports post-quantum TLS key exchange.
• /post_quantum/origin/summary/{dimension} – Returns origin post-quantum data summarized by key agreement algorithm.
• /post_quantum/origin/timeseries_groups/{dimension} – Returns origin post-quantum timeseries data grouped by key agreement algorithm.

The new Post-Quantum Encryption page shows the share of customer origins supporting X25519MLKEM768, derived from daily automated TLS scans of TLS 1.3-compatible origins. The scanner tests for algorithm support rather than the origin server’s configured preference.

A host test tool allows checking any publicly accessible website for post-quantum encryption compatibility. Enter a hostname and optional port to see whether the server negotiates a post-quantum key exchange algorithm.

Key Transparency

A new Key Transparency section displays the audit status of Key Transparency logs for end-to-end encrypted messaging services. The page launches with two monitored logs: WhatsApp and Facebook Messenger Transport.

Each log card shows the current status, last signed epoch, last verified epoch, and the root hash of the Auditable Key Directory tree. The data is also available through the Key Transparency Auditor API.

Learn more about these features in our blog post and check out the Post-Quantum Encryption and Key Transparency pages to explore the data.