diff --git a/src/content/docs/cache/how-to/configure-cache-status-code.mdx b/src/content/docs/cache/how-to/configure-cache-status-code.mdx
index 190551d6350d5d..bf606b18948d1b 100644
--- a/src/content/docs/cache/how-to/configure-cache-status-code.mdx
+++ b/src/content/docs/cache/how-to/configure-cache-status-code.mdx
@@ -84,3 +84,16 @@ Provide a JSON object containing status codes and their corresponding TTLs. Each
 ## Set cache TTL by response status via a Cloudflare Worker
 
 The **cacheTtlByStatus** option is a version of the **cacheTtl** feature that designates a cache TTL for a request’s response status code (for example, `{ "200-299": 86400, 404: 1, "500-599": 0 }`).
+
+## TTL handling for 304 and 200 status codes
+
+1. If a TTL is not explicitly set for status code `304`, we automatically set it to match the TTL of status code `200` (if the user has defined one for `200`).
+
+2. If a user explicitly sets a different TTL for `304` than for `200`, the following behavior will occur:
+
+- When a `200` response is received, the asset is cached with the TTL specified for status `200`.
+- Once the asset expires and we revalidate with the origin, if the origin returns a `304`, the cache TTL is updated to the value set for `304`.
+
+For example, if a user specifies a TTL of one hour for status `200` and 0 seconds (cache and always revalidate) for status `304`, the asset will be cached for 1 hour. After it expires, we revalidate with the origin. If the origin returns a `304`, each subsequent request will trigger revalidation. If the origin continues to return `304`, this cycle will persist.
+
+This behavior is likely undesirable unless the user has a specific use case. Therefore, users should ensure that the TTL for `304` matches the TTL for `200` unless they intentionally require this behavior.
\ No newline at end of file