[Workers Logs] Observability docs for Workers Logs (#17028)

* [workers-observability] restructure integrations tab. remove baselime integration from docs

* [workers-observability] first pass on workers logs

* [workers-observability] update real-time logs and reduce redundancy

* [workers-observability] add sidebar ordering. many areas marked todo

* [workers-observability] copy corrections

* [workers-observability] add baselime integration back, mark it as under maintenance

* [workers-observability] add pricing partial, environment copy improvements

* [workers-observability] add execution log message summary, overview page, best practices

* [workers-observability] update cron events documentation

* [workers-observability] hyperlint updates

* [workers-observability] update references to old logging routes, update redirect path for logpush

* Update src/content/docs/workers/observability/logs/workers-logs.mdx

* Update src/content/docs/workers/observability/logs/workers-logs.mdx

* [workers-observability] update references to old logging routes

---------

Co-authored-by: Rohin Lohe <rohin@cloudflare.com>
Co-authored-by: dbenCF <125887610+dbenCF@users.noreply.github.com>

public/_redirects

@@ -1788,6 +1788,8 @@
 # Workers
 /workers/reference/apis/* /workers/runtime-apis/:splat 301
 /workers/templates/pages/* /workers/examples/:splat 301
+/workers/observability/sentry-integration /workers/observability/integrations/sentry 301
+/workers/observability/logging/* /workers/observability/logs/:splat 301
 
 # Others
 /ssl/custom-certificates/* /ssl/edge-certificates/custom-certificates/:splat 301

src/content/changelogs/workers.yaml

@@ -27,7 +27,7 @@ entries:
       - Workers with the [mTLS](/workers/runtime-apis/bindings/mtls/) binding now support [Gradual Deployments](/workers/configuration/versions-and-deployments/gradual-deployments/).
   - publish_date: "2024-07-18"
     description: |-
-      - Added a new `truncated` flag to [Tail Worker](/workers/observability/logging/tail-workers/) events to indicate when the event buffer is full and events are being dropped.
+      - Added a new `truncated` flag to [Tail Worker](/workers/observability/logs/tail-workers/) events to indicate when the event buffer is full and events are being dropped.
   - publish_date: "2024-07-17"
     description: |-
       - Updated v8 to version 12.7.
@@ -105,7 +105,7 @@ entries:
       - The new [`unwrap_custom_thenables` compatibility flag](/workers/configuration/compatibility-dates/#handling-custom-thenables) enables workers to accept custom thenables in internal APIs that expect a promise (for instance, the `ctx.waitUntil(...)` method).
       - TransformStreams created with the TransformStream constructor now have a cancel algorithm that is called when the stream is canceled or aborted. This change is part of the implementation of the WHATWG Streams standard.
       - The [`nodejs_compat` compatibility flag](/workers/runtime-apis/nodejs/) now includes an implementation of the [`MockTracker` API from `node:test`](https://nodejs.org/api/test.html#class-mocktracker). This is not an implementation of the full `node:test` module, and mock timers are currently not included.
-      - Exceptions reported to [Tail Workers](/workers/observability/logging/tail-workers/) now include a "stack" property containing the exception's stack trace, if available.
+      - Exceptions reported to [Tail Workers](/workers/observability/logs/tail-workers/) now include a "stack" property containing the exception's stack trace, if available.
   - publish_date: "2024-03-11"
     description: |-
       - Built-in APIs that return Promises will now produce stack traces when the Promise rejects. Previously, the rejection error lacked a stack trace.
@@ -225,7 +225,7 @@ entries:
       - No externally-visible changes.
   - publish_date: "2023-03-06"
     description: |-
-      - [Workers Logpush](/workers/observability/logging/logpush/#limits) now supports
+      - [Workers Logpush](/workers/observability/logs/logpush/#limits) now supports
       300 characters per log line. This is an increase from the previous limit of 150
       characters per line.
   - publish_date: "2023-02-06"

src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/observability.mdx

@@ -12,24 +12,24 @@ Learn how to access logs with Workers for Platforms.
 
 ### Workers Trace Events Logpush
 
-Workers Trace Events logpush is used to get raw Workers execution logs. Refer to [Logpush](/workers/observability/logging/logpush/) for more information.
+Workers Trace Events logpush is used to get raw Workers execution logs. Refer to [Logpush](/workers/observability/logs/logpush/) for more information.
 
 Logpush can be enabled for an entire dispatch namespace or a single user Worker. To capture logs for all of the user Workers in a dispatch namespace:
 
-1. Create a [Logpush job](/workers/observability/logging/logpush/#create-a-logpush-job).
-2. Enable [logging](/workers/observability/logging/logpush/#enable-logging-on-your-worker) on your dispatch Worker.
+1. Create a [Logpush job](/workers/observability/logs/logpush/#create-a-logpush-job).
+2. Enable [logging](/workers/observability/logs/logpush/#enable-logging-on-your-worker) on your dispatch Worker.
 
 Enabling logging on your dispatch Worker collects logs for both the dispatch Worker and for any user Workers in the dispatch namespace. Logs are automatically collected for all new Workers added to a dispatch namespace. To enable logging for an individual user Worker rather than an entire dispatch namespace, skip step 1 and complete step 2 on your user Worker.
 
 All logs are forwarded to the Logpush job that you have setup for your account. Logpush filters can be used on the `Outcome` or `Script Name` field to include or exclude specific values or send logs to different destinations.
 
 ### Tail Workers
 
-A [Tail Worker](/workers/observability/logging/tail-workers/) receives information about the execution of other Workers (known as producer Workers), such as HTTP statuses, data passed to `console.log()` or uncaught exceptions.
+A [Tail Worker](/workers/observability/logs/tail-workers/) receives information about the execution of other Workers (known as producer Workers), such as HTTP statuses, data passed to `console.log()` or uncaught exceptions.
 
-Use [Tail Workers](/workers/observability/logging/tail-workers/) instead of Logpush if you want granular control over formatting before logs are sent to their destination to receive [diagnostics channel events](/workers/runtime-apis/nodejs/diagnostics-channel), or if you want logs delivered in real-time.
+Use [Tail Workers](/workers/observability/logs/tail-workers/) instead of Logpush if you want granular control over formatting before logs are sent to their destination to receive [diagnostics channel events](/workers/runtime-apis/nodejs/diagnostics-channel), or if you want logs delivered in real-time.
 
-Adding a Tail Worker to  your dispatch Worker collects logs for both the dispatch Worker and for any user Workers in the dispatch namespace. Logs are automatically collected for all new Workers added to a dispatch namespace. To enable logging for an individual user Worker rather than an entire dispatch namespace, add the [Tail Worker configuration](/workers/observability/logging/tail-workers/#configure-tail-workers) directly to the user Worker.
+Adding a Tail Worker to  your dispatch Worker collects logs for both the dispatch Worker and for any user Workers in the dispatch namespace. Logs are automatically collected for all new Workers added to a dispatch namespace. To enable logging for an individual user Worker rather than an entire dispatch namespace, add the [Tail Worker configuration](/workers/observability/logs/tail-workers/#configure-tail-workers) directly to the user Worker.
 
 ## Analytics
 

src/content/docs/d1/build-with-d1/local-development.mdx

@@ -211,4 +211,4 @@ Review the [`unstable_dev()`](/workers/wrangler/api/#usage) documentation for mo
 
 - Use [`wrangler dev`](/workers/wrangler/commands/#dev) to run your Worker and D1 locally and debug issues before deploying.
 - Learn [how to debug D1](/d1/observability/debug-d1/).
-- Understand how to [access logs](/workers/observability/logging/) generated from your Worker and D1.
+- Understand how to [access logs](/workers/observability/logs/) generated from your Worker and D1.

src/content/docs/d1/build-with-d1/remote-development.mdx

@@ -48,4 +48,4 @@ export default {
 ## Related resources
 
 * Learn [how to debug D1](/d1/observability/debug-d1/).
-* Understand how to [access logs](/workers/observability/logging/) generated from your Worker and D1.
+* Understand how to [access logs](/workers/observability/logs/) generated from your Worker and D1.

src/content/docs/d1/observability/debug-d1.mdx

@@ -31,7 +31,7 @@ try {
 
 ## View logs
 
-View a stream of live logs from your Worker by using [`wrangler tail`](/workers/observability/logging/real-time-logs#view-logs-using-wrangler-tail) or via the [Cloudflare dashboard](/workers/observability/logging/real-time-logs#view-logs-from-the-dashboard).
+View a stream of live logs from your Worker by using [`wrangler tail`](/workers/observability/logs/real-time-logs#view-logs-using-wrangler-tail) or via the [Cloudflare dashboard](/workers/observability/logs/real-time-logs#view-logs-from-the-dashboard).
 
 ## Report issues
 
@@ -49,5 +49,5 @@ You should include as much of the following in any bug report:
 ## Related resources
 
 * Learn [how to debug Workers](/workers/observability/).
-* Understand how to [access logs](/workers/observability/logging/) generated from your Worker and D1.
+* Understand how to [access logs](/workers/observability/logs/) generated from your Worker and D1.
 * Use [`wrangler dev`](/workers/wrangler/commands/#dev) to run your Worker and D1 locally and [debug issues before deploying](/workers/testing/local-development/).

src/content/docs/email-routing/limits.mdx

@@ -12,7 +12,7 @@ import { Render } from "~/components"
 
 When you process emails with Email Workers and you are on [Workers’ free pricing tier](/workers/platform/pricing/) you might encounter an allocation error. This may happen due to the size of the emails you are processing and/or the complexity of your Email Worker. Refer to [Worker limits](/workers/platform/limits/#worker-limits) for more information.
 
-You can use the [log functionality for Workers](/workers/observability/logging/) to look for messages related to CPU limits (such as `EXCEEDED_CPU`) and troubleshoot any issues regarding allocation errors.
+You can use the [log functionality for Workers](/workers/observability/logs/) to look for messages related to CPU limits (such as `EXCEEDED_CPU`) and troubleshoot any issues regarding allocation errors.
 
 If you encounter these error messages frequently, consider upgrading to the [Workers Paid plan](/workers/platform/pricing/) for higher usage limits.
 

src/content/docs/logs/about.mdx

@@ -19,7 +19,7 @@ Logpush does not offer storage or search functionality for logs; its primary aim
 :::note
 
 
-Users without an Enterprise plan can still access [Workers Trace Events Logpush](/workers/observability/logging/logpush/) by subscribing to the [Workers Paid](/workers/platform/pricing/) plan.
+Users without an Enterprise plan can still access [Workers Trace Events Logpush](/workers/observability/logs/logpush/) by subscribing to the [Workers Paid](/workers/platform/pricing/) plan.
 
 
 :::

src/content/docs/queues/examples/publish-to-a-queue-over-http.mdx

@@ -156,4 +156,4 @@ This will issue a HTTP POST request, and if successful, return a HTTP 200 with a
 - If you receive a HTTP 403, this is because the `Authorization` header is invalid, or you did not configure a secret.
 - If you receive a HTTP 500, this is either because you did not correctly create a shared secret to your Worker, or you attempted to send an invalid message to your queue.
 
-You can use [`wrangler tail`](/workers/observability/logging/real-time-logs/) to debug the output of `console.log`.
+You can use [`wrangler tail`](/workers/observability/logs/real-time-logs/) to debug the output of `console.log`.

src/content/docs/workers-ai/function-calling/embedded/troubleshooting.mdx

@@ -13,7 +13,7 @@ This section will describe tools for troubleshooting and address common errors.
 
 ## Logging
 
-General [logging](/workers/observability/logging/) capabilities for Workers also apply to embedded function calling.
+General [logging](/workers/observability/logs/) capabilities for Workers also apply to embedded function calling.
 
 ### Function invocations
 

src/content/docs/workers/configuration/cron-triggers.mdx

@@ -125,7 +125,15 @@ curl "http://localhost:8787/__scheduled?cron=*+*+*+*+*"
 
 ## View past events
 
-Users can review the execution history of their Cron Triggers in **Past Cron Events** under [**Logs**](https://dash.cloudflare.com/?to=/:account/workers) or through Cloudflare's [GraphQL Analytics API](/analytics/graphql-api).
+To view the execution history of Cron Triggers, view **Cron Events**:
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
+2. In Account Home, go to **Workers & Pages**.
+3. In **Overview**, select your **Worker**.
+4. Select **Settings**.
+5. Under **Trigger Events**, select **View events**.
+
+Cron Events stores the 100 most recent invocations of the Cron scheduled event. [Workers Logs](/workers/observability/logs/workers-logs) also records invocation logs for the Cron Trigger with a longer retention period and a filter & query interface. If you are interested in an API to access Cron Events, use Cloudflare's [GraphQL Analytics API](/analytics/graphql-api).
 
 :::note
 

src/content/docs/workers/configuration/multipart-upload-metadata.mdx

@@ -83,7 +83,7 @@ These attributes are **not available** for version uploads.
 
 * `tail_consumers` array\[object] optional
 
-  * [Tail Workers](/workers/observability/logging/tail-workers/) that will consume logs from the attached Worker.
+  * [Tail Workers](/workers/observability/logs/tail-workers/) that will consume logs from the attached Worker.
 
 * `tags` array\[string] optional
 

src/content/docs/workers/configuration/versions-and-deployments/gradual-deployments.mdx

@@ -14,7 +14,7 @@ Gradual Deployments give you the ability to incrementally deploy new [versions](
 Using gradual deployments, you can:
 
 - Gradually shift traffic to a newer version of your Worker.
-- Monitor error rates and exceptions across versions using [analytics and logging](/workers/configuration/versions-and-deployments/gradual-deployments/#observability) tooling.
+- Monitor error rates and exceptions across versions using [analytics and logs](/workers/configuration/versions-and-deployments/gradual-deployments/#observability) tooling.
 - [Roll back](/workers/configuration/versions-and-deployments/rollbacks/) to a previously stable version if you notice issues when deploying a new version.
 
 ## Use gradual deployments
@@ -238,7 +238,7 @@ When using gradual deployments, you may want to attribute Workers invocations to
 
 ### Logpush
 
-A new `ScriptVersion` object is available in [Workers Logpush](/workers/observability/logging/logpush/). `ScriptVersion` can only be added through the [Logpush API](/api/operations/post-accounts-account_identifier-logpush-jobs) right now. Sample API call:
+A new `ScriptVersion` object is available in [Workers Logpush](/workers/observability/logs/logpush/). `ScriptVersion` can only be added through the [Logpush API](/api/operations/post-accounts-account_identifier-logpush-jobs) right now. Sample API call:
 
 ```bash
 curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/logpush/jobs' \

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

@@ -287,6 +287,6 @@ async function handleRequest(request) {
 
 ## Related resources
 
-- [Log from Workers](/workers/observability/logging/) - Learn how to log your Workers.
-- [Logpush](/workers/observability/logging/logpush/) - Learn how to push Workers Trace Event Logs to supported destinations.
+- [Log from Workers](/workers/observability/logs/) - Learn how to log your Workers.
+- [Logpush](/workers/observability/logs/logpush/) - Learn how to push Workers Trace Event Logs to supported destinations.
 - [RPC error handling](/workers/runtime-apis/rpc/error-handling/) - Learn how to handle errors from remote-procedure calls.

src/content/docs/workers/observability/baselime-integration.mdx → src/content/docs/workers/observability/integrations/baselime-integration.mdx

@@ -6,7 +6,8 @@ description: Connect to Baselime from your Worker to automatically send errors
   and logs to Baselime.
 sidebar:
   badge:
-    text: Beta
+    variant: caution
+    text: Maintenance Mode
 
 ---
 
@@ -26,7 +27,7 @@ Baselime integration is available to all Enterprise customers and Free, Pro, and
 
 ## How it works
 
-This integration adds a [Tail Worker](/workers/observability/logging/tail-workers) to your application Worker. The Tail Worker automatically sends errors and uncaught exceptions to the Baselime environment you have configured.
+This integration adds a [Tail Worker](/workers/observability/logs/tail-workers) to your application Worker. The Tail Worker automatically sends errors and uncaught exceptions to the Baselime environment you have configured.
 
 This integration supports the following Baselime features:
 

src/content/docs/workers/observability/logging/index.mdx → src/content/docs/workers/observability/integrations/index.mdx

@@ -1,13 +1,13 @@
 ---
 pcx_content_type: navigation
-title: Logging
+title: Integrations
 sidebar:
   group:
     hideIndex: true
 ---
 
 import { DirectoryListing } from "~/components";
 
-Use different methods of logging throughout the entire software development lifecycle of your Worker project.
+Send your telemetry data to third parties.
 
 <DirectoryListing />

src/content/docs/workers/observability/sentry-integration.mdx → src/content/docs/workers/observability/integrations/sentry.mdx

@@ -1,6 +1,6 @@
 ---
 pcx_content_type: concept
-title: Sentry integration
+title: Sentry
 head: []
 description: Connect to a Sentry project from your Worker to automatically send
   errors and uncaught exceptions to Sentry.
@@ -27,14 +27,14 @@ Sentry integration is available to all Enterprise customers and Free, Pro, and B
 :::caution
 
 
-This integration is not supported for Pages projects. Pages does not support [Tail Workers](/workers/observability/logging/tail-workers/), and the Sentry integration relies on adding a Tail Worker to your Worker.
+This integration is not supported for Pages projects. Pages does not support [Tail Workers](/workers/observability/logs/tail-workers/), and the Sentry integration relies on adding a Tail Worker to your Worker.
 
 
 :::
 
 ## How it works
 
-This integration adds a [Tail Worker](/workers/observability/logging/tail-workers) to your application Worker. The Tail Worker automatically sends errors and uncaught exceptions to the Sentry project you have configured.
+This integration adds a [Tail Worker](/workers/observability/logs/tail-workers) to your application Worker. The Tail Worker automatically sends errors and uncaught exceptions to the Sentry project you have configured.
 
 This integration supports the following Sentry features: