Improve workers errors documentation

src/content/docs/logs/reference/log-fields/account/workers_trace_events.md

@@ -61,7 +61,18 @@ List of console messages emitted during the invocation.
 
 Type: `string`
 
-The outcome of the Worker script invocation. <br />Possible values are <em>ok</em> \| <em>exception</em>.
+The outcome of the Worker script invocation. <br />The possible values for `Outcome` are:
+
+*   `ok`
+*   `exception`
+*   `exceededCpu`
+*   `killSwitch`
+*   `daemonDown`
+*   `scriptNotFound`
+*   `canceled`
+*   `exceededMemory`
+*   `loadShed`
+*   `responseStreamDisconnected`
 
 ## ScriptName
 

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. |
+| `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.