[Support Feedback] Improve error handling, Wrangler debugging, and KV troubleshooting (Workers)

src/content/docs/images/transform-images/transform-via-url.mdx

@@ -27,12 +27,30 @@ Here is a breakdown of each part of the URL:
 - `<SOURCE-IMAGE>`
   - An absolute path on the origin server, or an absolute URL (starting with `https://` or `http://`), pointing to an image to resize. The path is not URL-encoded, so the resizing URL can be safely constructed by concatenating `/cdn-cgi/image/options` and the original image URL. For example: `/cdn-cgi/image/width=100/https://s3.example.com/bucket/image.png`.
 
-Here is an example of an URL with `<OPTIONS>` set to `width=80,quality=75` and a `<SOURCE-IMAGE>` of `uploads/avatar1.jpg`:
+## Examples
+
+**Relative path source** — the source image is on the same origin:
+
+```txt
+https://example.com/cdn-cgi/image/format=webp,quality=85/uploads/photo.png
+```
+
+**Full URL source** — the source image is an absolute URL (useful for external images or S3 buckets):
+
+```txt
+https://example.com/cdn-cgi/image/format=webp,quality=85/https://example.com/uploads/photo.png
+```
+
+**In HTML markup** — with `<OPTIONS>` set to `width=80,quality=75` and a `<SOURCE-IMAGE>` of `uploads/avatar1.jpg`:
 
 ```html
 <img src="/cdn-cgi/image/width=80,quality=75/uploads/avatar1.jpg" />
 ```
 
+## When to use URL format versus Workers
+
+The URL format is simpler for static, predictable transforms — you only need to change HTML markup. For dynamic logic such as A/B testing image quality, device-based format selection, or access control, use the [Worker-based approach](/images/transform-images/transform-via-workers/) with the `cf.image` fetch option instead.
+
 <Render file="ir-svg-aside" product="images" />
 
 ## Options

src/content/docs/kv/reference/faq.mdx

@@ -64,3 +64,22 @@ No.
 ### Are key expirations billed as delete operations?
 
 No. Key expirations are not billable operations.
+
+## Troubleshooting
+
+### Common issues
+
+- **Stale reads after writing** — Workers KV is [eventually consistent](/kv/concepts/how-kv-works/#consistency). The [`cacheTtl` parameter](/kv/api/read-key-value-pairs/#cachettl-parameter) controls how long reads are cached locally and does not provide immediate read-after-write consistency. If you need strong consistency, consider using [Durable Objects](/durable-objects/).
+- **Namespace not found or binding errors** — Verify the KV namespace is correctly bound in your Wrangler configuration file. The binding name in your code must match the `binding` value in `[[kv_namespaces]]`. Refer to [KV bindings](/kv/concepts/kv-bindings/) for setup instructions.
+- **Key or value size errors** — Keys are limited to 512 bytes and values to 25 MiB. Refer to [Limits](/kv/platform/limits/) for the full list of constraints.
+
+### Information to gather if the issue persists
+
+If the issue persists after these checks, gather the following details:
+
+1. When you first noticed the issue.
+2. Steps to reproduce the problem.
+3. The KV namespace name experiencing the issue.
+4. Expected behavior versus actual behavior.
+5. The Worker script name that invokes the KV namespace.
+6. A brief summary of what the Worker does.

src/content/docs/workers/observability/errors.mdx

@@ -5,7 +5,7 @@ head: []
 description: Review Workers errors and exceptions.
 ---
 
-import { TabItem, Tabs, DashButton } from "~/components";
+import { TabItem, Tabs, DashButton, TypeScriptExample } from "~/components";
 
 Review Workers errors and exceptions.
 
@@ -15,7 +15,7 @@ When a Worker running in production has an error that prevents it from returning
 
 | Error code | Meaning                                                                                                                                         |
 | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
-| `1101`     | Worker threw a JavaScript exception.                                                                                                            |
+| `1101`     | Worker failed to produce a response (unhandled exception, unresolved Promise, or other runtime failure).                                         |
 | `1102`     | Worker exceeded [CPU time limit](/workers/platform/limits/#cpu-time).                                                                           |
 | `1103`     | The owner of this worker needs to contact [Cloudflare Support](/support/contacting-cloudflare-support/)                                         |
 | `1015`     | Worker hit the [burst rate limit](/workers/platform/limits/#burst-rate).                                                                        |
@@ -31,6 +31,40 @@ Other `11xx` errors generally indicate a problem with the Workers runtime itself
 
 Errors in the `11xx` range can also be related with [Snippets](/rules/snippets/).
 
+### Troubleshooting 1101 errors
+
+A `1101` error with HTTP status `500` means your Worker failed to produce a response. This can happen when your code throws an unhandled JavaScript exception, or when the runtime determines the script will never generate a response (for example, due to unresolved Promises). Visitors see a Cloudflare error page instead of your expected response. Common triggers include:
+
+- **Unhandled promise rejections** — an `await` that rejects without a surrounding `try`/`catch`.
+- **Fetch failures to your origin** — the origin is unreachable or returns an unexpected response that your code does not handle.
+- **KV or binding errors** — a read or write to [Workers KV](/kv/), [D1](/d1/), or another binding fails and the error is not caught.
+
+To fix this, wrap code that could throw in `try`/`catch` blocks and return a graceful fallback response:
+
+<TypeScriptExample filename="src/index.ts">
+
+```ts
+interface Env {
+  MY_KV: KVNamespace;
+}
+
+export default {
+  async fetch(_request: Request, env: Env): Promise<Response> {
+    try {
+      const result = await env.MY_KV.get("key");
+      return new Response(result ?? "No value found");
+    } catch (error) {
+      console.error("KV read failed", error);
+      return new Response("An error occurred", { status: 500 });
+    }
+  },
+};
+```
+
+</TypeScriptExample>
+
+Use [Workers Logs](/workers/observability/logs/workers-logs/) or [`wrangler tail`](/workers/wrangler/commands/general/#tail) to identify the specific exception. For a full list of error codes and invocation statuses, refer to the [error pages table](#error-pages-generated-by-workers) above and [Workers Trace Events](/logs/logpush/logpush-job/datasets/account/workers_trace_events/#outcome).
+
 ### Loop limit
 
 A Worker cannot call itself or another Worker more than 16 times. In order to prevent infinite loops between Workers, the [`CF-EW-Via`](/fundamentals/reference/http-headers/#cf-ew-via) header's value is an integer that indicates how many invocations are left. Every time a Worker is invoked, the integer will decrement by 1. If the count reaches zero, a [`1019`](#error-pages-generated-by-workers) error is returned.

src/content/docs/workers/wrangler/install-and-update.mdx

@@ -55,7 +55,42 @@ To update the version of Wrangler used in your project, run:
 
 <PackageManagers pkg="wrangler@latest" dev />
 
+## Troubleshooting Wrangler
+
+If you run into issues with Wrangler, follow these steps before opening a support ticket or filing an issue.
+
+### Check your version
+
+Run `npx wrangler --version` to confirm you are on the latest release. Many issues are fixed in newer versions — upgrade first and retry your command.
+
+### Collect debug logs
+
+Set the `WRANGLER_LOG` environment variable to `debug` before running your command. This produces verbose output that is useful for diagnosing failures:
+
+```sh
+WRANGLER_LOG=debug npx wrangler deploy
+```
+
+You can also write debug logs to a file with `WRANGLER_LOG_PATH`:
+
+```sh
+WRANGLER_LOG=debug WRANGLER_LOG_PATH=./wrangler-debug.log npx wrangler deploy
+```
+
+Refer to [System environment variables](/workers/wrangler/system-environment-variables/) for the full list of variables.
+
+### Information to provide when requesting help
+
+When opening a support ticket or GitHub issue, include the following:
+
+1. Wrangler version (`npx wrangler --version`).
+2. Full contents of your Wrangler configuration file (`wrangler.toml` or `wrangler.json`), with secrets redacted.
+3. The exact Wrangler command you ran.
+4. Your operating system, Node.js version, and package manager.
+5. Full error output and debug log output (`WRANGLER_LOG=debug`).
+
 ## Related resources
 
 - [Commands](/workers/wrangler/commands/) - A detailed list of the commands that Wrangler supports.
 - [Configuration](/workers/wrangler/configuration/) - Learn more about Wrangler's configuration file.
+- [System environment variables](/workers/wrangler/system-environment-variables/) - Environment variables that control Wrangler behavior.