durable objects: cpu time updates #21135

src/content/docs/durable-objects/platform/limits.mdx

@@ -6,7 +6,7 @@ sidebar:
 
 ---
 
-import { Render, GlossaryTooltip } from "~/components";
+import { Render, GlossaryTooltip, WranglerConfig } from "~/components";
 
 Durable Objects are only available on the [Workers Paid plan](/workers/platform/pricing/#workers). Durable Objects limits are the same as [Workers Limits](/workers/platform/limits/), as well as the following limits that are specific to Durable Objects:
 
@@ -20,15 +20,15 @@ Durable Objects are only available on the [Workers Paid plan](/workers/platform/
 | Key size                                 | 2 KiB (2048 bytes)                                               | Key and value combined cannot exceed 2 MB                        |
 | Value size                               | 128 KiB (131072 bytes)                                           | Key and value combined cannot exceed 2 MB                        |
 | WebSocket message size                   | 1 MiB (only for received messages)                               | 1 MiB (only for received messages)                               |
-| CPU per request                          | 30s (including WebSocket messages) [^4]                          | 30s (including WebSocket messages) [^4]                          |
+| CPU per request                          | 30s (including WebSocket messages) [^4]                          | 30 seconds (default) / configurable to 5 minutes of [active CPU time](/workers/platform/limits/#cpu-time) [^4] |
 
 [^1]: The new beta version of Durable Objects is available where each Durable Object has a private, embedded SQLite database. When creating a Durable Object class, users can [opt-in to using SQL storage](/durable-objects/reference/durable-objects-migrations/#enable-sqlite-storage-backend-on-new-durable-object-class-migration).
 
 [^2]: Durable Objects both bills and measures storage based on a gigabyte <br/> (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB). <br/>
 
 [^3]: Will be raised to 10 GB for general availability.
 
-[^4]: Each incoming HTTP request or WebSocket *message* resets the remaining available CPU time to 30 seconds. This allows the Durable Object to consume up to 30 seconds of compute after each incoming network request, with each new network request resetting the timer. If you consume more than 30 seconds of compute between incoming network requests, there is a heightened chance that the individual Durable Object is evicted and reset.
+[^4]: Each incoming HTTP request or WebSocket *message* resets the remaining available CPU time to 30 seconds. This allows the Durable Object to consume up to 30 seconds of compute after each incoming network request, with each new network request resetting the timer. If you consume more than 30 seconds of compute between incoming network requests, there is a heightened chance that the individual Durable Object is evicted and reset. 
 
 For Durable Object classes with [SQLite storage backend](/durable-objects/best-practices/access-durable-objects-storage/#sqlite-storage-backend) these SQL limits apply:
 
@@ -63,3 +63,23 @@ Durable Objects are designed such that the number of individual objects in the s
 - You can create and run as many separate Durable Objects as you want within a given Durable Object <GlossaryTooltip term="namespace">namespace</GlossaryTooltip>.
 - The main limit to your usage of Durable Objects is the total storage limit per account.
 - If you need more storage, contact your account team or complete the [Limit Increase Request Form](https://forms.gle/ukpeZVLWLnKeixDu7) and we will contact you with next steps.
+
+### Increasing Durable Object CPU limits
+
+Durable Objects are Worker scripts, and share the same [per invocation CPU limits](/workers/platform/limits/#worker-limits) as any Workers do. Note that CPU time is active processing time: not time spent waiting on network requests, storage calls, or other general I/O, which don't count towards your CPU time or Durable Objects compute consumption.
+
+By default, the maximum CPU time per Durable Objects invocation (HTTP request, WebSocket message, or Alarm) is set to 30 seconds, but can be increased for all Durable Objects associated with a Durable Object definition by setting `limits.cpu_ms` in your wrangler configuration:
+
+<WranglerConfig>
+
+```jsonc
+{
+  // ...rest of your configuration...
+  "limits": {
+    "cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
+  },
+  // ...rest of your configuration...
+}
+```
+
+</WranglerConfig>