Improve workers errors documentation (#21982)

* add outcome values to the workers_trace_events docs

* improve the workers observability errors documentation

* improve the workers observability errors documentation

* try to fix the link

* the trace item schema is updated automatically

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

Co-authored-by: Kody Jackson <[email protected]>

---------

Co-authored-by: Thomas Ankcorn <[email protected]>
Co-authored-by: Kody Jackson <[email protected]>

Author: Ankcorn

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

@@ -242,17 +242,39 @@ To review whether your application is experiencing any downtime or returning any
 2. In **Account Home**, select **Workers & Pages**.
 3. In **Overview**, select your Worker and review your Worker's metrics.
 
-A `responseStreamDisconnected` event `outcome` occurs when one end of the connection hangs up during the deferred proxying stage of a Worker request flow. This is regarded as an error for request metrics, and presents in logs as a non-error log entry. It commonly appears for longer lived connections such as WebSockets.
+### Worker Errors
 
-## Debug exceptions
+The **Errors by invocation status** chart shows the number of errors broken down into the following categories:
 
-After you have identified your Workers application is returning exceptions, use `wrangler tail` to inspect and fix the exceptions.
+| Error                      | Meaning                                                         |
+| -------------------------- | --------------------------------------------------------------- |
+| `Uncaught Exception`       | Your Worker code threw a JavaScript exception during execution. |
+| `Exceeded CPU Time Limits` | Worker exceeded CPU time limit or other resource constraints.   |
+| `Exceeded Memory`          | Worker exceeded the memory limit during execution.              |
+| `Internal`                 | An internal error occurred in the Workers runtime.              |
 
-{/* <!-- TODO: include example --> */}
+The **Client disconnected by type** chart shows the number of client disconnect errors broken down into the following categories:
+
+| Client Disconnects             | Meaning                                                                                                                                                     |
+| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Response Stream Disconnected` | Connection was terminated during the deferred proxying stage of a Worker request flow. It commonly appears for longer lived connections such as [WebSockets](/workers/runtime-apis/websockets/). |
+| `Cancelled`                    | The Client disconnected before the Worker completed its response.                                                                                           |
+
+## Debug exceptions with Workers Logs
+
+[Workers Logs](/workers/observability/logs/workers-logs) is a powerful tool for debugging your Workers. It shows all the historic logs generated by your Worker, including any uncaught exceptions that occur during execution.
+
+To find all your errors in Workers Logs, you can use the following filter: `$metadata.error EXISTS`. This will show all the logs that have an error associated with them. You can also filter by `$workers.outcome` to find the requests that resulted in an error. For example, you can filter by `$workers.outcome = "exception"` to find all the requests that resulted in an uncaught exception.
+
+All the possible outcome values can be found in the [Workers Trace Event](/logs/reference/log-fields/account/workers_trace_events/#outcome) reference.
+
+## Debug exceptions from `Wrangler`
+
+To debug your worker via wrangler use `wrangler tail` to inspect and fix the exceptions.
 
 Exceptions will show up under the `exceptions` field in the JSON returned by `wrangler tail`. After you have identified the exception that is causing errors, redeploy your code with a fix, and continue tailing the logs to confirm that it is fixed.
 
-## Set up a logging service
+## Set up a 3rd party logging service
 
 A Worker can make HTTP requests to any HTTP service on the public Internet. You can use a service like [Sentry](https://sentry.io) to collect error logs from your Worker, by making an HTTP request to the service to report the error. Refer to your service’s API documentation for details on what kind of request to make.