diff --git a/src/content/changelog/workers/2026-10-17-request-signal-default.mdx b/src/content/changelog/workers/2026-10-17-request-signal-default.mdx
new file mode 100644
index 00000000000..e38a696eab2
--- /dev/null
+++ b/src/content/changelog/workers/2026-10-17-request-signal-default.mdx
@@ -0,0 +1,64 @@
+---
+title: Request.signal will be enabled by default in Workers on November 1
+description: Workers with compatibility dates of November 1, 2026 or later will receive client disconnection events through request.signal by default.
+products:
+ - workers
+date: 2026-10-17
+---
+
+import { TypeScriptExample, WranglerConfig } from "~/components";
+
+Starting November 1, 2026, Workers with a [compatibility date](/workers/configuration/compatibility-dates/) of `2026-11-01` or later will receive client disconnection events through `request.signal` by default. Use these events to stop unnecessary work when a client leaves. You will no longer need the `enable_request_signal` compatibility flag for these dates.
+
+We [introduced this feature in May 2025](/changelog/post/2025-05-22-handle-request-cancellation/). You can log cancellations, clean up resources, or cancel operations that accept an `AbortSignal`.
+
+For example, this Worker logs a client disconnection and cancels an outgoing request:
+
+
+
+```ts
+export default {
+ async fetch(request): Promise {
+ request.signal.addEventListener(
+ "abort",
+ () => {
+ console.log("Client disconnected");
+ },
+ { once: true },
+ );
+
+ return fetch("https://example.com/slow-response", {
+ signal: request.signal,
+ });
+ },
+} satisfies ExportedHandler;
+```
+
+
+
+Existing Workers keep their current behavior until you change their compatibility date or flags. To try this feature before November 1, keep your current date and add `enable_request_signal` to your existing flags. With [`cf`](/cf/get-started/), set `worker.compatibilityFlags` in [`cloudflare.config.ts`](/cf/projects/cloudflare-config/). With Wrangler, set `compatibility_flags`:
+
+
+
+```toml
+compatibility_flags = ["enable_request_signal"]
+```
+
+
+
+With `cf`, run `cf dev` to test locally, then `cf deploy` to publish the change. For an existing Wrangler project, follow the [migration guide](/cf/wrangler/migrate/) before switching to `cf`.
+
+With a compatibility date of `2026-11-01` or later, use `disable_request_signal` instead of `enable_request_signal` in the same flags list to opt out. This change does not enable `request_signal_passthrough`. Pass the signal explicitly, as the example does.
+
+For more information, refer to the [Request API](/workers/runtime-apis/request/#properties) and the [Request.signal compatibility flag](/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests).
diff --git a/src/content/compatibility-flags/request-signal.md b/src/content/compatibility-flags/request-signal.md
index e60e43e6640..4c5ef32270d 100644
--- a/src/content/compatibility-flags/request-signal.md
+++ b/src/content/compatibility-flags/request-signal.md
@@ -1,8 +1,13 @@
---
name: "Enable `Request.signal` for incoming requests"
-sort_date: "2025-05-22"
+sort_date: "2026-11-01"
+enable_date: "2026-11-01"
enable_flag: "enable_request_signal"
disable_flag: "disable_request_signal"
---
-When you use the `enable_request_signal` compatibility flag, you can attach an event listener to [`Request`](/workers/runtime-apis/request/) objects, using the [`signal` property](https://developer.mozilla.org/en-US/docs/Web/API/Request/signal). This allows you to perform tasks when the request to your Worker is canceled by the client.
\ No newline at end of file
+For compatibility dates on or after November 1, 2026, incoming [`Request`](/workers/runtime-apis/request/) objects provide an [`AbortSignal`](https://developer.mozilla.org/en-US/docs/Web/API/Request/signal) that fires an `abort` event when the client disconnects. You can listen for this event to perform cleanup or write logs before the invocation ends.
+
+For earlier compatibility dates, add `enable_request_signal` to opt in. Add `disable_request_signal` to opt out, including with later compatibility dates.
+
+This flag does not change `request_signal_passthrough`. Pass `request.signal` explicitly to APIs that accept a signal, such as [`fetch()`](/workers/runtime-apis/fetch/), to cancel that work when the client disconnects.
diff --git a/src/content/docs/workers/runtime-apis/request.mdx b/src/content/docs/workers/runtime-apis/request.mdx
index ac7f6b9e012..80c8e9f8da5 100644
--- a/src/content/docs/workers/runtime-apis/request.mdx
+++ b/src/content/docs/workers/runtime-apis/request.mdx
@@ -265,7 +265,7 @@ All properties of an incoming `Request` object (the request you receive from the
* The redirect mode to use: `follow`, `error`, or `manual`. The `fetch` method will automatically follow redirects if the redirect mode is set to `follow`. If set to `manual`, the `3xx` redirect response will be returned to the caller as-is. The default for a new `Request` object is `follow`. Note, however, that the incoming `Request` property of a `FetchEvent` will have redirect mode `manual`.
* `signal` AbortSignal read-only
- * The `AbortSignal` corresponding to this request. If you use the [`enable_request_signal`](/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests) compatibility flag, you can attach an event listener to the signal. This allows you to perform cleanup tasks or write to logs before your Worker's invocation ends.
+ * The `AbortSignal` corresponding to this request. For compatibility dates on or after November 1, 2026, the signal fires an `abort` event when the client disconnects. For earlier dates, add the [`enable_request_signal`](/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests) compatibility flag. You can listen for the event to perform cleanup tasks or write logs before your Worker's invocation ends. Use `disable_request_signal` to opt out.
For example, if you run the Worker below, and then abort the request from the client, a log will be written: