From 031f5ab2f69ed3c076c67ac7bd29e697f6e7e7e9 Mon Sep 17 00:00:00 2001
From: Clayton Cornell <131809008+clayton-cornell@users.noreply.github.com>
Date: Mon, 10 Feb 2025 06:25:31 -0800
Subject: [PATCH] Apply linting rules to loki.* component docs (#2594)

* First linting pass through some loki components

* General linting cleanup

* Format table styles

* Fix small typo

* Fix up rule selector block

* General tidy catching spelling, typos, and formatting

* Another pass to fix style spelling and typos

* Fix some missing syntax and layout

* Add some missing nested block explanations

* Markdown coding cleanup

* Fix ref to OAuth 2.0

* Fix typo in compatible components

* Add required to block definition

* Second try at fixing compat components section
---
 .../reference/components/local/_index.md      |    2 +-
 .../reference/components/local/local.file.md  |   32 +-
 .../components/local/local.file_match.md      |   18 +-
 .../reference/components/loki/_index.md       |    2 +-
 .../reference/components/loki/loki.echo.md    |   24 +-
 .../reference/components/loki/loki.process.md | 1199 ++++++++---------
 .../reference/components/loki/loki.relabel.md |   60 +-
 .../components/loki/loki.rules.kubernetes.md  |  206 +--
 .../components/loki/loki.secretfilter.md      |   68 +-
 .../components/loki/loki.source.api.md        |   65 +-
 .../loki/loki.source.awsfirehose.md           |  150 ++-
 .../loki/loki.source.azure_event_hubs.md      |  121 +-
 .../components/loki/loki.source.cloudflare.md |  144 +-
 .../components/loki/loki.source.docker.md     |  107 +-
 .../components/loki/loki.source.file.md       |   69 +-
 .../components/loki/loki.source.gcplog.md     |  138 +-
 .../components/loki/loki.source.gelf.md       |   58 +-
 .../components/loki/loki.source.heroku.md     |   81 +-
 .../components/loki/loki.source.journal.md    |   62 +-
 .../components/loki/loki.source.kafka.md      |  138 +-
 .../components/loki/loki.source.kubernetes.md |  142 +-
 .../loki/loki.source.kubernetes_events.md     |  150 +--
 .../components/loki/loki.source.podlogs.md    |  288 ++--
 .../components/loki/loki.source.syslog.md     |  103 +-
 .../loki/loki.source.windowsevent.md          |   44 +-
 .../reference/components/loki/loki.write.md   |  239 ++--
 26 files changed, 1841 insertions(+), 1869 deletions(-)

diff --git a/docs/sources/reference/components/local/_index.md b/docs/sources/reference/components/local/_index.md
index 3c8f2793cc..f3830a3e30 100644
--- a/docs/sources/reference/components/local/_index.md
+++ b/docs/sources/reference/components/local/_index.md
@@ -5,7 +5,7 @@ title: local
 weight: 100
 ---
 
-# local
+# `local`
 
 This section contains reference documentation for the `local` components.
 
diff --git a/docs/sources/reference/components/local/local.file.md b/docs/sources/reference/components/local/local.file.md
index cdd8d866ea..bec308ee4f 100644
--- a/docs/sources/reference/components/local/local.file.md
+++ b/docs/sources/reference/components/local/local.file.md
@@ -3,17 +3,19 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/local/loca
 aliases:
   - ../local.file/ # /docs/alloy/latest/reference/components/local.file/
 description: Learn about local.file
+labels:
+  stage: general-availability
 title: local.file
 ---
 
 # `local.file`
 
 `local.file` exposes the contents of a file on disk to other components.
-The file will be watched for changes so that its latest content is always exposed.
+The file is watched for changes so that its latest content is always exposed.
 
 The most common use of `local.file` is to load secrets (for example, API keys) from files.
 
-Multiple `local.file` components can be specified by giving them different labels.
+You can specify multiple `local.file` components by giving them different labels.
 
 ## Usage
 
@@ -25,14 +27,14 @@ local.file "<LABEL>" {
 
 ## Arguments
 
-The following arguments are supported:
+You can use the following arguments with `local.file`:
 
-Name             | Type       | Description                                         | Default      | Required
------------------|------------|-----------------------------------------------------|--------------|---------
-`filename`       | `string`   | Path of the file on disk to watch.                  |              | yes
-`detector`       | `string`   | Which file change detector to use (fsnotify, poll). | `"fsnotify"` | no
-`is_secret`      | `bool`     | Marks the file as containing a [secret][].          | `false`      | no
-`poll_frequency` | `duration` | How often to poll for file changes.                 | `"1m"`       | no
+| Name             | Type       | Description                                              | Default      | Required |
+|------------------|------------|----------------------------------------------------------|--------------|----------|
+| `filename`       | `string`   | Path of the file on disk to watch.                       |              | yes      |
+| `detector`       | `string`   | Which file change detector to use, `fsnotify` or `poll`. | `"fsnotify"` | no       |
+| `is_secret`      | `bool`     | Marks the file as containing a [secret][].               | `false`      | no       |
+| `poll_frequency` | `duration` | How often to poll for file changes.                      | `"1m"`       | no       |
 
 [secret]: ../../../../get-started/configuration-syntax/expressions/types_and_values/#secrets
 
@@ -46,9 +48,9 @@ The `local.file` component doesn't support any blocks. You can configure this co
 
 The following fields are exported and can be referenced by other components:
 
-Name      | Type                 | Description
-----------|----------------------|----------------------------------------------------
-`content` | `string` or `secret` | The contents of the file from the most recent read.
+| Name      | Type                 | Description                                         |
+|-----------|----------------------|-----------------------------------------------------|
+| `content` | `string` or `secret` | The contents of the file from the most recent read. |
 
 The `content` field has the `secret` type only if the `is_secret` argument is true.
 
@@ -58,9 +60,9 @@ You can use `local.file.LABEL.content` to access the contents of the file.
 
 `local.file` is reported as healthy whenever if the watched file was read successfully.
 
-Failing to read the file whenever an update is detected (or after the poll period elapses) will cause the component to be reported as unhealthy.
-When unhealthy, exported fields will be kept at the last healthy value.
-The read error will be exposed as a log message and in the debug information for the component.
+Failing to read the file whenever an update is detected (or after the poll period elapses) causes the component to be reported as unhealthy.
+When unhealthy, exported fields is kept at the last healthy value.
+The read error is exposed as a log message and in the debug information for the component.
 
 ## Debug information
 
diff --git a/docs/sources/reference/components/local/local.file_match.md b/docs/sources/reference/components/local/local.file_match.md
index 1fdf1039e7..02376a0db0 100644
--- a/docs/sources/reference/components/local/local.file_match.md
+++ b/docs/sources/reference/components/local/local.file_match.md
@@ -3,6 +3,8 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/local/loca
 aliases:
   - ../local.file_match/ # /docs/alloy/latest/reference/components/local.file_match/
 description: Learn about local.file_match
+labels:
+  stage: general-availability
 title: local.file_match
 ---
 
@@ -24,11 +26,11 @@ local.file_match "LABEL" {
 
 You can use the following arguments with `local.file_match`:
 
-Name                | Type                | Description                                                                                | Default | Required
----------------     | ------------------- | ------------------------------------------------------------------------------------------ |---------| --------
-`path_targets`      | `list(map(string))` | Targets to expand; looks for glob patterns on the  `__path__` and `__path_exclude__` keys. |         | yes
-`ignore_older_than` | `duration`          | Ignores files which are modified before this duration.                                     |  `"0s"` | no
-`sync_period`       | `duration`          | How often to sync filesystem and targets.                                                  | `"10s"` | no
+| Name                | Type                | Description                                                                                | Default | Required |
+|---------------------|---------------------|--------------------------------------------------------------------------------------------|---------|----------|
+| `path_targets`      | `list(map(string))` | Targets to expand; looks for glob patterns on the  `__path__` and `__path_exclude__` keys. |         | yes      |
+| `ignore_older_than` | `duration`          | Ignores files which are modified before this duration.                                     | `"0s"`  | no       |
+| `sync_period`       | `duration`          | How often to sync filesystem and targets.                                                  | `"10s"` | no       |
 
 `path_targets` uses [doublestar][] style paths.
 
@@ -46,9 +48,9 @@ The `local.file_match` component doesn't support any blocks. You can configure t
 
 The following fields are exported and can be referenced by other components:
 
-Name      | Type                | Description
-----------|---------------------|---------------------------------------------------
-`targets` | `list(map(string))` | The set of targets discovered from the filesystem.
+| Name      | Type                | Description                                        |
+|-----------|---------------------|----------------------------------------------------|
+| `targets` | `list(map(string))` | The set of targets discovered from the filesystem. |
 
 Each target includes the following label:
 
diff --git a/docs/sources/reference/components/loki/_index.md b/docs/sources/reference/components/loki/_index.md
index 6ce605456f..dcb435bd88 100644
--- a/docs/sources/reference/components/loki/_index.md
+++ b/docs/sources/reference/components/loki/_index.md
@@ -5,7 +5,7 @@ title: loki
 weight: 100
 ---
 
-# loki
+# `loki`
 
 This section contains reference documentation for the `loki` components.
 
diff --git a/docs/sources/reference/components/loki/loki.echo.md b/docs/sources/reference/components/loki/loki.echo.md
index 8e46cc47bb..e518563fb0 100644
--- a/docs/sources/reference/components/loki/loki.echo.md
+++ b/docs/sources/reference/components/loki/loki.echo.md
@@ -3,32 +3,38 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.echo/ # /docs/alloy/latest/reference/components/loki.echo/
 description: Learn about loki.echo
+labels:
+  stage: general-availability
 title: loki.echo
 ---
 
-# loki.echo
+# `loki.echo`
 
-`loki.echo` receives log entries from other `loki` components and prints them to the process' standard output (stdout).
+`loki.echo` receives log entries from other `loki` components and prints them to the process' standard output, `stdout`.
 
-Multiple `loki.echo` components can be specified by giving them different labels.
+You can specify multiple `loki.echo` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.echo "LABEL" {}
+loki.echo "<LABEL>" {}
 ```
 
 ## Arguments
 
-`loki.echo` accepts no arguments.
+The `loki.echo` component doesn't support any arguments.
+
+## Blocks
+
+The `loki.echo` component doesn't support any blocks.
 
 ## Exported fields
 
 The following fields are exported and can be referenced by other components:
 
-Name       | Type           | Description
------------|----------------|--------------------------------------------------------------
-`receiver` | `LogsReceiver` | A value that other components can use to send log entries to.
+| Name       | Type           | Description                                                   |
+| ---------- | -------------- | ------------------------------------------------------------- |
+| `receiver` | `LogsReceiver` | A value that other components can use to send log entries to. |
 
 ## Component health
 
@@ -36,7 +42,7 @@ Name       | Type           | Description
 
 ## Debug information
 
-`loki.echo` does not expose any component-specific debug information.
+`loki.echo` doesn't expose any component-specific debug information.
 
 ## Example
 
diff --git a/docs/sources/reference/components/loki/loki.process.md b/docs/sources/reference/components/loki/loki.process.md
index 4041b512ee..731fdc3720 100644
--- a/docs/sources/reference/components/loki/loki.process.md
+++ b/docs/sources/reference/components/loki/loki.process.md
@@ -3,10 +3,12 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.process/ # /docs/alloy/latest/reference/components/loki.process/
 description: Learn about loki.process
+labels:
+  stage: general-availability
 title: loki.process
 ---
 
-# loki.process
+# `loki.process`
 
 `loki.process` receives log entries from other loki components, applies one or more processing _stages_, and forwards the results to the list of receivers in the component's arguments.
 
@@ -14,15 +16,15 @@ A stage is a multi-purpose tool that can parse, transform, and filter log entrie
 These stages are applied to each log entry in order of their appearance in the configuration file.
 All stages within a `loki.process` block have access to the log entry's label set, the log line, the log timestamp, as well as a shared map of 'extracted' values so that the results of one stage can be used in a subsequent one.
 
-Multiple `loki.process` components can be specified by giving them different labels.
+You can specify multiple `loki.process` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.process "LABEL" {
-  forward_to = RECEIVER_LIST
+loki.process "<LABEL>" {
+  forward_to = <RECEIVER_LIST>
 
-  stage.STAGENAME {
+  stage.<STAGENAME> {
     ...
   }
   ...
@@ -31,7 +33,7 @@ loki.process "LABEL" {
 
 ## Arguments
 
-`loki.process` supports the following arguments:
+You can use the following argument with `loki.process`:
 
 | Name         | Type                 | Description                                    | Default | Required |
 | ------------ | -------------------- | ---------------------------------------------- | ------- | -------- |
@@ -39,80 +41,77 @@ loki.process "LABEL" {
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.process`:
-
-| Hierarchy                 | Block                         | Description                                                    | Required |
-|---------------------------|-------------------------------|----------------------------------------------------------------|----------|
-| stage.cri                 | [stage.cri][]                 | Configures a pre-defined CRI-format pipeline.                  | no       |
-| stage.decolorize          | [stage.decolorize][]          | Strips ANSI color codes from log lines.                        | no       |
-| stage.docker              | [stage.docker][]              | Configures a pre-defined Docker log format pipeline.           | no       |
-| stage.drop                | [stage.drop][]                | Configures a `drop` processing stage.                          | no       |
-| stage.eventlogmessage     | [stage.eventlogmessage][]     | Extracts data from the Message field in the Windows Event Log. | no       |
-| stage.geoip               | [stage.geoip][]               | Configures a `geoip` processing stage.                         | no       |
-| stage.json                | [stage.json][]                | Configures a JSON processing stage.                            | no       |
-| stage.label_drop          | [stage.label_drop][]          | Configures a `label_drop` processing stage.                    | no       |
-| stage.label_keep          | [stage.label_keep][]          | Configures a `label_keep` processing stage.                    | no       |
-| stage.labels              | [stage.labels][]              | Configures a `labels` processing stage.                        | no       |
-| stage.limit               | [stage.limit][]               | Configures a `limit` processing stage.                         | no       |
-| stage.logfmt              | [stage.logfmt][]              | Configures a `logfmt` processing stage.                        | no       |
-| stage.luhn                | [stage.luhn][]                | Configures a `luhn` processing stage.                          | no       |
-| stage.match               | [stage.match][]               | Configures a `match` processing stage.                         | no       |
-| stage.metrics             | [stage.metrics][]             | Configures a `metrics` stage.                                  | no       |
-| stage.multiline           | [stage.multiline][]           | Configures a `multiline` processing stage.                     | no       |
-| stage.output              | [stage.output][]              | Configures an `output` processing stage.                       | no       |
-| stage.pack                | [stage.pack][]                | Configures a `pack` processing stage.                          | no       |
-| stage.regex               | [stage.regex][]               | Configures a `regex` processing stage.                         | no       |
-| stage.replace             | [stage.replace][]             | Configures a `replace` processing stage.                       | no       |
-| stage.sampling            | [stage.sampling][]            | Samples logs at a given rate.                                  | no       |
-| stage.static_labels       | [stage.static_labels][]       | Configures a `static_labels` processing stage.                 | no       |
-| stage.structured_metadata | [stage.structured_metadata][] | Configures a structured metadata processing stage.             | no       |
-| stage.template            | [stage.template][]            | Configures a `template` processing stage.                      | no       |
-| stage.tenant              | [stage.tenant][]              | Configures a `tenant` processing stage.                        | no       |
-| stage.timestamp           | [stage.timestamp][]           | Configures a `timestamp` processing stage.                     | no       |
-| stage.windowsevent        | [stage.windowsevent][]        | Configures a `windowsevent` processing stage.                  | no       |
-
-A user can provide any number of these stage blocks nested inside `loki.process`; these will run in order of appearance in the configuration file.
-
-[stage.cri]: #stagecri-block
-[stage.decolorize]: #stagedecolorize-block
-[stage.docker]: #stagedocker-block
-[stage.drop]: #stagedrop-block
-[stage.eventlogmessage]: #stageeventlogmessage-block
-[stage.geoip]: #stagegeoip-block
-[stage.json]: #stagejson-block
-[stage.label_drop]: #stagelabel_drop-block
-[stage.label_keep]: #stagelabel_keep-block
-[stage.labels]: #stagelabels-block
-[stage.limit]: #stagelimit-block
-[stage.logfmt]: #stagelogfmt-block
-[stage.luhn]: #stageluhn-block
-[stage.match]: #stagematch-block
-[stage.metrics]: #stagemetrics-block
-[stage.multiline]: #stagemultiline-block
-[stage.output]: #stageoutput-block
-[stage.pack]: #stagepack-block
-[stage.regex]: #stageregex-block
-[stage.replace]: #stagereplace-block
-[stage.sampling]: #stagesampling-block
-[stage.static_labels]: #stagestatic_labels-block
-[stage.structured_metadata]: #stagestructuredmetadata-block
-[stage.template]: #stagetemplate-block
-[stage.tenant]: #stagetenant-block
-[stage.timestamp]: #stagetimestamp-block
-[stage.windowsevent]: #stagewindowsevent-block
-
-
-### stage.cri block
+You can use the following blocks with `loki.process`:
+
+| Block                                                    | Description                                                    | Required |
+| -------------------------------------------------------- | -------------------------------------------------------------- | -------- |
+| [`stage.cri`][stage.cri]                                 | Configures a pre-defined CRI-format pipeline.                  | no       |
+| [`stage.decolorize`][stage.decolorize]                   | Strips ANSI color codes from log lines.                        | no       |
+| [`stage.docker`][stage.docker]                           | Configures a pre-defined Docker log format pipeline.           | no       |
+| [`stage.drop`][stage.drop]                               | Configures a `drop` processing stage.                          | no       |
+| [`stage.eventlogmessage`][stage.eventlogmessage]         | Extracts data from the Message field in the Windows Event Log. | no       |
+| [`stage.geoip`][stage.geoip]                             | Configures a `geoip` processing stage.                         | no       |
+| [`stage.json`][stage.json]                               | Configures a JSON processing stage.                            | no       |
+| [`stage.label_drop`][stage.label_drop]                   | Configures a `label_drop` processing stage.                    | no       |
+| [`stage.label_keep`][stage.label_keep]                   | Configures a `label_keep` processing stage.                    | no       |
+| [`stage.labels`][stage.labels]                           | Configures a `labels` processing stage.                        | no       |
+| [`stage.limit`][stage.limit]                             | Configures a `limit` processing stage.                         | no       |
+| [`stage.logfmt`][stage.logfmt]                           | Configures a `logfmt` processing stage.                        | no       |
+| [`stage.luhn`][stage.luhn]                               | Configures a `luhn` processing stage.                          | no       |
+| [`stage.match`][stage.match]                             | Configures a `match` processing stage.                         | no       |
+| [`stage.metrics`][stage.metrics]                         | Configures a `metrics` stage.                                  | no       |
+| [`stage.multiline`][stage.multiline]                     | Configures a `multiline` processing stage.                     | no       |
+| [`stage.output`][stage.output]                           | Configures an `output` processing stage.                       | no       |
+| [`stage.pack`][stage.pack]                               | Configures a `pack` processing stage.                          | no       |
+| [`stage.regex`][stage.regex]                             | Configures a `regex` processing stage.                         | no       |
+| [`stage.replace`][stage.replace]                         | Configures a `replace` processing stage.                       | no       |
+| [`stage.sampling`][stage.sampling]                       | Samples logs at a given rate.                                  | no       |
+| [`stage.static_labels`][stage.static_labels]             | Configures a `static_labels` processing stage.                 | no       |
+| [`stage.structured_metadata`][stage.structured_metadata] | Configures a structured metadata processing stage.             | no       |
+| [`stage.template`][stage.template]                       | Configures a `template` processing stage.                      | no       |
+| [`stage.tenant`][stage.tenant]                           | Configures a `tenant` processing stage.                        | no       |
+| [`stage.timestamp`][stage.timestamp]                     | Configures a `timestamp` processing stage.                     | no       |
+
+You can provide any number of these stage blocks nested inside `loki.process`. These blocks run in order of appearance in the configuration file.
+
+[stage.cri]: #stagecri
+[stage.decolorize]: #stagedecolorize
+[stage.docker]: #stagedocker
+[stage.drop]: #stagedrop
+[stage.eventlogmessage]: #stageeventlogmessage
+[stage.geoip]: #stagegeoip
+[stage.json]: #stagejson
+[stage.label_drop]: #stagelabel_drop
+[stage.label_keep]: #stagelabel_keep
+[stage.labels]: #stagelabels
+[stage.limit]: #stagelimit
+[stage.logfmt]: #stagelogfmt
+[stage.luhn]: #stageluhn
+[stage.match]: #stagematch
+[stage.metrics]: #stagemetrics
+[stage.multiline]: #stagemultiline
+[stage.output]: #stageoutput
+[stage.pack]: #stagepack
+[stage.regex]: #stageregex
+[stage.replace]: #stagereplace
+[stage.sampling]: #stagesampling
+[stage.static_labels]: #stagestatic_labels
+[stage.structured_metadata]: #stagestructured_metadata
+[stage.template]: #stagetemplate
+[stage.tenant]: #stagetenant
+[stage.timestamp]: #stagetimestamp
+
+### `stage.cri`
 
 The `stage.cri` inner block enables a predefined pipeline which reads log lines using the CRI logging format.
 
 The following arguments are supported:
 
-| Name                             | Type       | Description                                                          | Default        | Required |
-| -------------------------------- | ---------- | -------------------------------------------------------------------- | -------------- | -------- |
-| `max_partial_lines`              | `number`   | Maximum number of partial lines to hold in memory.                   | `100`          | no       |
-| `max_partial_line_size`          | `number`   | Maximum number of characters which a partial line can have.          | `0`            | no       |
-| `max_partial_line_size_truncate` | `bool`     | Truncate partial lines that are longer than `max_partial_line_size`. | `false`        | no       |
+| Name                             | Type     | Description                                                          | Default | Required |
+| -------------------------------- | -------- | -------------------------------------------------------------------- | ------- | -------- |
+| `max_partial_line_size_truncate` | `bool`   | Truncate partial lines that are longer than `max_partial_line_size`. | `false` | no       |
+| `max_partial_line_size`          | `number` | Maximum number of characters which a partial line can have.          | `0`     | no       |
+| `max_partial_lines`              | `number` | Maximum number of partial lines to hold in memory.                   | `100`   | no       |
 
 `max_partial_line_size` is only taken into account if `max_partial_line_size_truncate` is set to `true`.
 
@@ -122,14 +121,14 @@ stage.cri {}
 
 CRI specifies log lines as single space-delimited values with the following components:
 
-* `time`: The timestamp string of the log
-* `stream`: Either `stdout` or `stderr`
-* `flags`: CRI flags including `F` or `P`
-* `log`: The contents of the log line
+* `time`: The timestamp string of the log.
+* `stream`: Either `stdout` or `stderr`.
+* `flags`: CRI flags including `F` or `P`.
+* `log`: The contents of the log line.
 
 Given the following log line, the subsequent key-value pairs are created in the shared map of extracted data:
 
-```
+```text
 "2019-04-30T02:12:41.8443515Z stdout F message"
 
 content: message
@@ -137,33 +136,34 @@ stream: stdout
 timestamp: 2019-04-30T02:12:41.8443515
 ```
 
-### stage.decolorize block
+### `stage.decolorize`
 
-The `stage.decolorize` strips ANSI color codes from the log lines, thus making it easier to parse logs further.
+The `stage.decolorize` strips ANSI color codes from the log lines, making it easier to parse logs.
 
-The `stage.decolorize` block does not support any arguments or inner blocks, so it is always empty.
+The `stage.decolorize` block doesn't support any arguments or inner blocks, so it's always empty.
 
 ```alloy
 stage.decolorize {}
 ```
 
-`stage.decolorize` turns each line having a color code into a non-colored one, for example:
+`stage.decolorize` turns each line having a color code into a non-colored one.
+For example:
 
-```
+```text
 [2022-11-04 22:17:57.811] \033[0;32http\033[0m: GET /_health (0 ms) 204
 ```
 
 is turned into
 
-```
+```text
 [2022-11-04 22:17:57.811] http: GET /_health (0 ms) 204
 ```
 
-### stage.docker block
+### `stage.docker`
 
 The `stage.docker` inner block enables a predefined pipeline which reads log lines in the standard format of Docker log files.
 
-The `stage.docker` block does not support any arguments or inner blocks, so it is always empty.
+The `stage.docker` block doesn't support any arguments or inner blocks, so it's always empty.
 
 ```alloy
 stage.docker {}
@@ -171,13 +171,13 @@ stage.docker {}
 
 Docker log entries are formatted as JSON with the following keys:
 
-* `log`: The content of log line
-* `stream`: Either `stdout` or `stderr`
-* `time`: The timestamp string of the log line
+* `log`: The content of log line.
+* `stream`: Either `stdout` or `stderr`.
+* `time`: The timestamp string of the log line.
 
 Given the following log line, the subsequent key-value pairs are created in the shared map of extracted data:
 
-```
+```text
 {"log":"log message\n","stream":"stderr","time":"2019-04-30T02:12:41.8443515Z"}
 
 output: log message\n
@@ -185,7 +185,7 @@ stream: stderr
 timestamp: 2019-04-30T02:12:41.8443515
 ```
 
-### stage.drop block
+### `stage.drop`
 
 The `stage.drop` inner block configures a filtering stage that drops log entries based on several options.
 If multiple options are provided, they're treated as AND clauses and must _all_ be true for the log entry to be dropped.
@@ -194,25 +194,28 @@ To drop entries with an OR clause, specify multiple `drop` blocks in sequence.
 The following arguments are supported:
 
 | Name                  | Type       | Description                                                                                                            | Default        | Required |
-|-----------------------|------------|------------------------------------------------------------------------------------------------------------------------|----------------|----------|
-| `source`              | `string`   | Name or comma-separated list of names from extracted data to match. If empty or not defined, it uses the log message.  | `""`           | no       |
-| `separator`           | `string`   | When `source` is a comma-separated list of names, this separator is placed between concatenated extracted data values. | `";"`          | no       |
+| --------------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------- | -------------- | -------- |
+| `drop_counter_reason` | `string`   | A custom reason to report for dropped lines.                                                                           | `"drop_stage"` | no       |
 | `expression`          | `string`   | A valid RE2 regular expression.                                                                                        | `""`           | no       |
-| `value`               | `string`   | If both `source` and `value` are specified, the stage drops lines where `value` exactly matches the source content.    | `""`           | no       |
-| `older_than`          | `duration` | If specified, the stage drops lines whose timestamp is older than the current time minus this duration.                | `""`           | no       |
 | `longer_than`         | `string`   | If specified, the stage drops lines whose size exceeds the configured value.                                           | `""`           | no       |
-| `drop_counter_reason` | `string`   | A custom reason to report for dropped lines.                                                                           | `"drop_stage"` | no       |
+| `older_than`          | `duration` | If specified, the stage drops lines whose timestamp is older than the current time minus this duration.                | `""`           | no       |
+| `separator`           | `string`   | When `source` is a comma-separated list of names, this separator is placed between concatenated extracted data values. | `";"`          | no       |
+| `source`              | `string`   | Name or comma-separated list of names from extracted data to match. If empty or not defined, it uses the log message.  | `""`           | no       |
+| `value`               | `string`   | If both `source` and `value` are specified, the stage drops lines where `value` exactly matches the source content.    | `""`           | no       |
+
+The `expression` field must be a RE2 regular expression string.
 
-The `expression` field must be a RE2 regex string.
-* If `source` is empty or not provided, the regex attempts to match the log line itself.
-* If `source` is a single name, the regex attempts to match the corresponding value from the extracted map.
-* If `source` is a comma-separated list of names, the corresponding values from the extracted map are concatenated using `separator` and the regex attempts to match the concatenated string.
+* If `source` is empty or not provided, the regular expression attempts to match the log line itself.
+* If `source` is a single name, the regular expression attempts to match the corresponding value from the extracted map.
+* If `source` is a comma-separated list of names, the corresponding values from the extracted map are concatenated using `separator` and the regular expression attempts to match the concatenated string.
 
 The `value` field can only work with values from the extracted map, and must be specified together with `source`.
+
 * If `source` is a single name, the entries are dropped when there is an exact match between the corresponding value from the extracted map and the `value`.
 * If `source` is a comma-separated list of names, the entries are dropped when the `value` matches the `source` values from extracted data, concatenated using the `separator`.
 
-Whenever an entry is dropped, the metric `loki_process_dropped_lines_total` is incremented. By default, the reason label is `"drop_stage"`, but you can provide a custom label using the `drop_counter_reason` argument.
+Whenever an entry is dropped, the metric `loki_process_dropped_lines_total` is incremented.
+By default, the reason label is `"drop_stage"`, but you can provide a custom label using the `drop_counter_reason` argument.
 
 The following stage drops log entries that contain the word `debug` _and_ are longer than 1KB.
 
@@ -223,7 +226,7 @@ stage.drop {
 }
 ```
 
-On the following example, we define multiple `drop` blocks so `loki.process` drops entries that are either 24h or older, are longer than 8KB, _or_ the extracted value of 'app' is equal to foo.
+The following example defines multiple `drop` blocks so `loki.process` drops entries that are either 24h or older, are longer than 8KB, _or_ the extracted value of `app` is equal to `example`.
 
 ```alloy
 stage.drop {
@@ -238,29 +241,29 @@ stage.drop {
 
 stage.drop {
     source = "app"
-    value  = "foo"
+    value  = "example"
 }
 ```
 
-### stage.eventlogmessage block
+### `stage.eventlogmessage`
 
-Deprecated in favor of the [stage.windowsevent block][stage.windowsevent].
+Deprecated in favor of the [`stage.windowsevent`][stage.windowsevent] block.
 
 The `eventlogmessage` stage extracts data from the Message string that appears in the Windows Event Log.
 
 The following arguments are supported:
 
-| Name                  | Type     | Description                                            | Default   | Required |
-|-----------------------|----------|--------------------------------------------------------|-----------|----------|
-| `source`              | `string` | Name of the field in the extracted data to parse.      | `message` | no       |
-| `overwrite_existing`  | `bool`   | Whether to overwrite existing extracted data fields.   | `false`   | no       |
-| `drop_invalid_labels` | `bool`   | Whether to drop fields that are not valid label names. | `false`   | no       |
+| Name                  | Type     | Description                                           | Default   | Required |
+| --------------------- | -------- | ----------------------------------------------------- | --------- | -------- |
+| `drop_invalid_labels` | `bool`   | Whether to drop fields that aren't valid label names. | `false`   | no       |
+| `overwrite_existing`  | `bool`   | Whether to overwrite existing extracted data fields.  | `false`   | no       |
+| `source`              | `string` | Name of the field in the extracted data to parse.     | `message` | no       |
 
-When `overwrite_existing` is set to `true`, the stage overwrites existing extracted data fields with the same name.
-If set to `false`, the `_extracted` suffix will be appended to an already existing field name.
+When `drop_invalid_labels` is set to `true`, the stage drops fields that aren't valid label names.
+If set to `false`, the stage automatically converts them into valid labels replacing invalid characters with underscores.
 
-When `drop_invalid_labels` is set to `true`, the stage drops fields that are not valid label names.
-If set to `false`, the stage will automatically convert them into valid labels replacing invalid characters with underscores.
+When `overwrite_existing` is set to `true`, the stage overwrites existing extracted data fields with the same name.
+If set to `false`, the `_extracted` suffix is appended to an existing field name.
 
 The `eventlogmessage` stage only extracts lines with the key:value format.
 All non-alpha characters in the key are replaced with underscores.
@@ -283,22 +286,197 @@ stage.eventlogmessage {
 ```
 
 Given the following log line:
-```
+
+```text
 {"event_id": 1, "Overwritten": "old", "message": "Message type:\r\nOverwritten: new\r\nImage: C:\\Users\\User\\alloy.exe"}
 ```
 
 The first stage would create the following key-value pairs in the set of extracted data:
 
-- `message`: `Message type:\r\nOverwritten: new\r\nImage: C:\Users\User\alloy.exe`
-- `Overwritten`: `old`
+* `message`: `Message type:\r\nOverwritten: new\r\nImage: C:\Users\User\alloy.exe`
+* `Overwritten`: `old`
+
+The second stage parses the value of `message` from the extracted data and appends or overwrites the following key-value pairs to the set of extracted data:
+
+* `Image`: `C:\\Users\\User\\alloy.exe`
+* `Message_type`: (empty string)
+* `Overwritten`: `new`
+
+### `stage.geoip`
+
+The `stage.geoip` inner block configures a processing stage that reads an IP address and populates the shared map with `geoip` fields. The Maxmind GeoIP2 database is used for the lookup.
+
+The following arguments are supported:
+
+| Name             | Type          | Description                                                         | Default | Required |
+| ---------------- | ------------- | ------------------------------------------------------------------- | ------- | -------- |
+| `db`             | `string`      | Path to the Maxmind DB file.                                        |         | yes      |
+| `source`         | `string`      | IP from extracted data to parse.                                    |         | yes      |
+| `custom_lookups` | `map(string)` | Key-value pairs of JMESPath expressions.                            |         | no       |
+| `db_type`        | `string`      | Maxmind DB type. Allowed values are `"city"`, `"asn"`, `"country"`. |         | no       |
+
+#### GeoIP with City database example
+
+```alloy
+{"log":"log message","client_ip":"34.120.177.193"}
+
+loki.process "example" {
+    stage.json {
+        expressions = {ip = "client_ip"}
+    }
+
+    stage.geoip {
+        source  = "ip"
+        db      = "/path/to/db/GeoLite2-City.mmdb"
+        db_type = "city"
+    }
+
+    stage.labels {
+        values = {
+            geoip_city_name          = "",
+            geoip_country_name       = "",
+            geoip_country_code       = "",
+            geoip_continent_name     = "",
+            geoip_continent_code     = "",
+            geoip_location_latitude  = "",
+            geoip_location_longitude = "",
+            geoip_postal_code        = "",
+            geoip_timezone           = "",
+            geoip_subdivision_name   = "",
+            geoip_subdivision_code   = "",
+        }
+    }
+}
+```
+
+The `json` stage extracts the IP address from the `client_ip` key in the log line.
+Then the extracted `ip` value is given as source to `geoip` stage.
+The `geoip` stage performs a lookup on the IP and populates the following fields in the shared map which are added as labels using the `labels` stage.
+
+The extracted data from the IP used in this example:
+
+```text
+geoip_city_name: Kansas City
+geoip_country_name: United States
+geoip_country_code: US
+geoip_continent_name: North America
+geoip_continent_code: NA
+geoip_location_latitude: 39.1027
+geoip_location_longitude: -94.5778
+geoip_postal_code: 64184
+geoip_timezone: America/Chicago
+geoip_subdivision_name: Missouri
+geoip_subdivision_code: MO
+```
+
+#### GeoIP with ASN (Autonomous System Number) database example
+
+```alloy
+loki.process "example" {
+    stage.json {
+        expressions = {ip = "client_ip"}
+    }
+
+    stage.geoip {
+        source  = "ip"
+        db      = "/path/to/db/GeoIP2-ASN.mmdb"
+        db_type = "asn"
+    }
+
+    stage.labels {
+        values = {
+            geoip_autonomous_system_number       = "",
+            geoip_autonomous_system_organization = "",
+        }
+    }
+}
+```
+
+The `json` stage extracts the IP address from the `client_ip` key in the log line.
+Then the extracted `ip` value is given as source to `geoip` stage. The `geoip` stage performs a lookup on the IP and populates the shared map.
+
+The extracted data from the IP used in this example:
+
+```text
+geoip_autonomous_system_number: 396982
+geoip_autonomous_system_organization: GOOGLE-CLOUD-PLATFORM
+```
+
+#### GeoIP with Country database example
+
+```alloy
+{"log":"log message","client_ip":"34.120.177.193"}
+
+loki.process "example" {
+    stage.json {
+        expressions = {ip = "client_ip"}
+    }
+
+    stage.geoip {
+        source  = "ip"
+        db      = "/path/to/db/GeoLite2-Country.mmdb"
+        db_type = "country"
+    }
+
+    stage.labels {
+        values = {
+            geoip_country_name       = "",
+            geoip_country_code       = "",
+            geoip_continent_name     = "",
+            geoip_continent_code     = "",
+        }
+    }
+}
+```
+
+The `json` stage extracts the IP address from the `client_ip` key in the log line.
+Then the extracted `ip` value is given as source to `geoip` stage.
+The `geoip` stage performs a lookup on the IP and populates the following fields in the shared map which are added as labels using the `labels` stage.
 
-The second stage will parse the value of `message` from the extracted data and append/overwrite the following key-value pairs to the set of extracted data:
+The extracted data from the IP used in this example:
+
+```text
+geoip_country_name: United States
+geoip_country_code: US
+geoip_continent_name: North America
+geoip_continent_code: NA
+```
+
+#### GeoIP with custom fields example
+
+If the MMDB file used is enriched with custom data, for example, private IP addresses as explained in [the Maxmind blog post](https://github.com/maxmind/mmdb-from-go-blogpost), then it can be extracted from the record using the `custom_lookups` attribute.
 
-- `Image`: `C:\\Users\\User\\alloy.exe`
-- `Message_type`: (empty string)
-- `Overwritten`: `new`
+```alloy
+loki.process "example" {
+    stage.json {
+        expressions = {ip = "client_ip"}
+    }
 
-### stage.json block
+    stage.geoip {
+        source         = "ip"
+        db             = "/path/to/db/GeoIP2-Enriched.mmdb"
+        db_type        = "city"
+        custom_lookups = {
+            "department"  = "MyCompany.DeptName",
+            "parent_vnet" = "MyCompany.ParentVNet",
+            "subnet"      = "MyCompany.Subnet",
+        }
+    }
+
+    stage.labels {
+        values = {
+            department  = "",
+            parent_vnet = "",
+            subnet      = "",
+        }
+    }
+}
+```
+
+The `json` stage extracts the IP address from the `client_ip` key in the log line.
+Then the extracted `ip` value is given as source to `geoip` stage. The `geoip` stage performs a lookup on the IP and populates the shared map with the data from the city database results in addition to the custom lookups. Lastly, the custom lookup fields from the shared map are added as labels.
+
+### `stage.json`
 
 The `stage.json` inner block configures a JSON processing stage that parses incoming log lines or previously extracted values as JSON and uses [JMESPath expressions][] to extract new values from them.
 
@@ -306,19 +484,19 @@ The `stage.json` inner block configures a JSON processing stage that parses inco
 
 The following arguments are supported:
 
-| Name             | Type          | Description                                            | Default | Required |
-| ---------------- | ------------- | ------------------------------------------------------ | ------- | -------- |
-| `expressions`    | `map(string)` | Key-value pairs of JMESPath expressions.               |         | yes      |
-| `source`         | `string`      | Source of the data to parse as JSON.                   | `""`    | no       |
-| `drop_malformed` | `bool`        | Drop lines whose input cannot be parsed as valid JSON. | `false` | no       |
-
-When configuring a JSON stage, the `source` field defines the source of data to parse as JSON.
-By default, this is the log line itself, but it can also be a previously extracted value.
+| Name             | Type          | Description                                           | Default | Required |
+| ---------------- | ------------- | ----------------------------------------------------- | ------- | -------- |
+| `expressions`    | `map(string)` | Key-value pairs of JMESPath expressions.              |         | yes      |
+| `drop_malformed` | `bool`        | Drop lines whose input can't be parsed as valid JSON. | `false` | no       |
+| `source`         | `string`      | Source of the data to parse as JSON.                  | `""`    | no       |
 
 The `expressions` field is the set of key-value pairs of JMESPath expressions to run.
 The map key defines the name with which the data is extracted, while the map value is the expression used to populate the value.
 
-Here's a given log line and two JSON stages to run.
+When configuring a JSON stage, the `source` field defines the source of data to parse as JSON.
+By default, this is the log line itself, but it can also be a previously extracted value.
+
+The following example shows a given log line and two JSON stages.
 
 ```alloy
 {"log":"log message\n","extra":"{\"user\":\"alloy\"}"}
@@ -336,19 +514,21 @@ loki.process "username" {
 ```
 
 In this example, the first stage uses the log line as the source and populates these values in the shared map.
-An empty expression means using the same value as the key (so `extra="extra"`).
-```
+An empty expression means using the same value as the key, for example `extra="extra"`.
+
+```text
 output: log message\n
 extra: {"user": "alloy"}
 ```
 
 The second stage uses the value in `extra` as the input and appends the following key-value pair to the set of extracted data.
-```
+
+```text
 username: alloy
 ```
 
 {{< admonition type="note" >}}
-Due to a limitation of the upstream jmespath library, you must wrap any string that contains a hyphen `-` in quotes so that it's not considered a numerical expression.
+Due to a limitation of the upstream `jmespath` library, you must wrap any string that contains a hyphen `-` in quotes so that it's not considered a numerical expression.
 
 If you don't use quotes to wrap a string that contains a hyphen, you will get errors like: `Unexpected token at the end of the expression: tNumber`
 
@@ -358,10 +538,9 @@ You can use one of two options to circumvent this issue:
 1. A backtick quote. For example: ``http_user_agent = `"request_User-Agent"` ``
 {{< /admonition >}}
 
-### stage.label_drop block
+### `stage.label_drop`
 
-The `stage.label_drop` inner block configures a processing stage that drops labels
-from incoming log entries.
+The `stage.label_drop` inner block configures a processing stage that drops labels from incoming log entries.
 
 The following arguments are supported:
 
@@ -375,7 +554,7 @@ stage.label_drop {
 }
 ```
 
-### stage.label_keep block
+### `stage.label_keep`
 
 The `stage.label_keep` inner block configures a processing stage that filters the label set of an incoming log entry down to a subset.
 
@@ -385,14 +564,13 @@ The following arguments are supported:
 | -------- | -------------- | ------------------------------------------- | ------- | -------- |
 | `values` | `list(string)` | Configures a `label_keep` processing stage. | `{}`    | no       |
 
-
 ```alloy
 stage.label_keep {
     values = [ "kubernetes_pod_name", "kubernetes_pod_container_name" ]
 }
 ```
 
-### stage.labels block
+### `stage.labels`
 
 The `stage.labels` inner block configures a labels processing stage that can read data from the extracted values map and set new labels on incoming log entries.
 
@@ -403,7 +581,7 @@ The following arguments are supported:
 | `values` | `map(string)` | Configures a `labels` processing stage. | `{}`    | no       |
 
 In a labels stage, the map's keys define the label to set and the values are how to look them up.
-If the value is empty, it is inferred to be the same as the key.
+If the value is empty, it's inferred to be the same as the key.
 
 ```alloy
 stage.labels {
@@ -414,29 +592,7 @@ stage.labels {
 }
 ```
 
-### stage.structured_metadata block
-
-The `stage.structured_metadata` inner block configures a stage that can read data from the extracted values map and add them to log entries as structured metadata.
-
-The following arguments are supported:
-
-| Name     | Type          | Description                                                                 | Default | Required |
-| -------- | ------------- |-----------------------------------------------------------------------------| ------- | -------- |
-| `values` | `map(string)` | Specifies the list of labels to add from extracted values map to log entry. | `{}`    | no       |
-
-In a structured_metadata stage, the map's keys define the label to set and the values are how to look them up.
-If the value is empty, it is inferred to be the same as the key.
-
-```alloy
-stage.structured_metadata {
-    values = {
-      env  = "",         // Sets up an 'env' property to structured metadata, based on the 'env' extracted value.
-      user = "username", // Sets up a 'user' property to structured metadata, based on the 'username' extracted value.
-    }
-}
-```
-
-### stage.limit block
+### `stage.limit`
 
 The `stage.limit` inner block configures a rate-limiting stage that throttles logs based on several options.
 
@@ -444,14 +600,16 @@ The following arguments are supported:
 
 | Name                  | Type     | Description                                                                      | Default | Required |
 | --------------------- | -------- | -------------------------------------------------------------------------------- | ------- | -------- |
-| `rate`                | `number` | The maximum rate of lines per second that the stage forwards.                    |         | yes      |
 | `burst`               | `number` | The maximum number of burst lines that the stage forwards.                       |         | yes      |
+| `rate`                | `number` | The maximum rate of lines per second that the stage forwards.                    |         | yes      |
 | `by_label_name`       | `string` | The label to use when rate-limiting on a label name.                             | `""`    | no       |
 | `drop`                | `bool`   | Whether to discard or backpressure lines that exceed the rate limit.             | `false` | no       |
 | `max_distinct_labels` | `number` | The number of unique values to keep track of when rate-limiting `by_label_name`. | `10000` | no       |
 
-The rate limiting is implemented as a "token bucket" of size `burst`, initially full and refilled at `rate` tokens per second.
-Each received log entry consumes one token from the bucket. When `drop` is set to true, incoming entries that exceed the rate-limit are dropped, otherwise they are queued until more tokens are available.
+The rate limiting is a "token bucket" of size `burst`.
+It's initially full and refilled at `rate` tokens per second.
+Each received log entry consumes one token from the bucket.
+When `drop` is set to true, incoming entries that exceed the rate-limit are dropped, otherwise they're queued until more tokens are available.
 
 ```alloy
 stage.limit {
@@ -464,7 +622,7 @@ If `by_label_name` is set, then `drop` must be set to `true`.
 This enables the stage to rate-limit not by the number of lines but by the number of labels.
 
 The following example rate-limits entries from each unique `namespace` value independently.
-Any entries without the `namespace` label are not rate-limited.
+Any entries without the `namespace` label aren't rate-limited.
 The stage keeps track of up to `max_distinct_labels` unique values, defaulting at 10000.
 
 ```alloy
@@ -477,29 +635,30 @@ stage.limit {
 }
 ```
 
-### stage.logfmt block
+### `stage.logfmt`
 
 The `stage.logfmt` inner block configures a processing stage that reads incoming log lines as logfmt and extracts values from them.
 
 The following arguments are supported:
 
-| Name      | Type          | Description                                  | Default | Required |
-| --------- | ------------- | -------------------------------------------- | ------- | -------- |
-| `mapping` | `map(string)` | Key-value pairs of logmft fields to extract. |         | yes      |
-| `source`  | `string`      | Source of the data to parse as logfmt.       | `""`    | no       |
+| Name      | Type          | Description                                    | Default | Required |
+| --------- | ------------- | ---------------------------------------------- | ------- | -------- |
+| `mapping` | `map(string)` | Key-value pairs of `logmft` fields to extract. |         | yes      |
+| `source`  | `string`      | Source of the data to parse as `logfmt`.       | `""`    | no       |
 
+The `source` field defines the source of data to parse as `logfmt`.
+When `source` is missing or empty, the stage parses the log line itself, but it can also be used to parse a previously extracted value.
 
-The `source` field defines the source of data to parse as logfmt. When `source` is missing or empty, the stage parses the log line itself, but it can also be used to parse a previously extracted value.
-
-This stage uses the [go-logfmt][] unmarshaler, so that numeric or boolean types are unmarshalled into their correct form. The stage does not perform any other type conversions.
-If the extracted value is a complex type, it is treated as a string.
+This stage uses the [go-logfmt][] unmarshaler, so that numeric or boolean types are unmarshalled into their correct form.
+The stage doesn't perform any other type conversions.
+If the extracted value is a complex type, it's treated as a string.
 
 [go-logfmt]: https://github.com/go-logfmt/logfmt
 
-Let's see how this works on the following log line and stages.
+The following log line and stages demonstrates how this works.
 
-```
-time=2012-11-01T22:08:41+00:00 app=loki level=WARN duration=125 message="this is a log line" extra="user=foo"
+```alloy
+time=2012-11-01T22:08:41+00:00 app=loki level=WARN duration=125 message="this is a log line" extra="user=example_name"
 
 stage.logfmt {
     mapping = { "extra" = "" }
@@ -511,39 +670,34 @@ stage.logfmt {
 }
 ```
 
-The first stage parses the log line itself and inserts the `extra` key in the set of extracted data, with the value of `user=foo`.
+The first stage parses the log line itself and inserts the `extra` key in the set of extracted data, with the value of `user=example_name`.
 
-The second stage parses the contents of `extra` and appends the `username: foo` key-value pair to the set of extracted data.
+The second stage parses the contents of `extra` and appends the `username: example_name` key-value pair to the set of extracted data.
 
-### stage.luhn block
+### `stage.luhn`
 
-The `stage.luhn` inner block configures a processing stage that reads incoming
-log lines and redacts strings that match a Luhn algorithm.
+The `stage.luhn` inner block configures a processing stage that reads incoming log lines and redacts strings that match a Luhn algorithm.
 
-The [Luhn algorithm][] is a simple checksum formula used to validate various
-identification numbers, such as credit card numbers, IMEI numbers, National
-Provider Identifier numbers in the US, and Canadian Social Insurance Numbers.
+The [Luhn algorithm][] is a simple checksum formula used to validate various identification numbers, such as credit card numbers, IMEI numbers, National Provider Identifier numbers in the USA, and Canadian Social Insurance Numbers.
 Many Payment Card Industry environments require these numbers to be redacted.
 
 [Luhn algorithm]: https://en.wikipedia.org/wiki/Luhn_algorithm
 
 The following arguments are supported:
 
-| Name          | Type          | Description                                    | Default          | Required |
-| ------------- | ------------- | ---------------------------------------------- | ---------------- | -------- |
-| `replacement` | `string`      | String to substitute the matched patterns with | `"**REDACTED**"` | no      |
-| `source`      | `string`      | Source of the data to parse.                   | `""`             | no       |
-| `min_length`   | `int`         | Minimum length of digits to consider           | `13`             | no       |
+| Name          | Type     | Description                                    | Default          | Required |
+| ------------- | -------- | ---------------------------------------------- | ---------------- | -------- |
+| `min_length`  | `int`    | Minimum length of digits to consider           | `13`             | no       |
+| `replacement` | `string` | String to substitute the matched patterns with | `"**REDACTED**"` | no       |
+| `source`      | `string` | Source of the data to parse.                   | `""`             | no       |
 
-
-The `source` field defines the source of data to search. When `source` is
-missing or empty, the stage parses the log line itself, but it can also be used
-to parse a previously extracted value.
+The `source` field defines the source of data to search.
+When `source` is missing or empty, the stage parses the log line itself, but it can also be used to parse a previously extracted value.
 
 The following example log line contains an approved credit card number.
 
-```
-time=2012-11-01T22:08:41+00:00 app=loki level=WARN duration=125 message="credit card approved 4032032513548443" extra="user=foo"
+```alloy
+time=2012-11-01T22:08:41+00:00 app=loki level=WARN duration=125 message="credit card approved 4032032513548443" extra="user=example_name"
 
 stage.luhn {
     replacement = "**DELETED**"
@@ -552,11 +706,11 @@ stage.luhn {
 
 The stage parses the log line, redacts the credit card number, and produces the following updated log line:
 
-```
-time=2012-11-01T22:08:41+00:00 app=loki level=INFO duration=125 message="credit card approved **DELETED**" extra="user=foo"
+```text
+time=2012-11-01T22:08:41+00:00 app=loki level=INFO duration=125 message="credit card approved **DELETED**" extra="user=example_name"
 ```
 
-### stage.match block
+### `stage.match`
 
 The `stage.match` inner block configures a filtering stage that can conditionally either apply a nested set of processing stages or drop an entry when a log entry matches a configurable LogQL stream selector and filter expressions.
 
@@ -565,27 +719,26 @@ The following arguments are supported:
 | Name                  | Type     | Description                                                                                           | Default         | Required |
 | --------------------- | -------- | ----------------------------------------------------------------------------------------------------- | --------------- | -------- |
 | `selector`            | `string` | The LogQL stream selector and line filter expressions to use.                                         |                 | yes      |
-| `pipeline_name`       | `string` | A custom name to use for the nested pipeline.                                                         | `""`            | no       |
 | `action`              | `string` | The action to take when the selector matches the log line. Supported values are `"keep"` and `"drop"` | `"keep"`        | no       |
 | `drop_counter_reason` | `string` | A custom reason to report for dropped lines.                                                          | `"match_stage"` | no       |
+| `pipeline_name`       | `string` | A custom name to use for the nested pipeline.                                                         | `""`            | no       |
 
 {{< admonition type="note" >}}
-The filters do not include label filter expressions such as `| label == "foobar"`.
+The filters don't include label filter expressions such as `| label == "examplelabel"`.
 {{< /admonition >}}
 
 The `stage.match` block supports a number of `stage.*` inner blocks, like the top-level block.
 These are used to construct the nested set of stages to run if the selector matches the labels and content of the log entries.
 It supports all the same `stage.NAME` blocks as the in the top level of the `loki.process` component.
 
-
 If the specified action is `"drop"`, the metric `loki_process_dropped_lines_total` is incremented with every line dropped.
 By default, the reason label is `"match_stage"`, but a custom reason can be provided by using the `drop_counter_reason` argument.
 
-Let's see this in action, with the following log lines and stages:
+The following example log lines and stages show how this works.
 
-```
-{ "time":"2023-01-18T17:08:41+00:00", "app":"foo", "component": ["parser","type"], "level" : "WARN", "message" : "app1 log line" }
-{ "time":"2023-01-18T17:08:42+00:00", "app":"bar", "component": ["parser","type"], "level" : "ERROR", "message" : "foo noisy error" }
+```alloy
+{ "time":"2023-01-18T17:08:41+00:00", "app":"example1", "component": ["parser","type"], "level" : "WARN", "message" : "app1 log line" }
+{ "time":"2023-01-18T17:08:42+00:00", "app":"example2", "component": ["parser","type"], "level" : "ERROR", "message" : "example noisy error" }
 
 stage.json {
     expressions = { "appname" = "app" }
@@ -596,7 +749,7 @@ stage.labels {
 }
 
 stage.match {
-    selector = "{applbl=\"foo\"}"
+    selector = "{applbl=\"examplelabel\"}"
 
     stage.json {
         expressions = { "msg" = "message" }
@@ -624,120 +777,119 @@ stage.output {
 
 The first two stages parse the log lines as JSON, decode the `app` value into the shared extracted map as `appname`, and use its value as the `applbl` label.
 
-The third stage uses the LogQL selector to only execute the nested stages on lines where the `applbl="foo"`.
+The third stage uses the LogQL selector to only execute the nested stages on lines where the `applbl="examplelabel"`.
 So, for the first line, the nested JSON stage adds `msg="app1 log line"` into the extracted map.
 
-The fourth stage uses the LogQL selector to only execute on lines where `applbl="qux"`; that means it won't match any of the input, and the nested JSON stage does not run.
+The fourth stage uses the LogQL selector to only execute on lines where `applbl="qux"`. This means it won't match any of the input, and the nested JSON stage doesn't run.
 
-The fifth stage drops entries from lines where `applbl` is set to 'bar' and the line contents matches the regex `.*noisy error.*`.
+The fifth stage drops entries from lines where `applbl` is set to 'example2' and the line contents matches the regex `.*noisy error.*`.
 It also increments the `loki_process_dropped_lines_total` metric with a label `drop_counter_reason="discard_noisy_errors"`.
 
 The final output stage changes the contents of the log line to be the value of `msg` from the extracted map. In this case, the first log entry's content is changed to `app1 log line`.
 
-### stage.metrics block
+### `stage.metrics`
 
-The `stage.metrics` inner block configures stage that allows to define and update metrics based on values from the shared extracted map.
-The created metrics are available at {{< param "PRODUCT_NAME" >}}'s root /metrics endpoint.
+The `stage.metrics` inner block configures stage that allows you to define and update metrics based on values from the shared extracted map.
+The created metrics are available at the {{< param "PRODUCT_NAME" >}} root `/metrics` endpoint.
 
-The `stage.metrics` block does not support any arguments and is only configured via a number of nested inner `metric.*` blocks, one for each metric that should be generated.
+The `stage.metrics` block doesn't support any arguments and is only configured via a number of nested inner `metric.*` blocks, one for each metric that should be generated.
 
 The following blocks are supported inside the definition of `stage.metrics`:
 
-| Hierarchy        | Block                | Description                   | Required |
-| ---------------- | -------------------- | ----------------------------- | -------- |
-| metric.counter   | [metric.counter][]   | Defines a `counter` metric.   | no       |
-| metric.gauge     | [metric.gauge][]     | Defines a `gauge` metric.     | no       |
-| metric.histogram | [metric.histogram][] | Defines a `histogram` metric. | no       |
+| Block                                  | Description                   | Required |
+| -------------------------------------- | ----------------------------- | -------- |
+| [`metric.counter`][metric.counter]     | Defines a `counter` metric.   | no       |
+| [`metric.gauge`][metric.gauge]         | Defines a `gauge` metric.     | no       |
+| [`metric.histogram`][metric.histogram] | Defines a `histogram` metric. | no       |
 
 {{< admonition type="note" >}}
 The metrics will be reset if you reload the {{< param "PRODUCT_NAME" >}} configuration file.
 {{< /admonition >}}
 
-[metric.counter]: #metriccounter-block
-[metric.gauge]: #metricgauge-block
-[metric.histogram]: #metrichistogram-block
+[metric.counter]: #metriccounter
+[metric.gauge]: #metricgauge
+[metric.histogram]: #metrichistogram
 
-
-#### metric.counter block
+#### `metric.counter`
 
 Defines a metric whose value only goes up.
 
 The following arguments are supported:
 
 | Name                | Type       | Description                                                                                               | Default                  | Required |
-|---------------------|------------|-----------------------------------------------------------------------------------------------------------|--------------------------|----------|
-| `name`              | `string`   | The metric name.                                                                                          |                          | yes      |
+| ------------------- | ---------- | --------------------------------------------------------------------------------------------------------- | ------------------------ | -------- |
 | `action`            | `string`   | The action to take. Valid actions are `inc` and `add`.                                                    |                          | yes      |
+| `name`              | `string`   | The metric name.                                                                                          |                          | yes      |
+| `count_entry_bytes` | `bool`     | If set to true, counts all log lines bytes.                                                               | `false`                  | no       |
 | `description`       | `string`   | The metric's description and help text.                                                                   | `""`                     | no       |
-| `source`            | `string`   | Key from the extracted data map to use for the metric. Defaults to the metric name.                       | `""`                     | no       |
-| `prefix`            | `string`   | The prefix to the metric name.                                                                            | `"loki_process_custom_"` | no       |
+| `match_all`         | `bool`     | If set to true, all log lines are counted, without attempting to match the `source` to the extracted map. | `false`                  | no       |
 | `max_idle_duration` | `duration` | Maximum amount of time to wait until the metric is marked as 'stale' and removed.                         | `"5m"`                   | no       |
+| `prefix`            | `string`   | The prefix to the metric name.                                                                            | `"loki_process_custom_"` | no       |
+| `source`            | `string`   | Key from the extracted data map to use for the metric. Defaults to the metric name.                       | `""`                     | no       |
 | `value`             | `string`   | If set, the metric only changes if `source` exactly matches the `value`.                                  | `""`                     | no       |
-| `match_all`         | `bool`     | If set to true, all log lines are counted, without attempting to match the `source` to the extracted map. | `false`                  | no       |
-| `count_entry_bytes` | `bool`     | If set to true, counts all log lines bytes.                                                               | `false`                  | no       |
 
-A counter cannot set both `match_all` to true _and_ a `value`.
-A counter cannot set `count_entry_bytes` without also setting `match_all=true` _or_ `action=add`.
-The valid `action` values are `inc` and `add`. The `inc` action increases the metric value by 1 for each log line that passed the filter.
+A counter can't set both `match_all` to true _and_ a `value`.
+A counter can't set `count_entry_bytes` without also setting `match_all=true` _or_ `action=add`.
+The valid `action` values are `inc` and `add`.
+The `inc` action increases the metric value by 1 for each log line that passed the filter.
 The `add` action converts the extracted value to a positive float and adds it to the metric.
 
+#### `metric.gauge`
 
-#### metric.gauge block
 Defines a gauge metric whose value can go up or down.
 
 The following arguments are supported:
 
 | Name                | Type       | Description                                                                         | Default                  | Required |
-|---------------------|------------|-------------------------------------------------------------------------------------|--------------------------|----------|
-| `name`              | `string`   | The metric name.                                                                    |                          | yes      |
+| ------------------- | ---------- | ----------------------------------------------------------------------------------- | ------------------------ | -------- |
 | `action`            | `string`   | The action to take. Valid actions are  `inc`, `dec`, `set`, `add`, or `sub`.        |                          | yes      |
+| `name`              | `string`   | The metric name.                                                                    |                          | yes      |
 | `description`       | `string`   | The metric's description and help text.                                             | `""`                     | no       |
-| `source`            | `string`   | Key from the extracted data map to use for the metric. Defaults to the metric name. | `""`                     | no       |
-| `prefix`            | `string`   | The prefix to the metric name.                                                      | `"loki_process_custom_"` | no       |
 | `max_idle_duration` | `duration` | Maximum amount of time to wait until the metric is marked as 'stale' and removed.   | `"5m"`                   | no       |
+| `prefix`            | `string`   | The prefix to the metric name.                                                      | `"loki_process_custom_"` | no       |
+| `source`            | `string`   | Key from the extracted data map to use for the metric. Defaults to the metric name. | `""`                     | no       |
 | `value`             | `string`   | If set, the metric only changes if `source` exactly matches the `value`.            | `""`                     | no       |
 
-
 The valid `action` values are `inc`, `dec`, `set`, `add`, or `sub`.
 `inc` and `dec` increment and decrement the metric's value by 1 respectively.
 If `set`, `add`, or `sub` is chosen, the extracted value must be convertible to a positive float and is set, added to, or subtracted from the metric's value.
 
+#### `metric.histogram`
 
-#### metric.histogram block
 Defines a histogram metric whose values are recorded in predefined buckets.
 
-
 The following arguments are supported:
 
 | Name                | Type          | Description                                                                         | Default                  | Required |
-|---------------------|---------------|-------------------------------------------------------------------------------------|--------------------------|----------|
+| ------------------- | ------------- | ----------------------------------------------------------------------------------- | ------------------------ | -------- |
+| `buckets`           | `list(float)` | Predefined buckets                                                                    |                          | yes      |
 | `name`              | `string`      | The metric name.                                                                    |                          | yes      |
-| `buckets`           | `list(float)` | Prefined buckets                                                                    |                          | yes      |
 | `description`       | `string`      | The metric's description and help text.                                             | `""`                     | no       |
-| `source`            | `string`      | Key from the extracted data map to use for the metric. Defaults to the metric name. | `""`                     | no       |
-| `prefix`            | `string`      | The prefix to the metric name.                                                      | `"loki_process_custom_"` | no       |
 | `max_idle_duration` | `duration`    | Maximum amount of time to wait until the metric is marked as 'stale' and removed.   | `"5m"`                   | no       |
+| `prefix`            | `string`      | The prefix to the metric name.                                                      | `"loki_process_custom_"` | no       |
+| `source`            | `string`      | Key from the extracted data map to use for the metric. Defaults to the metric name. | `""`                     | no       |
 | `value`             | `string`      | If set, the metric only changes if `source` exactly matches the `value`.            | `""`                     | no       |
 
-#### metrics behavior
+#### `metrics` behavior
 
-If `value` is not present, all incoming log entries match.
+If `value` isn't present, all incoming log entries match.
 
 Label values on created metrics can be dynamic, which can cause exported metrics to explode in cardinality or go stale, for example, when a stream stops receiving new logs.
-To prevent unbounded growth of the `/metrics` endpoint, any metrics which have not been updated within `max_idle_duration` are removed.
+To prevent unbounded growth of the `/metrics` endpoint, any metrics which haven't been updated within `max_idle_duration` are removed.
 The `max_idle_duration` must be greater or equal to `"1s"`, and it defaults to `"5m"`.
 
 The metric values extracted from the log data are internally converted to floats.
 The supported values are the following:
 
-* integer
-* floating point number
-* string - Two types of string format are supported:
-    * Strings that represent floating point numbers, for example, "0.804" is converted to 0.804.
-    * Duration format strings. Valid time units are “ns”, “us”, “ms”, “s”, “m”, “h”. A value in this format is converted to a floating point number of seconds, for example, "0.5ms" is converted to 0.0005.
-* boolean:
-    * true is converted to 1.
-    * false is converted to 0.
+* Integer
+* Floating point number
+* String - Two types of string format are supported:
+  * Strings that represent floating point numbers, for example, "0.804" is converted to 0.804.
+  * Duration format strings. Valid time units are `"ns"`, `"us"`, `"ms"`, `"s"`, `"m"`, `"h"`.
+    A value in this format is converted to a floating point number of seconds, for example, `"0.5ms"` is converted to `0.0005`.
+* Boolean:
+  * `true` is converted to `1`.
+  * `false` is converted to `0`.
 
 The following pipeline creates a counter which increments every time any log line is received by using the `match_all` parameter.
 The pipeline creates a second counter which adds the byte size of these log lines by using the `count_entry_bytes` parameter.
@@ -771,7 +923,7 @@ stage.metrics {
 }
 ```
 
-Here, the first stage uses a regex to extract text in the format `order_status=<string>` in the log line.
+Here, the first stage uses a regular expression to extract text in the format `order_status=<string>` in the log line.
 The second stage, defines a counter which increments the `successful_orders_total` and `failed_orders_total` based on the previously extracted values.
 
 ```alloy
@@ -828,7 +980,7 @@ stage.metrics {
 }
 ```
 
-### stage.multiline block
+### `stage.multiline`
 
 The `stage.multiline` inner block merges multiple lines into a single block before passing it on to the next stage in the pipeline.
 
@@ -837,21 +989,19 @@ The following arguments are supported:
 | Name            | Type       | Description                                        | Default | Required |
 | --------------- | ---------- | -------------------------------------------------- | ------- | -------- |
 | `firstline`     | `string`   | Name from extracted data to use for the log entry. |         | yes      |
-| `max_wait_time` | `duration` | The maximum time to wait for a multiline block.    | `"3s"`  | no       |
 | `max_lines`     | `number`   | The maximum number of lines a block can have.      | `128`   | no       |
-
+| `max_wait_time` | `duration` | The maximum time to wait for a multiline block.    | `"3s"`  | no       |
 
 A new block is identified by the RE2 regular expression passed in `firstline`.
 
-
 Any line that does _not_ match the expression is considered to be part of the block of the previous match.
 If no new logs arrive with `max_wait_time`, the block is sent on.
 The `max_lines` field defines the maximum number of lines a block can have.
 If this is exceeded, a new block is started.
 
-Let's see how this works in practice with an example stage and a stream of log entries from a Flask web service.
+The following example stage and stream of log entries from a Flask web service show how this works.
 
-```
+```text
 stage.multiline {
     firstline     = "^\\[\\d{4}-\\d{2}-\\d{2} \\d{1,2}:\\d{2}:\\d{2}\\]"
     max_wait_time = "10s"
@@ -882,9 +1032,9 @@ Exception: Sorry, this route always breaks
 All 'blocks' that form log entries of separate web requests start with a timestamp in square brackets.
 The stage detects this with the regular expression in `firstline` to collapse all lines of the traceback into a single block and thus a single Loki log entry.
 
-### stage.output block
+### `stage.output`
 
-The `stage.output` inner block configures a processing stage that reads from the extracted map and changes the content of the log entry that is forwarded to the next component.
+The `stage.output` inner block configures a processing stage that reads from the extracted map and changes the content of the log entry that's forwarded to the next component.
 
 The following arguments are supported:
 
@@ -892,10 +1042,9 @@ The following arguments are supported:
 | -------- | -------- | -------------------------------------------------- | ------- | -------- |
 | `source` | `string` | Name from extracted data to use for the log entry. |         | yes      |
 
+The following example log line and three-stage pipeline shows how this works.
 
-Let's see how this works for the following log line and three-stage pipeline:
-
-```
+```alloy
 {"user": "John Doe", "message": "hello, world!"}
 
 stage.json {
@@ -913,14 +1062,14 @@ stage.output {
 
 The first stage extracts the following key-value pairs into the shared map:
 
-```
+```text
 user: John Doe
 message: hello, world!
 ```
 
 Then, the second stage adds `user="John Doe"` to the label set of the log entry, and the final output stage changes the log line from the original JSON to `hello, world!`.
 
-### stage.pack block
+### `stage.pack`
 
 The `stage.pack` inner block configures a transforming stage that replaces the log entry with a JSON object that embeds extracted values and labels with it.
 
@@ -939,12 +1088,13 @@ The querying capabilities of Loki make it easy to still access this data so it c
 
 For example, consider the following log entry:
 
-```
+```text
 log_line: "something went wrong"
 labels:   { "level" = "error", "env" = "dev", "user_id" = "f8fas0r" }
 ```
 
 and this processing stage:
+
 ```alloy
 stage.pack {
     labels = ["env", "user_id"]
@@ -961,13 +1111,13 @@ The stage transforms the log entry into the following JSON object, where the two
 }
 ```
 
-At query time, Loki's [`unpack` parser][unpack parser] can be used to access these embedded labels and replace the log line with the original one stored in the `_entry` field automatically.
+At query time, the Loki [`unpack` parser][unpack parser] can be used to access these embedded labels and replace the log line with the original one stored in the `_entry` field automatically.
 
 [unpack parser]: https://grafana.com/docs/loki/latest/logql/log_queries/#unpack
 
 When combining several log streams to use with the `pack` stage, you can set `ingest_timestamp` to true to avoid interlaced timestamps and out-of-order ingestion issues.
 
-### stage.regex block
+### `stage.regex`
 
 The `stage.regex` inner block configures a processing stage that parses log lines using regular expressions and uses named capture groups for adding data into the shared extracted map of values.
 
@@ -978,19 +1128,18 @@ The following arguments are supported:
 | `expression` | `string` | A valid RE2 regular expression. Each capture group must be named.  |         | yes      |
 | `source`     | `string` | Name from extracted data to parse. If empty, uses the log message. | `""`    | no       |
 
-
-The `expression` field needs to be a RE2 regex string.
+The `expression` field needs to be a RE2 regular expression string.
 Every matched capture group is added to the extracted map, so it must be named like: `(?P<name>re)`.
 The name of the capture group is then used as the key in the extracted map for the matched value.
 
-Because of how {{< param "PRODUCT_NAME" >}} syntax strings work, any backslashes in `expression` must be escaped with a double backslash; for example `"\\w"` or `"\\S+"`.
+Because of how {{< param "PRODUCT_NAME" >}} syntax strings work, any backslashes in `expression` must be escaped with a double backslash, for example, `"\\w"` or `"\\S+"`.
 
 If the `source` is empty or missing, then the stage parses the log line itself.
 If it's set, the stage parses a previously extracted value with the same name.
 
-Given the following log line and regex stage, the extracted values are shown below:
+Given the following log line and regular expression stage, the extracted values are shown below:
 
-```
+```alloy
 2019-01-01T01:00:00.000000001Z stderr P i'm a log message!
 
 stage.regex {
@@ -1003,11 +1152,11 @@ flags: P,
 content: i'm a log message
 ```
 
-On the other hand, if the `source` value is set, then the regex is applied to the value stored in the shared map under that name.
+On the other hand, if the `source` value is set, then the regular expression is applied to the value stored in the shared map under that name.
 
-Let's see what happens when the following log line is put through this two-stage pipeline:
+The following log line is put through this two-stage pipeline:
 
-```
+```alloy
 {"timestamp":"2022-01-01T01:00:00.000000001Z"}
 
 stage.json {
@@ -1021,28 +1170,28 @@ stage.regex {
 
 The first stage adds the following key-value pair into the extracted map:
 
-```
+```text
 time: 2022-01-01T01:00:00.000000001Z
 ```
 
-Then, the regex stage parses the value for time from the shared values and appends the subsequent key-value pair back into the extracted values map:
+Then, the regular expression stage parses the value for time from the shared values and appends the subsequent key-value pair back into the extracted values map:
 
-```
+```text
 year: 2022
 ```
 
-### stage.replace block
+### `stage.replace`
 
 The `stage.replace` inner block configures a stage that parses a log line using a regular expression and replaces the log line contents.
-Named capture groups in the regex also support adding data into the shared extracted map.
+Named capture groups in the regular expression also support adding data into the shared extracted map.
 
 The following arguments are supported:
 
 | Name         | Type     | Description                                                     | Default | Required |
 | ------------ | -------- | --------------------------------------------------------------- | ------- | -------- |
-| `expression` | `string` | A RE2 regular expression containing capture groups.            |         | yes      |
-| `source`     | `string` | Source of the data to parse. If empty, it uses the log message. |         | no       |
+| `expression` | `string` | A RE2 regular expression containing capture groups.             |         | yes      |
 | `replace`    | `string` | Value replaced by the capture group.                            |         | no       |
+| `source`     | `string` | Source of the data to parse. If empty, it uses the log message. |         | no       |
 
 Each capture group and named capture group in `expression` is replaced with the value given in `replace`.
 
@@ -1054,11 +1203,12 @@ The `source` field defines the source of data to parse using `expression`.
 When `source` is missing or empty, the stage parses the log line itself, but it can also be used to parse a previously extracted value.
 The replaced value is assigned back to the `source` key.
 
-Because of how {{< param "PRODUCT_NAME" >}} syntax treats backslashes in double-quoted strings, note that all backslashes in a regex expression must be escaped like `"\\w*"`.
+Because of how {{< param "PRODUCT_NAME" >}} syntax treats backslashes in double-quoted strings, all backslashes in a regular expression must be escaped like `"\\w*"`.
 
-Let's see how this works with the following log line and stage. Since `source` is omitted, the replacement occurs on the log line itself.
+The following log line and stage shows how this works.
+Since `source` is omitted, the replacement occurs on the log line itself.
 
-```
+```alloy
 2023-01-01T01:00:00.000000001Z stderr P i'm a log message who has sensitive information with password xyz!
 
 stage.replace {
@@ -1069,7 +1219,7 @@ stage.replace {
 
 The log line is transformed to
 
-```
+```text
 2023-01-01T01:00:00.000000001Z stderr P i'm a log message who has sensitive information with password *****!
 ```
 
@@ -1077,7 +1227,7 @@ If `replace` is empty, then the captured value is omitted instead.
 
 In the following example, `source` is defined.
 
-```
+```alloy
 {"time":"2023-01-01T01:00:00.000000001Z", "level": "info", "msg":"11.11.11.11 - \"POST /loki/api/push/ HTTP/1.1\" 200 932 \"-\" \"Mozilla/5.0\"}
 
 stage.json {
@@ -1093,7 +1243,7 @@ stage.replace {
 
 The JSON stage adds the following key-value pairs into the extracted map:
 
-```
+```text
 time: 2023-01-01T01:00:00.000000001Z
 level: info
 msg: "11.11.11.11 - "POST /loki/api/push/ HTTP/1.1" 200 932 "-" "Mozilla/5.0"
@@ -1103,7 +1253,7 @@ The `replace` stage acts on the `msg` value. The capture group matches against `
 
 The `msg` value is finally transformed into:
 
-```
+```text
 msg: "11.11.11.11 - "POST redacted_url HTTP/1.1" 200 932 "-" "Mozilla/5.0"
 ```
 
@@ -1111,9 +1261,9 @@ The `replace` field can use a set of templating functions, by utilizing Go's [te
 
 [text/template]: https://pkg.go.dev/text/template
 
-Let's see how this works with named capture groups with a sample log line and stage.
+The following example shows how this works with named capture groups with a sample log line and stage.
 
-```
+```alloy
 11.11.11.11 - alloy [01/Jan/2023:00:00:01 +0200]
 
 stage.replace {
@@ -1122,10 +1272,10 @@ stage.replace {
 }
 ```
 
-Since `source` is empty, the regex parses the log line itself and extracts the named capture groups to the shared map of values.
+Since `source` is empty, the regular expression parses the log line itself and extracts the named capture groups to the shared map of values.
 The `replace` field acts on these extracted values and converts them to uppercase:
 
-```
+```text
 ip: 11.11.11.11
 identd: -
 user: FRANK
@@ -1134,30 +1284,31 @@ timestamp: 01/JAN/2023:00:00:01 +0200
 
 and the log line becomes:
 
-```
+```text
 11.11.11.11 - FRANK [01/JAN/2023:00:00:01 +0200]
 ```
 
 The following list contains available functions with examples of more complex `replace` fields.
 
-```
+```text
 ToLower, ToUpper, Replace, Trim, TrimLeftTrimRight, TrimPrefix, TrimSuffix, TrimSpace, Hash, Sha2Hash, regexReplaceAll, regexReplaceAllLiteral
 
-"{{ if eq .Value \"200\" }}{{ Replace .Value \"200\" \"HttpStatusOk\" -1 }}{{ else }}{{ .Value | ToUpper }}{{ end }}"
-"*IP4*{{ .Value | Hash "salt" }}*"
+| "{{ if eq .Value \"200\" }}{{ Replace .Value \"200\" \"HttpStatusOk\" -1 }}{{ else }}{{ .Value | ToUpper }}{{ end }}" |
+| "*IP4*{{ .Value                                                                                | Hash "salt" }}*"     |
 ```
 
-### stage.sampling block
+### `stage.sampling`
 
-The `sampling` stage is used to sample the logs. Configuring the value `rate = 0.1` means that 10% of the logs will continue to be processed.
-The remaining 90% of the logs will be dropped.
+The `sampling` stage is used to sample the logs.
+Configuring the value `rate = 0.1` means that 10% of the logs continue to be processed.
+The remaining 90% of the logs are dropped.
 
 The following arguments are supported:
 
-| Name                  | Type     | Description                                                                                        | Default        | Required |
-|-----------------------|----------|----------------------------------------------------------------------------------------------------|----------------|----------|
-| `rate`                | `float`  | The sampling rate in a range of `[0, 1]`                                                           |                | yes      |
-| `drop_counter_reason` | `string` | The label to add to `loki_process_dropped_lines_total` metric when logs are dropped by this stage. | sampling_stage | no       |
+| Name                  | Type     | Description                                                                                        | Default          | Required |
+| --------------------- | -------- | -------------------------------------------------------------------------------------------------- | ---------------- | -------- |
+| `rate`                | `float`  | The sampling rate in a range of `[0, 1]`                                                           |                  | yes      |
+| `drop_counter_reason` | `string` | The label to add to `loki_process_dropped_lines_total` metric when logs are dropped by this stage. | `sampling_stage` | no       |
 
 For example, the configuration below will sample 25% of the logs and drop the remaining 75%.
 When logs are dropped, the `loki_process_dropped_lines_total` metric is incremented with an additional `reason=logs_sampling` label.
@@ -1169,7 +1320,7 @@ stage.sampling {
 }
 ```
 
-### stage.static_labels block
+### `stage.static_labels`
 
 The `stage.static_labels` inner block configures a static_labels processing stage that adds a static set of labels to incoming log entries.
 
@@ -1179,7 +1330,6 @@ The following arguments are supported:
 | -------- | ------------- | ---------------------------------------------- | ------- | -------- |
 | `values` | `map(string)` | Configures a `static_labels` processing stage. | `{}`    | no       |
 
-
 ```alloy
 stage.static_labels {
     values = {
@@ -1189,7 +1339,29 @@ stage.static_labels {
 }
 ```
 
-### stage.template block
+### `stage.structured_metadata`
+
+The `stage.structured_metadata` inner block configures a stage that can read data from the extracted values map and add them to log entries as structured metadata.
+
+The following arguments are supported:
+
+| Name     | Type          | Description                                                                 | Default | Required |
+| -------- | ------------- | --------------------------------------------------------------------------- | ------- | -------- |
+| `values` | `map(string)` | Specifies the list of labels to add from extracted values map to log entry. | `{}`    | no       |
+
+In a `structured_metadata` stage, the map's keys define the label to set and the values are how to look them up.
+If the value is empty, it's inferred to be the same as the key.
+
+```alloy
+stage.structured_metadata {
+    values = {
+      env  = "",         // Sets up an 'env' property to structured metadata, based on the 'env' extracted value.
+      user = "username", // Sets up a 'user' property to structured metadata, based on the 'username' extracted value.
+    }
+}
+```
+
+### `stage.template`
 
 The `stage.template` inner block configures a transforming stage that allows users to manipulate the values in the extracted map by using Go's `text/template` [package][] syntax.
 This stage is primarily useful for manipulating and standardizing data from previous stages before setting them as labels in a subsequent stage.
@@ -1211,11 +1383,11 @@ It supports all functions from the [sprig package][], as well as the following l
 
 [sprig package]: http://masterminds.github.io/sprig/
 
-```
+```text
 ToLower, ToUpper, Replace, Trim, TrimLeftTrimRight, TrimPrefix, TrimSuffix, TrimSpace, Hash, Sha2Hash, regexReplaceAll, regexReplaceAllLiteral
 ```
 
-More details on each of these functions can be found in the [supported functions][] section below.
+More details on each of these functions can be found in the [supported functions][] section.
 
 [supported functions]: #supported-functions
 
@@ -1248,7 +1420,8 @@ stage.template {
 }
 ```
 
-A special key named `Entry` can be used to reference the current line; this can be useful when you need to append/prepend something to the log line, like this snippet:
+A special key named `Entry` can be used to reference the current line.
+This can be useful when you need to append/prepend something to the log line, like this snippet:
 
 ```alloy
 stage.template {
@@ -1261,14 +1434,15 @@ stage.output {
 ```
 
 #### Supported functions
+
 In addition to supporting all functions from the [sprig package](http://masterminds.github.io/sprig/), the `template` stage supports the following custom functions.
 
-##### ToLower and ToUpper
+##### `ToLower` and `ToUpper`
 
-`ToLower` and `ToUpper` convert the entire string to lowercase and
-uppercase, respectively.
+`ToLower` and `ToUpper` convert the entire string to lowercase and uppercase, respectively.
+
+The following example shows how you can use this function.
 
-Examples:
 ```alloy
 stage.template {
     source   = "out"
@@ -1280,17 +1454,17 @@ stage.template {
 }
 ```
 
-##### Replace
+##### `Replace`
 
 The `Replace` function syntax is defined as `{{ Replace <string> <old> <new> <n> }}`.
 
-The function returns a copy of the input string, with instances of the `<old>`
-argument being replaced by `<new>`. The function replaces up to `<n>`
-non-overlapping instances of the second argument. If `<n>` is less than zero,
-there is no limit on the number of replacement. Finally, if `<old>` is empty,
-it matches before and after every UTF-8 character in the string.
+The function returns a copy of the input string, with instances of the `<old>` argument being replaced by `<new>`.
+The function replaces up to `<n>` non-overlapping instances of the second argument.
+If `<n>` is less than zero, there is no limit on the number of replacements.
+Finally, if `<old>` is empty, it matches before and after every UTF-8 character in the string.
 
 This example replaces the first two instances of the `loki` word by `Loki`:
+
 ```alloy
 stage.template {
     source   = "output"
@@ -1298,17 +1472,14 @@ stage.template {
 }
 ```
 
-##### Trim, TrimLeft, TrimRight, TrimSpace, TrimPrefix, TrimSuffix
+##### `Trim`, `TrimLeft`, `TrimRight`, `TrimSpace`, `TrimPrefix`, `TrimSuffix`
 
-* `Trim` returns a slice of the string `s` with all leading and trailing Unicode
-  code points contained in `cutset` removed.
-* `TrimLeft` and `TrimRight` are the same as Trim except that they
-  trim only leading and trailing characters, respectively.
-* `TrimSpace` returns a slice of the string s, with all leading and trailing
-white space removed, as defined by Unicode.
+* `Trim` returns a slice of the string `s` with all leading and trailing Unicode code points contained in `cutset` removed.
+* `TrimLeft` and `TrimRight` are the same as Trim except that they trim only leading and trailing characters, respectively.
+* `TrimSpace` returns a slice of the string s, with all leading and trailing white space removed, as defined by Unicode.
 * `TrimPrefix` and `TrimSuffix` trim the supplied prefix or suffix, respectively.
 
-Examples:
+The following example shows how you can use this function.
 
 ```alloy
 stage.template {
@@ -1325,16 +1496,14 @@ stage.template {
 }
 ```
 
-##### Regex
+##### `regexReplaceAll` and `regexReplaceAllLiteral`
 
-`regexReplaceAll` returns a copy of the input string, replacing matches of the
-Regexp with the replacement string. Inside the replacement string, `$` characters
-are interpreted as in Expand functions, so for instance, $1 represents the first captured
-submatch.
+`regexReplaceAll` returns a copy of the input string, replacing matches of the Regexp with the replacement string.
+Inside the replacement string, `$` characters are interpreted as in Expand functions.
+For example, $1 represents the first captured submatch.
 
-`regexReplaceAllLiteral` returns a copy of the input string, replacing matches
-of the Regexp with the replacement string. The replacement string is
-substituted directly, without using Expand.
+`regexReplaceAllLiteral` returns a copy of the input string, replacing matches of the Regexp with the replacement string.
+The replacement string is substituted directly, without using Expand.
 
 ```alloy
 stage.template {
@@ -1347,13 +1516,15 @@ stage.template {
 }
 ```
 
-##### Hash and Sha2Hash
+##### `Hash` and `Sha2Hash`
 
-`Hash` returns a `Sha3_256` hash of the string, represented as a hexadecimal number of 64 digits. You can use it to obfuscate sensitive data and PII in the logs.
-It requires a (fixed) salt value, to add complexity to low input domains (e.g., all possible social security numbers).
-`Sha2Hash` returns a `Sha2_256` of the string which is faster and less CPU-intensive than `Hash`, however it is less secure.
+`Hash` returns a `Sha3_256` hash of the string, represented as a hexadecimal number of 64 digits.
+You can use it to obfuscate sensitive data and PII in the logs.
+It requires a (fixed) salt value, to add complexity to low input domains, for example, all possible social security numbers.
+`Sha2Hash` returns a `Sha2_256` of the string which is faster and less CPU-intensive than `Hash`, however it's less secure.
+
+The following example shows how you can use this function.
 
-Examples:
 ```alloy
 stage.template {
     source   = "output"
@@ -1367,10 +1538,9 @@ stage.template {
 
 We recommend using Hash as it has a stronger hashing algorithm.
 
-### stage.tenant block
+### `stage.tenant`
 
-The `stage.tenant` inner block sets the tenant ID for the log entry by obtaining it from a
-field in the extracted data map, a label, or a provided value.
+The `stage.tenant` inner block sets the tenant ID for the log entry by obtaining it from a field in the extracted data map, a label, or a provided value.
 
 The following arguments are supported:
 
@@ -1383,14 +1553,14 @@ The following arguments are supported:
 The block expects only one of `label`, `source` or `value` to be provided.
 
 The following stage assigns the fixed value `team-a` as the tenant ID:
+
 ```alloy
 stage.tenant {
     value = "team-a"
 }
 ```
 
-This stage extracts the tenant ID from the `customer_id` field after
-parsing the log entry as JSON in the shared extracted map:
+This stage extracts the tenant ID from the `customer_id` field after parsing the log entry as JSON in the shared extracted map:
 
 ```alloy
 stage.json {
@@ -1412,36 +1582,33 @@ stage.tenant {
 }
 ```
 
-### stage.timestamp block
+### `stage.timestamp`
 
-The `stage.timestamp` inner block configures a processing stage that sets the
-timestamp of log entries before they're forwarded to the next component. When
-no timestamp stage is set, the log entry timestamp defaults to the time when
-the log entry was scraped.
+The `stage.timestamp` inner block configures a processing stage that sets the timestamp of log entries before they're forwarded to the next component.
+When no timestamp stage is set, the log entry timestamp defaults to the time when the log entry was scraped.
 
 The following arguments are supported:
 
 | Name                | Type           | Description                                                 | Default   | Required |
 | ------------------- | -------------- | ----------------------------------------------------------- | --------- | -------- |
-| `source`            | `string`       | Name from extracted values map to use for the timestamp.    |           | yes      |
 | `format`            | `string`       | Determines how to parse the source string.                  |           | yes      |
+| `source`            | `string`       | Name from extracted values map to use for the timestamp.    |           | yes      |
+| `action_on_failure` | `string`       | What to do when the timestamp can't be extracted or parsed. | `"fudge"` | no       |
 | `fallback_formats`  | `list(string)` | Fallback formats to try if the `format` field fails.        | `[]`      | no       |
 | `location`          | `string`       | IANA Timezone Database location to use when parsing.        | `""`      | no       |
-| `action_on_failure` | `string`       | What to do when the timestamp can't be extracted or parsed. | `"fudge"` | no       |
 
 {{< admonition type="note" >}}
 Be careful with further stages which may also override the timestamp.
 For example, a `stage.pack` with `ingest_timestamp` set to `true` could replace the timestamp which `stage.timestamp` had set earlier in the pipeline.
 {{< /admonition >}}
 
-The `source` field defines which value from the shared map of extracted values
-the stage should attempt to parse as a timestamp.
+The `source` field defines which value from the shared map of extracted values the stage should attempt to parse as a timestamp.
 
 The `format` field defines _how_ that source should be parsed.
 
 The `format` can be set to one of the following shorthand values for commonly used forms:
 
-```
+```text
 ANSIC: Mon Jan _2 15:04:05 2006
 UnixDate: Mon Jan _2 15:04:05 MST 2006
 RubyDate: Mon Jan 02 15:04:05 -0700 2006
@@ -1454,28 +1621,23 @@ RFC3339: 2006-01-02T15:04:05-07:00
 RFC3339Nano: 2006-01-02T15:04:05.999999999-07:00
 ```
 
-Additionally, support for common Unix timestamps is supported with the
-following format values:
+Additionally, support for common Unix timestamps is supported with the following format values:
 
-```
+```text
 Unix: 1562708916 or with fractions 1562708916.000000123
 UnixMs: 1562708916414
 UnixUs: 1562708916414123
 UnixNs: 1562708916000000123
 ```
 
-Otherwise, the field accepts a custom format string that defines how an
-arbitrary reference point in history should
-be interpreted by the stage. The arbitrary reference point is Mon Jan 2 15:04:05 -0700 MST 2006.
+Otherwise, the field accepts a custom format string that defines how an arbitrary reference point in history should be interpreted by the stage.
+The arbitrary reference point is Mon Jan 2 15:04:05 -0700 MST 2006.
 
-The string value of the field is passed directly to the layout parameter in
-Go's [`time.Parse`](https://pkg.go.dev/time#Parse) function.
+The string value of the field is passed directly to the layout parameter in Go's [`time.Parse`](https://pkg.go.dev/time#Parse) function.
 
-If the custom format has no year component, the stage uses the current year,
-according to the system's clock.
+If the custom format has no year component, the stage uses the current year, according to the system's clock.
 
-The following table shows the supported reference values to use when defining a
-custom format.
+The following table shows the supported reference values to use when defining a custom format.
 
 | Timestamp Component | Format value                                                                                                             |
 | ------------------- | ------------------------------------------------------------------------------------------------------------------------ |
@@ -1497,24 +1659,18 @@ If you define a custom timestamp, the `format` value for each timestamp componen
 For example, to indicate the year, the `format` value must be `06` or `2006` and not any other value like `23` or `2023`.
 {{< /admonition >}}
 
-The `fallback_formats` field defines one or more format fields to try and parse
-the timestamp with, if parsing with `format` fails.
+The `fallback_formats` field defines one or more format fields to try and parse the timestamp with, if parsing with `format` fails.
 
-The `location` field must be a valid IANA Timezone Database location and
-determines in which timezone the timestamp value is interpreted to be in.
+The `location` field must be a valid IANA Timezone Database location and determines in which timezone the timestamp value is interpreted to be in.
 
-The `action_on_failure` field defines what should happen when the source field
-doesn't exist in the shared extracted map, or if the timestamp parsing fails.
+The `action_on_failure` field defines what should happen when the source field doesn't exist in the shared extracted map, or if the timestamp parsing fails.
 
 The supported actions are:
 
-* fudge (default): Change the timestamp to the last known timestamp, summing up
-  1 nanosecond (to guarantee log entries ordering).
-* skip: Do not change the timestamp and keep the time when the log entry was
-  scraped.
+* fudge (default): Change the timestamp to the last known timestamp, summing up 1 nanosecond to guarantee log entries ordering.
+* skip: Don't change the timestamp and keep the time when the log entry was scraped.
 
-The following stage fetches the `time` value from the shared values map, parses
-it as a RFC3339 format, and sets it as the log entry's timestamp.
+The following stage fetches the `time` value from the shared values map, parses it as a RFC3339 format, and sets it as the log entry's timestamp.
 
 ```alloy
 stage.timestamp {
@@ -1532,258 +1688,6 @@ stage.timestamp {
 }
 ```
 
-### stage.geoip block
-
-The `stage.geoip` inner block configures a processing stage that reads an IP address and populates the shared map with geoip fields. Maxmind’s GeoIP2 database is used for the lookup.
-
-The following arguments are supported:
-
-| Name             | Type          | Description                                        | Default | Required |
-| ---------------- | ------------- | -------------------------------------------------- | ------- | -------- |
-| `db`             | `string`      | Path to the Maxmind DB file.                       |         | yes      |
-| `source`         | `string`      | IP from extracted data to parse.                   |         | yes      |
-| `db_type`        | `string`      | Maxmind DB type. Allowed values are "city", "asn", "country". |         | no       |
-| `custom_lookups` | `map(string)` | Key-value pairs of JMESPath expressions.           |         | no       |
-
-
-#### GeoIP with City database example:
-
-```
-{"log":"log message","client_ip":"34.120.177.193"}
-
-loki.process "example" {
-    stage.json {
-        expressions = {ip = "client_ip"}
-    }
-
-    stage.geoip {
-        source  = "ip"
-        db      = "/path/to/db/GeoLite2-City.mmdb"
-        db_type = "city"
-    }
-
-    stage.labels {
-        values = {
-            geoip_city_name          = "",
-            geoip_country_name       = "",
-            geoip_country_code       = "",
-            geoip_continent_name     = "",
-            geoip_continent_code     = "",
-            geoip_location_latitude  = "",
-            geoip_location_longitude = "",
-            geoip_postal_code        = "",
-            geoip_timezone           = "",
-            geoip_subdivision_name   = "",
-            geoip_subdivision_code   = "",
-        }
-    }
-}
-```
-
-The `json` stage extracts the IP address from the `client_ip` key in the log line.
-Then the extracted `ip` value is given as source to geoip stage. The geoip stage performs a lookup on the IP and populates the following fields in the shared map which are added as labels using the `labels` stage.
-
-The extracted data from the IP used in this example:
-
-- geoip_city_name: Kansas City
-- geoip_country_name: United States
-- geoip_country_code: US
-- geoip_continent_name: North America
-- geoip_continent_code: NA
-- geoip_location_latitude: 39.1027
-- geoip_location_longitude: -94.5778
-- geoip_postal_code: 64184
-- geoip_timezone: America/Chicago
-- geoip_subdivision_name: Missouri
-- geoip_subdivision_code: MO
-
-#### GeoIP with ASN (Autonomous System Number) database example
-
-```
-loki.process "example" {
-    stage.json {
-        expressions = {ip = "client_ip"}
-    }
-
-    stage.geoip {
-        source  = "ip"
-        db      = "/path/to/db/GeoIP2-ASN.mmdb"
-        db_type = "asn"
-    }
-
-    stage.labels {
-        values = {
-            geoip_autonomous_system_number       = "",
-            geoip_autonomous_system_organization = "",
-        }
-    }
-}
-```
-
-The `json` stage extracts the IP address from the `client_ip` key in the log line.
-Then the extracted `ip` value is given as source to geoip stage. The geoip stage performs a lookup on the IP and populates the shared map.
-
-The extracted data from the IP used in this example:
-
-- geoip_autonomous_system_number: 396982
-- geoip_autonomous_system_organization: GOOGLE-CLOUD-PLATFORM
-
-#### GeoIP with Country database example:
-
-```
-{"log":"log message","client_ip":"34.120.177.193"}
-
-loki.process "example" {
-    stage.json {
-        expressions = {ip = "client_ip"}
-    }
-
-    stage.geoip {
-        source  = "ip"
-        db      = "/path/to/db/GeoLite2-Country.mmdb"
-        db_type = "country"
-    }
-
-    stage.labels {
-        values = {
-            geoip_country_name       = "",
-            geoip_country_code       = "",
-            geoip_continent_name     = "",
-            geoip_continent_code     = "",
-        }
-    }
-}
-```
-
-The `json` stage extracts the IP address from the `client_ip` key in the log line.
-Then the extracted `ip` value is given as source to geoip stage. The geoip stage performs a lookup on the IP and populates the following fields in the shared map which are added as labels using the `labels` stage.
-
-The extracted data from the IP used in this example:
-
-- geoip_country_name: United States
-- geoip_country_code: US
-- geoip_continent_name: North America
-- geoip_continent_code: NA
-
-#### GeoIP with custom fields example
-
-If the MMDB file used is enriched with custom data, for example, private IP addresses as explained in [the Maxmind blog post](https://github.com/maxmind/mmdb-from-go-blogpost), then it can be extracted from the record using the `custom_lookups` attribute.
-
-```
-loki.process "example" {
-    stage.json {
-        expressions = {ip = "client_ip"}
-    }
-
-    stage.geoip {
-        source         = "ip"
-        db             = "/path/to/db/GeoIP2-Enriched.mmdb"
-        db_type        = "city"
-        custom_lookups = {
-            "department"  = "MyCompany.DeptName",
-            "parent_vnet" = "MyCompany.ParentVNet",
-            "subnet"      = "MyCompany.Subnet",
-        }
-    }
-
-    stage.labels {
-        values = {
-            department  = "",
-            parent_vnet = "",
-            subnet      = "",
-        }
-    }
-}
-```
-The `json` stage extracts the IP address from the `client_ip` key in the log line.
-Then the extracted `ip` value is given as source to geoip stage. The geoip stage performs a lookup on the IP and populates the shared map with the data from the city database results in addition to the custom lookups. Lastly, the custom lookup fields from the shared map are added as labels.
-
-### stage.windowsevent block
-
-The `windowsevent` stage extracts data from the message string in the Windows Event Log.
-
-The following arguments are supported:
-
-| Name                  | Type     | Description                                            | Default   | Required |
-|-----------------------|----------|--------------------------------------------------------|-----------|----------|
-| `source`              | `string` | Name of the field in the extracted data to parse.      | `message` | no       |
-| `overwrite_existing`  | `bool`   | Whether to overwrite existing extracted data fields.   | `false`   | no       |
-| `drop_invalid_labels` | `bool`   | Whether to drop fields that are not valid label names. | `false`   | no       |
-
-When `overwrite_existing` is set to `true`, the stage overwrites existing extracted data fields with the same name.
-If set to `false`, the `_extracted` suffix is appended to an existing field name.
-
-When `drop_invalid_labels` is set to `true`, the stage drops fields that aren't valid label names.
-If set to `false`, the stage will automatically convert them into valid labels, replacing invalid characters with underscores.
-
-The `windowsevent` stage expects the message to be structured in sections that are split by empty lines.
-
-The first section of the input is treated as a whole block and stored in the extracted map with the key `Description`.
-
-Sections following the Description are expected to contain key-value pairs in the format key:value.
-
-If the first line of a section has no value, for example "Subject:", the key will act as a prefix for subsequent keys in the same section.
-
-If a line within a section does not include the `:` symbol, it is considered part of the previous entry's value. The line is appended to the previous value, separated by a comma.
-
-Lines in a section without a preceding valid entry (key-value pair) are ignored and discarded.
-
-#### Example with `loki.source.windowsevent`
-
-```alloy
-loki.source.windowsevent "security"  {
-    eventlog_name = "Security"
-    forward_to = [loki.process.default.receiver]
-}
-
-loki.process "default" {
-  forward_to = [loki.write.default.receiver]
-
-  stage.json {
-      expressions = {
-          message = "",
-          Overwritten = "",
-      }
-  }
-
-  stage.windowsevent {
-      source = "message"
-      overwrite_existing = true
-  }
-
-  stage.labels {
-    values = {
-      Description = "",
-      Subject_SecurityID  = "",        
-      ReadOP = "Subject_ReadOperation",
-    }
-  }
-}
-```
-
-The `loki.source.windowsevent` component forwards Windows security events to the `loki.process` component.
-
-Given the following event:
-```
-{"event_id": 1, "Overwritten": "old", "message": ""Special privileges assigned to new logon.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-1-1\r\n\tAccount Name:\t\tSYSTEM\r\n\tAccount Domain:\t\tNT AUTHORITY\r\n\tLogon ID:\t\t0xAAA\r\n\r\nPrivileges:\t\tSeAssignPrimaryTokenPrivilege\r\n\t\t\tSeTcbPrivilege\r\n\t\t\tSeSecurityPrivilege\r\n\t\t\tSeTakeOwnershipPrivilege\r\n\t\t\tSeLoadDriverPrivilege\r\n\t\t\tSeBackupPrivilege\r\n\t\t\tSeRestorePrivilege\r\n\t\t\tSeDebugPrivilege\r\n\t\t\tSeAuditPrivilege\r\n\t\t\tSeSystemEnvironmentPrivilege\r\n\t\t\tSeImpersonatePrivilege\r\n\t\t\tSeDelegateSessionUserImpersonatePrivilege""}
-```
-
-The `json` stage would create the following key-value pairs in the set of extracted data:
-
-- `message`: `"Special privileges assigned to new logon.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-1-1\r\n\tAccount Name:\t\tSYSTEM\r\n\tAccount Domain:\t\tNT AUTHORITY\r\n\tLogon ID:\t\t0xAAA\r\n\r\nPrivileges:\t\tSeAssignPrimaryTokenPrivilege\r\n\t\t\tSeTcbPrivilege\r\n\t\t\tSeSecurityPrivilege"`
-- `Overwritten`: `old`
-
-The `windowsevent` stage will parse the value of `message` from the extracted data and append/overwrite the following key-value pairs to the set of extracted data:
-
-- `Description`:           "Special privileges assigned to new logon.",
-- `Subject_SecurityID`:    "S-1-1-1",
-- `Subject_AccountName`:   "SYSTEM",
-- `Subject_AccountDomain`: "NT AUTHORITY",
-- `Subject_LogonID`:       "0xAAA",
-- `Privileges`:            "SeAssignPrimaryTokenPrivilege,SeTcbPrivilege,SeSecurityPrivilege",
-
-Finally the `labels` stage will use the extracted values `Description`, `Subject_SecurityID` and `Subject_ReadOperation` to add them as labels of the log entry before forwarding it to a `loki.write` component.
-
 ## Exported fields
 
 The following fields are exported and can be referenced by other components:
@@ -1798,7 +1702,7 @@ The following fields are exported and can be referenced by other components:
 
 ## Debug information
 
-`loki.process` does not expose any component-specific debug information.
+`loki.process` doesn't expose any component-specific debug information.
 
 ## Debug metrics
 
@@ -1807,8 +1711,7 @@ The following fields are exported and can be referenced by other components:
 
 ## Example
 
-This example creates a `loki.process` component that extracts the `environment`
-value from a JSON log line and sets it as a label named 'env'.
+This example creates a `loki.process` component that extracts the `environment` value from a JSON log line and sets it as a label named 'env'.
 
 ```alloy
 loki.process "local" {
diff --git a/docs/sources/reference/components/loki/loki.relabel.md b/docs/sources/reference/components/loki/loki.relabel.md
index af5e834293..2b25ee80af 100644
--- a/docs/sources/reference/components/loki/loki.relabel.md
+++ b/docs/sources/reference/components/loki/loki.relabel.md
@@ -3,36 +3,32 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.relabel/ # /docs/alloy/latest/reference/components/loki.relabel/
 description: Learn about loki.relabel
+labels:
+  stage: general-availability
 title: loki.relabel
 ---
 
-# loki.relabel
+# `loki.relabel`
 
-The `loki.relabel` component rewrites the label set of each log entry passed to
-its receiver by applying one or more relabeling `rule`s and forwards the
-results to the list of receivers in the component's arguments.
+The `loki.relabel` component rewrites the label set of each log entry passed to its receiver by applying one or more relabeling rules and forwards the results to the list of receivers in the component's arguments.
 
-If no labels remain after the relabeling rules are applied, then the log
-entries are dropped.
+If no labels remain after the relabeling rules are applied, then the log entries are dropped.
 
-The most common use of `loki.relabel` is to filter log entries or standardize
-the label set that is passed to one or more downstream receivers. The `rule`
-blocks are applied to the label set of each log entry in order of their
-appearance in the configuration file. The configured rules can be retrieved by
-calling the function in the `rules` export field.
+The most common use of `loki.relabel` is to filter log entries or standardize the label set that's passed to one or more downstream receivers.
+The `rule` blocks are applied to the label set of each log entry in order of their appearance in the configuration file.
+The configured rules can be retrieved by calling the function in the `rules` export field.
 
-If you're looking for a way to process the log entry contents, take a look at
-[the `loki.process` component][loki.process] instead.
+If you're looking for a way to process the log entry contents, use [the `loki.process` component][loki.process] instead.
 
 [loki.process]: ../loki.process/
 
-Multiple `loki.relabel` components can be specified by giving them different labels.
+You can specify multiple `loki.relabel` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.relabel "LABEL" {
-  forward_to = RECEIVER_LIST
+loki.relabel "<LABEL>" {
+  forward_to = <RECEIVER_LIST>
 
   rule {
     ...
@@ -44,24 +40,24 @@ loki.relabel "LABEL" {
 
 ## Arguments
 
-The following arguments are supported:
+You can use the following arguments with `loki.relabel`:
 
-Name             | Type             | Description                                                    | Default | Required
------------------|------------------|----------------------------------------------------------------|---------|---------
-`forward_to`     | `list(receiver)` | Where to forward log entries after relabeling.                 |         | yes
-`max_cache_size` | `int`            | The maximum number of elements to hold in the relabeling cache | 10,000  | no
+| Name             | Type             | Description                                                    | Default | Required |
+| ---------------- | ---------------- | -------------------------------------------------------------- | ------- | -------- |
+| `forward_to`     | `list(receiver)` | Where to forward log entries after relabeling.                 |         | yes      |
+| `max_cache_size` | `int`            | The maximum number of elements to hold in the relabeling cache | 10,000  | no       |
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.relabel`:
+You can use the following block with `loki.relabel`:
 
-Hierarchy | Name     | Description                                        | Required
-----------|----------|----------------------------------------------------|---------
-rule      | [rule][] | Relabeling rules to apply to received log entries. | no
+| Name           | Description                                        | Required |
+| -------------- | -------------------------------------------------- | -------- |
+| [`rule`][rule] | Relabeling rules to apply to received log entries. | no       |
 
-[rule]: #rule-block
+[rule]: #rule
 
-### rule block
+### `rule`
 
 {{< docs/shared lookup="reference/components/rule-block-logs.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
@@ -69,10 +65,10 @@ rule      | [rule][] | Relabeling rules to apply to received log entries. | no
 
 The following fields are exported and can be referenced by other components:
 
-Name       | Type           | Description
------------|----------------|-------------------------------------------------------------
-`receiver` | `receiver`     | The input receiver where log lines are sent to be relabeled.
-`rules`    | `RelabelRules` | The currently configured relabeling rules.
+| Name       | Type           | Description                                                  |
+| ---------- | -------------- | ------------------------------------------------------------ |
+| `receiver` | `receiver`     | The input receiver where log lines are sent to be relabeled. |
+| `rules`    | `RelabelRules` | The currently configured relabeling rules.                   |
 
 ## Component health
 
@@ -81,7 +77,7 @@ In those cases, exported fields are kept at their last healthy values.
 
 ## Debug information
 
-`loki.relabel` does not expose any component-specific debug information.
+`loki.relabel` doesn't expose any component-specific debug information.
 
 ## Debug metrics
 
diff --git a/docs/sources/reference/components/loki/loki.rules.kubernetes.md b/docs/sources/reference/components/loki/loki.rules.kubernetes.md
index 0eabf5b2df..7a35d73704 100644
--- a/docs/sources/reference/components/loki/loki.rules.kubernetes.md
+++ b/docs/sources/reference/components/loki/loki.rules.kubernetes.md
@@ -2,24 +2,24 @@
 canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.rules.kubernetes/
 aliases:
   - ../loki.rules.kubernetes/ # /docs/alloy/latest/reference/components/loki.rules.kubernetes/
+description: Learn about loki.rules.kubernetes
+labels:
+  stage: general-availability
 title: loki.rules.kubernetes
 ---
 
-# loki.rules.kubernetes
+# `loki.rules.kubernetes`
 
-`loki.rules.kubernetes` discovers `PrometheusRule` Kubernetes resources and
-loads them into a Loki instance.
+`loki.rules.kubernetes` discovers `PrometheusRule` Kubernetes resources and loads them into a Loki instance.
 
 * You can specify multiple `loki.rules.kubernetes` components by giving them different labels.
-* [Kubernetes label selectors][] can be used to limit the `Namespace` and
-  `PrometheusRule` resources considered during reconciliation.
+* [Kubernetes label selectors][] can be used to limit the `Namespace` and `PrometheusRule` resources considered during reconciliation.
 * Compatible with the Ruler APIs of Grafana Loki, Grafana Cloud, and Grafana Enterprise Metrics.
-* Compatible with the `PrometheusRule` CRD from the [prometheus-operator][].
+* Compatible with the `PrometheusRule` CRD from the [`prometheus-operator`][prometheus-operator].
 * This component accesses the Kubernetes REST API from [within a Pod][].
 
 {{< admonition type="note" >}}
-This component requires [Role-based access control (RBAC)][] to be set up
-in Kubernetes for {{< param "PRODUCT_NAME" >}} to access it via the Kubernetes REST API.
+This component requires [Role-based access control (RBAC)][] to be set up in Kubernetes for {{< param "PRODUCT_NAME" >}} to access it via the Kubernetes REST API.
 
 [Role-based access control (RBAC)]: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
 {{< /admonition >}}
@@ -31,100 +31,104 @@ in Kubernetes for {{< param "PRODUCT_NAME" >}} to access it via the Kubernetes R
 ## Usage
 
 ```alloy
-loki.rules.kubernetes "LABEL" {
-  address = LOKI_RULER_URL
+loki.rules.kubernetes "<LABEL>" {
+  address = "<LOKI_RULER_URL>"
 }
 ```
 
 ## Arguments
 
-`loki.rules.kubernetes` supports the following arguments:
-
-Name                    | Type       | Description                                                                          | Default | Required
-------------------------|------------|--------------------------------------------------------------------------------------|---------|---------
-`address`               | `string`   | URL of the Loki ruler.                                                               |         | yes
-`tenant_id`             | `string`   | Loki tenant ID.                                                                      |         | no
-`use_legacy_routes`     | `bool`     | Whether to use deprecated ruler API endpoints.                                       | false   | no
-`sync_interval`         | `duration` | Amount of time between reconciliations with Loki.                                    | "30s"   | no
-`loki_namespace_prefix` | `string`   | Prefix used to differentiate multiple {{< param "PRODUCT_NAME" >}} deployments. | "alloy" | no
-`bearer_token`          | `secret`   | Bearer token to authenticate with.                                                   |         | no
-`bearer_token_file`     | `string`   | File containing a bearer token to authenticate with.                                 |         | no
-`proxy_url`             | `string`   | HTTP proxy to proxy requests through.                                                |         | no
-`follow_redirects`      | `bool`     | Whether redirects returned by the server should be followed.                         | `true`  | no
-`enable_http2`          | `bool`     | Whether HTTP2 is supported for requests.                                             | `true`  | no
+You can use the following arguments with `loki.rules.kubernetes`:
+
+| Name                    | Type       | Description                                                                     | Default | Required |
+| ----------------------- | ---------- | ------------------------------------------------------------------------------- | ------- | -------- |
+| `address`               | `string`   | URL of the Loki ruler.                                                          |         | yes      |
+| `bearer_token_file`     | `string`   | File containing a bearer token to authenticate with.                            |         | no       |
+| `bearer_token`          | `secret`   | Bearer token to authenticate with.                                              |         | no       |
+| `enable_http2`          | `bool`     | Whether HTTP2 is supported for requests.                                        | `true`  | no       |
+| `follow_redirects`      | `bool`     | Whether redirects returned by the server should be followed.                    | `true`  | no       |
+| `loki_namespace_prefix` | `string`   | Prefix used to differentiate multiple {{< param "PRODUCT_NAME" >}} deployments. | "alloy" | no       |
+| `proxy_url`             | `string`   | HTTP proxy to proxy requests through.                                           |         | no       |
+| `sync_interval`         | `duration` | Amount of time between reconciliations with Loki.                               | "30s"   | no       |
+| `tenant_id`             | `string`   | Loki tenant ID.                                                                 |         | no       |
+| `use_legacy_routes`     | `bool`     | Whether to use deprecated ruler API endpoints.                                  | false   | no       |
 
  At most, one of the following can be provided:
- - [`bearer_token` argument](#arguments).
- - [`bearer_token_file` argument](#arguments).
- - [`basic_auth` block][basic_auth].
- - [`authorization` block][authorization].
- - [`oauth2` block][oauth2].
+
+* [`authorization`][authorization] block
+* [`basic_auth`][basic_auth] block
+* [`bearer_token_file`][arguments] argument
+* [`bearer_token`][arguments] argument
+* [`oauth2`][oauth2] block
 
  [arguments]: #arguments
 
-If no `tenant_id` is provided, the component assumes that the Loki instance at
-`address` is running in single-tenant mode and no `X-Scope-OrgID` header is sent.
+If no `tenant_id` is provided, the component assumes that the Loki instance at `address` is running in single-tenant mode and no `X-Scope-OrgID` header is sent.
 
-The `sync_interval` argument determines how often Loki's ruler API is accessed
-to reload the current state. Interaction with the Kubernetes API works
-differently. Updates are processed as events from the Kubernetes API server
-according to the informer pattern.
+The `sync_interval` argument determines how often the Loki ruler API is accessed to reload the current state.
+Interaction with the Kubernetes API works differently.
+Updates are processed as events from the Kubernetes API server according to the informer pattern.
 
-You can use the `loki_namespace_prefix` argument to separate the rules managed
-by multiple {{< param "PRODUCT_NAME" >}} deployments across your infrastructure. You should set the prefix to a
-unique value for each deployment.
+You can use the `loki_namespace_prefix` argument to separate the rules managed by multiple {{< param "PRODUCT_NAME" >}} deployments across your infrastructure.
+You should set the prefix to a unique value for each deployment.
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`loki.rules.kubernetes`:
+You can use the following blocks with `loki.rules.kubernetes`:
+
+| Block                                                              | Description                                                | Required |
+| ------------------------------------------------------------------ | ---------------------------------------------------------- | -------- |
+| [`authorization`][authorization]                                   | Configure generic authorization to the endpoint.           | no       |
+| [`basic_auth`][basic_auth]                                         | Configure `basic_auth` for authenticating to the endpoint. | no       |
+| [`rule_namespace_selector`][label_selector]                        | Label selector for `Namespace` resources.                  | no       |
+| `rule_namespace_selector` > [`match_expression`][match_expression] | Label match expression for `Namespace` resources.          | no       |
+| [`rule_selector`][label_selector]                                  | Label selector for `PrometheusRule` resources.             | no       |
+| `rule_selector` > [`match_expression`][match_expression]           | Label match expression for `PrometheusRule` resources.     | no       |
+| [`oauth2`][oauth2]                                                 | Configure OAuth 2.0 for authenticating to the endpoint.    | no       |
+| `oauth2` > [`tls_config`][tls_config]                              | Configure TLS settings for connecting to the endpoint.     | no       |
+| [`tls_config`][tls_config]                                         | Configure TLS settings for connecting to the endpoint.     | no       |
 
-Hierarchy                                  | Block                  | Description                                              | Required
--------------------------------------------|------------------------|----------------------------------------------------------|---------
-rule_namespace_selector                    | [label_selector][]     | Label selector for `Namespace` resources.                | no
-rule_namespace_selector > match_expression | [match_expression][]   | Label match expression for `Namespace` resources.        | no
-rule_selector                              | [label_selector][]     | Label selector for `PrometheusRule` resources.           | no
-rule_selector > match_expression           | [match_expression][]   | Label match expression for `PrometheusRule` resources.   | no
-basic_auth                                 | [basic_auth][]         | Configure basic_auth for authenticating to the endpoint. | no
-authorization                              | [authorization][]      | Configure generic authorization to the endpoint.         | no
-oauth2                                     | [oauth2][]             | Configure OAuth2 for authenticating to the endpoint.     | no
-oauth2 > tls_config                        | [tls_config][]         | Configure TLS settings for connecting to the endpoint.   | no
-tls_config                                 | [tls_config][]         | Configure TLS settings for connecting to the endpoint.   | no
+The > symbol indicates deeper levels of nesting.
+For example, `oauth2` > `tls_config` refers to a `tls_config` block defined inside an `oauth2` block.
 
-The `>` symbol indicates deeper levels of nesting. For example,
-`oauth2 > tls_config` refers to a `tls_config` block defined inside
-an `oauth2` block.
+[authorization]: #authorization
+[basic_auth]: #basic_auth
+[label_selector]: #rule_selector-and-rule_namespace_selector
+[match_expression]: #match_expression
+[oauth2]: #oauth2
+[tls_config]: #tls_config
 
-[basic_auth]: #basic_auth-block
-[authorization]: #authorization-block
-[oauth2]: #oauth2-block
-[tls_config]: #tls_config-block
-[label_selector]: #label_selector-block
-[match_expression]: #match_expression-block
+### `authorization`
 
-### label_selector block
+{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-The `label_selector` block describes a Kubernetes label selector for rule or namespace discovery.
+### `basic_auth`
+
+{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+
+### `rule_selector` and `rule_namespace_selector`
+
+The `rule_selector` and `rule_namespace_selector` blocks describe a Kubernetes label selector for rule or namespace discovery.
 
 The following arguments are supported:
 
-Name           | Type          | Description                                       | Default | Required
----------------|---------------|---------------------------------------------------|---------|---------
-`match_labels` | `map(string)` | Label keys and values used to discover resources. | `{}`    | yes
+| Name           | Type          | Description                                       | Default | Required |
+| -------------- | ------------- | ------------------------------------------------- | ------- | -------- |
+| `match_labels` | `map(string)` | Label keys and values used to discover resources. | `{}`    | yes      |
 
-When the `match_labels` argument is empty, all resources will be matched.
+When the `match_labels` argument is empty, all resources are matched.
 
-### match_expression block
+### `match_expression`
 
 The `match_expression` block describes a Kubernetes label match expression for rule or namespace discovery.
 
 The following arguments are supported:
 
-Name       | Type           | Description                        | Default | Required
------------|----------------|------------------------------------|---------|---------
-`key`      | `string`       | The label name to match against.   |         | yes
-`operator` | `string`       | The operator to use when matching. |         | yes
-`values`   | `list(string)` | The values used when matching.     |         | no
+| Name       | Type           | Description                        | Default | Required |
+| ---------- | -------------- | ---------------------------------- | ------- | -------- |
+| `key`      | `string`       | The label name to match against.   |         | yes      |
+| `operator` | `string`       | The operator to use when matching. |         | yes      |
+| `values`   | `list(string)` | The values used when matching.     |         | no       |
 
 The `operator` argument should be one of the following strings:
 
@@ -132,25 +136,17 @@ The `operator` argument should be one of the following strings:
 * `"notin"`
 * `"exists"`
 
-### basic_auth block
-
-{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
-
-### authorization block
-
-{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
-
-### oauth2 block
+### `oauth2`
 
 {{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### tls_config block
+### `tls_config`
 
 {{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Exported fields
 
-`loki.rules.kubernetes` does not export any fields.
+`loki.rules.kubernetes` doesn't export any fields.
 
 ## Component health
 
@@ -161,33 +157,33 @@ The `operator` argument should be one of the following strings:
 `loki.rules.kubernetes` exposes resource-level debug information.
 
 The following are exposed per discovered `PrometheusRule` resource:
+
 * The Kubernetes namespace.
 * The resource name.
-* The resource uid.
+* The resource UID.
 * The number of rule groups.
 
 The following are exposed per discovered Loki rule namespace resource:
+
 * The namespace name.
 * The number of rule groups.
 
-Only resources managed by the component are exposed - regardless of how many
-actually exist.
+Only resources managed by the component are exposed - regardless of how many actually exist.
 
 ## Debug metrics
 
-Metric Name                                  | Type        | Description
----------------------------------------------|-------------|-------------------------------------------------------------------------
-`loki_rules_config_updates_total`            | `counter`   | Number of times the configuration has been updated.
-`loki_rules_events_total`                    | `counter`   | Number of events processed, partitioned by event type.
-`loki_rules_events_failed_total`             | `counter`   | Number of events that failed to be processed, partitioned by event type.
-`loki_rules_events_retried_total`            | `counter`   | Number of events that were retried, partitioned by event type.
-`loki_rules_client_request_duration_seconds` | `histogram` | Duration of requests to the Loki API.
+| Metric Name                                  | Type        | Description                                                              |
+| -------------------------------------------- | ----------- | ------------------------------------------------------------------------ |
+| `loki_rules_config_updates_total`            | `counter`   | Number of times the configuration has been updated.                      |
+| `loki_rules_events_total`                    | `counter`   | Number of events processed, partitioned by event type.                   |
+| `loki_rules_events_failed_total`             | `counter`   | Number of events that failed to be processed, partitioned by event type. |
+| `loki_rules_events_retried_total`            | `counter`   | Number of events that were retried, partitioned by event type.           |
+| `loki_rules_client_request_duration_seconds` | `histogram` | Duration of requests to the Loki API.                                    |
 
 ## Example
 
-This example creates a `loki.rules.kubernetes` component that loads discovered
-rules to a local Loki instance under the `team-a` tenant. Only namespaces and
-rules with the `alloy` label set to `yes` are included.
+This example creates a `loki.rules.kubernetes` component that loads discovered rules to a local Loki instance under the `team-a` tenant.
+Only namespaces and rules with the `alloy` label set to `yes` are included.
 
 ```alloy
 loki.rules.kubernetes "local" {
@@ -208,21 +204,27 @@ loki.rules.kubernetes "local" {
 }
 ```
 
-This example creates a `loki.rules.kubernetes` component that loads discovered
-rules to Grafana Cloud.
+This example creates a `loki.rules.kubernetes` component that loads discovered rules to Grafana Cloud.
 
 ```alloy
 loki.rules.kubernetes "default" {
-    address = "GRAFANA_CLOUD_URL"
+    address = "<GRAFANA_CLOUD_URL>"
     basic_auth {
-        username = "GRAFANA_CLOUD_USER"
-        password = "GRAFANA_CLOUD_API_KEY"
+        username = "<GRAFANA_CLOUD_USER>"
+        password = "<GRAFANA_CLOUD_API_KEY>"
         // Alternatively, load the password from a file:
-        // password_file = "GRAFANA_CLOUD_API_KEY_PATH"
+        // password_file = "<GRAFANA_CLOUD_API_KEY_PATH>"
     }
 }
 ```
 
+Replace the following:
+
+* _`<GRAFANA_CLOUD_URL>`_: The Grafana Cloud URL.
+* _`<GRAFANA_CLOUD_USER>`_: Your Grafana Cloud user name.
+* _`<GRAFANA_CLOUD_API_KEY>`_: Your Grafana Cloud API key.
+* _`<GRAFANA_CLOUD_API_KEY_PATH>`_: The path to the Grafana Cloud API key.
+
 The following example is an RBAC configuration for Kubernetes. It authorizes {{< param "PRODUCT_NAME" >}} to query the Kubernetes REST API:
 
 ```yaml
diff --git a/docs/sources/reference/components/loki/loki.secretfilter.md b/docs/sources/reference/components/loki/loki.secretfilter.md
index 059cd9e722..7559e51eb7 100644
--- a/docs/sources/reference/components/loki/loki.secretfilter.md
+++ b/docs/sources/reference/components/loki/loki.secretfilter.md
@@ -6,7 +6,7 @@ labels:
   stage: experimental
 ---
 
-# loki.secretfilter
+# `loki.secretfilter`
 
 {{< docs/shared lookup="stability/experimental.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
@@ -38,57 +38,63 @@ loki.secretfilter "<LABEL>" {
 
 `loki.secretfilter` supports the following arguments:
 
-Name                     | Type                 | Description                                     | Default                          | Required
--------------------------|----------------------|-------------------------------------------------|----------------------------------|---------
-`forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.       |                                  | yes
-`gitleaks_config`        | `string`             | Path to the custom `gitleaks.toml` file.        | Embedded Gitleaks file           | no
-`types`                  | `map(string)`        | Types of secret to look for.                    | All types                        | no
-`redact_with`            | `string`             | String to use to redact secrets.                | `<REDACTED-SECRET:$SECRET_NAME>` | no
-`include_generic`        | `bool`               | Include the generic API key rule.               | `false`                          | no
-`allowlist`              | `map(string)`        | List of regexes to allowlist matching secrets.  | `{}`                             | no
-`partial_mask`           | `number`             | Show the first N characters of the secret.      | `0`                              | no
+| Name              | Type                 | Description                                                | Default                          | Required |
+| ----------------- | -------------------- | ---------------------------------------------------------- | -------------------------------- | -------- |
+| `forward_to`      | `list(LogsReceiver)` | List of receivers to send log entries to.                  |                                  | yes      |
+| `allowlist`       | `map(string)`        | List of regular expressions to allowlist matching secrets. | `{}`                             | no       |
+| `gitleaks_config` | `string`             | Path to the custom `gitleaks.toml` file.                   | Embedded Gitleaks file           | no       |
+| `include_generic` | `bool`               | Include the generic API key rule.                          | `false`                          | no       |
+| `partial_mask`    | `number`             | Show the first N characters of the secret.                 | `0`                              | no       |
+| `redact_with`     | `string`             | String to use to redact secrets.                           | `<REDACTED-SECRET:$SECRET_NAME>` | no       |
+| `types`           | `map(string)`        | Types of secret to look for.                               | All types                        | no       |
 
 The `gitleaks_config` argument is the path to the custom `gitleaks.toml` file.
 The Gitleaks configuration file embedded in the component is used if you don't provide the path to a custom configuration file.
 
 {{< admonition type="note" >}}
-This component doesn't support all the features of the Gitleaks configuration file. It only supports regular expression-based rules, `secretGroup`, and allowlist regular expressions. `regexTarget` only supports the default value `secret`. Other features such as `keywords`, `entropy`, `paths`, and `stopwords` are not supported. The `extend` feature is not supported. If you use a custom configuration file, you must include all the rules you want to use within the configuration file. Unsupported fields and values in the configuration file are ignored.
+This component doesn't support all the features of the Gitleaks configuration file.
+It only supports regular expression-based rules, `secretGroup`, and allowlist regular expressions. `regexTarget` only supports the default value `secret`.
+Other features such as `keywords`, `entropy`, `paths`, and `stopwords` aren't supported.
+The `extend` feature isn't supported.
+If you use a custom configuration file, you must include all the rules you want to use within the configuration file.
+Unsupported fields and values in the configuration file are ignored.
 {{< /admonition >}}
 
 The `types` argument is a map of secret types to look for.
 The values provided are used as prefixes to match rules IDs in the Gitleaks configuration.
-For example,  providing the type `grafana` will match the rules `grafana-api-key`, `grafana-cloud-api-token`, and `grafana-service-account-token`.
+For example,  providing the type `grafana` matches the rules `grafana-api-key`, `grafana-cloud-api-token`, and `grafana-service-account-token`.
 If you don't provide this argument, all rules are used.
 
 {{< admonition type="note" >}}
 Configuring this argument with the secret types you want to look for is strongly recommended.
-If you don't, the component will look for all known types, which is resource-intensive.
+If you don't, the component looks for all known types, which is resource-intensive.
 {{< /admonition >}}
 
 {{< admonition type="caution" >}}
 Some secret types in the Gitleaks configuration file rely on regular expression patterns that don't detect the secret itself but rather the context around it.
 For example, the `aws-access-token` type detects AWS key IDs, not the keys themselves.
 This is because the keys don't have a unique pattern that can easily be detected with a regular expression.
-As a result, with this secret type enabled, the component will redact key IDs but not actual secret keys.
+As a result, with this secret type enabled, the component redacts key IDs but not actual secret keys.
 This behavior is consistent with the Gitleaks redaction feature but may not be what you expect.
 Currently, the secret types known to have this behavior are: `aws-access-token`.
 {{< /admonition >}}
 
-The `redact_with` argument is a string that can use variables such as `$SECRET_NAME` (replaced with the matching secret type) and `$SECRET_HASH`(replaced with the sha1 hash of the secret).
+The `redact_with` argument is a string that can use variables such as `$SECRET_NAME`, replaced with the matching secret type, and `$SECRET_HASH`, replaced with the SHA1 hash of the secret.
 
-The `include_generic` argument is a boolean that includes the generic API key rule in the Gitleaks configuration file if set to `true`. It's disabled by default because it can generate false positives.
+The `include_generic` argument is a boolean that includes the generic API key rule in the Gitleaks configuration file if set to `true`.
+It's disabled by default because it can generate false positives.
 
 The `allowlist` argument is a map of regular expressions to allow matching secrets.
-A secret will not be redacted if it matches any of the regular expressions. The allowlist in the Gitleaks configuration file is also applied.
+A secret won't be redacted if it matches any of the regular expressions. The allowlist in the Gitleaks configuration file is also applied.
 
 The `partial_mask` argument is the number of characters to show from the beginning of the secret before the redact string is added.
 If set to `0`, the entire secret is redacted.
-If a secret is not at least 6 characters long, it will be entirely redacted.
+If a secret isn't at least 6 characters long, it's entirely redacted.
 For short secrets, at most half of the secret is shown.
 
 ## Blocks
 
-The `loki.secretfilter` component doesn't support any blocks and is configured fully through arguments.
+The `loki.secretfilter` component doesn't support any blocks. You can configure this component with arguments.
 
 ## Exported fields
 
@@ -109,32 +115,34 @@ The following fields are exported and can be referenced by other components:
 ## Example
 
 This example shows how to use `loki.secretfilter` to redact secrets from log lines before forwarding them to a Loki receiver.
-It uses a custom redaction string that will include the secret type and its hash.
+It uses a custom redaction string that includes the secret type and its hash.
 
 ```alloy
 local.file_match "local_logs" {
-	path_targets = <PATH_TARGETS>
+    path_targets = "<PATH_TARGETS>"
 }
 
 loki.source.file "local_logs" {
-	targets    = local.file_match.local_logs.targets
-	forward_to = [loki.secretfilter.secret_filter.receiver]
+    targets    = local.file_match.local_logs.targets
+    forward_to = [loki.secretfilter.secret_filter.receiver]
 }
 
 loki.secretfilter "secret_filter" {
-	forward_to  = [loki.write.local_loki.receiver]
-	redact_with = "<ALLOY-REDACTED-SECRET:$SECRET_NAME:$SECRET_HASH>"
+    forward_to  = [loki.write.local_loki.receiver]
+    redact_with = "<ALLOY-REDACTED-SECRET:$SECRET_NAME:$SECRET_HASH>"
 }
 
 loki.write "local_loki" {
-	endpoint {
-		url = <LOKI_ENDPOINT>
-	}
+    endpoint {
+        url = "<LOKI_ENDPOINT>"
+    }
 }
 ```
+
 Replace the following:
-  - `<PATH_TARGETS>`: The paths to the log files to monitor.
-  - `<LOKI_ENDPOINT>`: The URL of the Loki instance to send logs to.
+
+* _`<PATH_TARGETS>`_: The paths to the log files to monitor.
+* _`<LOKI_ENDPOINT>`_: The URL of the Loki instance to send logs to.
 
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
diff --git a/docs/sources/reference/components/loki/loki.source.api.md b/docs/sources/reference/components/loki/loki.source.api.md
index 5d702209c5..f871d3c2a1 100644
--- a/docs/sources/reference/components/loki/loki.source.api.md
+++ b/docs/sources/reference/components/loki/loki.source.api.md
@@ -3,10 +3,12 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.api/ # /docs/alloy/latest/reference/components/loki.source.api/
 description: Learn about loki.source.api
+labels:
+  stage: general-availability
 title: loki.source.api
 ---
 
-# loki.source.api
+# `loki.source.api`
 
 `loki.source.api` receives log entries over HTTP and forwards them to other `loki.*` components.
 
@@ -19,40 +21,39 @@ This means that other [`loki.write`][loki.write] components can be used as a cli
 ## Usage
 
 ```alloy
-loki.source.api "LABEL" {
+loki.source.api "<LABEL>" {
     http {
-        listen_address = "LISTEN_ADDRESS"
-        listen_port = PORT
+        listen_address = "<LISTEN_ADDRESS>"
+        listen_port = "<PORT>"
     }
-    forward_to = RECEIVER_LIST
+    forward_to = <RECEIVER_LIST>
 }
 ```
 
-The component will start an HTTP server on the configured port and address with the following endpoints:
+The component starts an HTTP server on the configured port and address with the following endpoints:
 
-- `/loki/api/v1/push` - accepting `POST` requests compatible with [Loki push API][loki-push-api], for example, from another {{< param "PRODUCT_NAME" >}}'s [`loki.write`][loki.write] component.
-- `/loki/api/v1/raw` - accepting `POST` requests with newline-delimited log lines in body.
+* `/loki/api/v1/push` - accepting `POST` requests compatible with [Loki push API][loki-push-api], for example, from another {{< param "PRODUCT_NAME" >}}'s [`loki.write`][loki.write] component.
+* `/loki/api/v1/raw` - accepting `POST` requests with newline-delimited log lines in body.
    This can be used to send NDJSON or plain text logs.
    This is compatible with the Promtail push API endpoint.
    Refer to the [Promtail documentation][promtail-push-api] for more information.
-   When this endpoint is used, the incoming timestamps can't be used and the `use_incoming_timestamp = true` setting will be ignored.
-- `/ready` - accepting `GET` requests. Can be used to confirm the server is reachable and healthy.
-- `/api/v1/push` - internally reroutes to `/loki/api/v1/push`.
-- `/api/v1/raw` - internally reroutes to `/loki/api/v1/raw`.
-
+   When this endpoint is used, the incoming timestamps can't be used and the `use_incoming_timestamp = true` setting is ignored.
+* `/ready` - accepting `GET` requests. Can be used to confirm the server is reachable and healthy.
+* `/api/v1/push` - internally reroutes to `/loki/api/v1/push`.
+* `/api/v1/raw` - internally reroutes to `/loki/api/v1/raw`.
 
 [promtail-push-api]: https://grafana.com/docs/loki/latest/clients/promtail/configuration/#loki_push_api
 
 ## Arguments
 
-`loki.source.api` supports the following arguments:
+You can use the following arguments with `loki.source.api`:
 
-Name                     | Type                 | Description                                                | Default | Required
--------------------------|----------------------|------------------------------------------------------------|---------|---------
-`forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.                  |         | yes
-`use_incoming_timestamp` | `bool`               | Whether or not to use the timestamp received from request. | `false` | no
-`labels`                 | `map(string)`        | The labels to associate with each received logs record.    | `{}`    | no
-`relabel_rules`          | `RelabelRules`       | Relabeling rules to apply on log entries.                  | `{}`    | no
+| Name                     | Type                 | Description                                                | Default | Required |
+| ------------------------ | -------------------- | ---------------------------------------------------------- | ------- | -------- |
+| `forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.                  |         | yes      |
+| `labels`                 | `map(string)`        | The labels to associate with each received logs record.    | `{}`    | no       |
+| `relabel_rules`          | `RelabelRules`       | Relabeling rules to apply on log entries.                  | `{}`    | no       |
+| `use_incoming_timestamp` | `bool`               | Whether or not to use the timestamp received from request. | `false` | no       |
 
 The `relabel_rules` field can make use of the `rules` export value from a [`loki.relabel`][loki.relabel] component to apply one or more relabeling rules to log entries before they're forwarded to the list of receivers in `forward_to`.
 
@@ -60,15 +61,15 @@ The `relabel_rules` field can make use of the `rules` export value from a [`loki
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.api`:
+You can use the following block with `loki.source.api`:
 
-Hierarchy | Name     | Description                                        | Required
-----------|----------|----------------------------------------------------|---------
-`http`    | [http][] | Configures the HTTP server that receives requests. | no
+| Name           | Description                                        | Required |
+| -------------- | -------------------------------------------------- | -------- |
+| [`http`][http] | Configures the HTTP server that receives requests. | no       |
 
 [http]: #http
 
-### http
+### `http`
 
 {{< docs/shared lookup="reference/components/loki-server-http.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
@@ -82,7 +83,8 @@ Hierarchy | Name     | Description                                        | Requ
 
 ## Debug metrics
 
-The following are some of the metrics that are exposed when this component is used. Note that the metrics include labels such as `status_code` where relevant, which can be used to measure request success rates.
+The following are some of the metrics that are exposed when this component is used.
+The metrics include labels such as `status_code` where relevant, which can be used to measure request success rates.
 
 * `loki_source_api_request_duration_seconds` (histogram): Time (in seconds) spent serving HTTP requests.
 * `loki_source_api_request_message_bytes` (histogram): Size (in bytes) of messages received in the request.
@@ -93,15 +95,15 @@ The following are some of the metrics that are exposed when this component is us
 
 This example starts an HTTP server on `0.0.0.0` address and port `9999`.
 The server receives log entries and forwards them to a `loki.write` component while adding a `forwarded="true"` label.
-The `loki.write` component will send the logs to the specified loki instance using basic auth credentials provided.
+The `loki.write` component sends the logs to the specified Loki instance using basic auth credentials provided.
 
 ```alloy
 loki.write "local" {
     endpoint {
         url = "http://loki:3100/api/v1/push"
         basic_auth {
-            username = "<your username>"
-            password_file = "<your password file>"
+            username = "<USERNAME>"
+            password_file = "<PASSWORD_FILE>"
         }
     }
 }
@@ -120,6 +122,11 @@ loki.source.api "loki_push_api" {
 }
 ```
 
+Replace the following:
+
+* _`<USERNAME>`_: Your username.
+* _`<PASSWORD_FILE>`_: Your password file.
+
 ### Technical details
 
 `loki.source.api` filters out all labels that start with `__`, for example,  `__tenant_id__`.
diff --git a/docs/sources/reference/components/loki/loki.source.awsfirehose.md b/docs/sources/reference/components/loki/loki.source.awsfirehose.md
index 4eb033ebef..56fa653b40 100644
--- a/docs/sources/reference/components/loki/loki.source.awsfirehose.md
+++ b/docs/sources/reference/components/loki/loki.source.awsfirehose.md
@@ -3,76 +3,76 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.awsfirehose/ # /docs/alloy/latest/reference/components/loki.source.awsfirehose/
 description: Learn about loki.source.awsfirehose
+labels:
+  stage: general-availability
 title: loki.source.awsfirehose
 ---
 
-# loki.source.awsfirehose
+# `loki.source.awsfirehose`
 
-`loki.source.awsfirehose` receives log entries over HTTP
-from [AWS Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
-and forwards them to other `loki.*` components.
+`loki.source.awsfirehose` receives log entries over HTTP from [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) and forwards them to other `loki.*` components.
 
 The HTTP API exposed is compatible
-with the [Firehose HTTP Delivery API](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html).
-Since the API model that AWS Firehose uses to deliver data over HTTP is generic enough, the same component can be used
-to receive data from multiple origins:
+with the [Data Firehose HTTP Delivery API](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html).
+Since the API model that Data Firehose uses to deliver data over HTTP is generic enough, the same component can be used to receive data from multiple origins:
 
-- [AWS CloudWatch logs](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-cloudwatch-logs.html)
-- [AWS CloudWatch events](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-cloudwatch-events.html)
-- Custom data through [DirectPUT requests](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-sdk.html)
+* [Amazon CloudWatch logs](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-cloudwatch-logs.html)
+* [Amazon CloudWatch events](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-cloudwatch-events.html)
+* Custom data through [DirectPUT requests](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-sdk.html)
 
-The component uses a heuristic to try to decode as much information as possible from each log record, and it falls back to writing
-the raw records to Loki. The decoding process goes as follows:
+The component uses a heuristic to try to decode as much information as possible from each log record, and it falls back to writing the raw records to Loki.
+The decoding process goes as follows:
 
-- AWS Firehose sends batched requests
-- Each record is treated individually
-- For each `record` received in each request:
-  - If the `record` comes from a [CloudWatch logs subscription filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#DestinationKinesisExample), it's decoded and each logging event is written to Loki
-  - All other records are written raw to Loki
+* Data Firehose sends batched requests
+* Each record is treated individually
+* For each `record` received in each request:
+  * If the `record` comes from a [CloudWatch logs subscription filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#DestinationKinesisExample), it's decoded and each logging event is written to Loki
+  * All other records are written raw to Loki
 
-The component exposes some internal labels, available for relabeling. The following tables describes internal labels available
-in records coming from any source.
+The component exposes some internal labels, available for relabeling.
+The following tables describes internal labels available in records coming from any source.
 
-| Name                        | Description                   | Example                                                                  |
-|-----------------------------|-------------------------------|--------------------------------------------------------------------------|
-| `__aws_firehose_request_id` | Firehose request ID.          | `a1af4300-6c09-4916-ba8f-12f336176246`                                   |
-| `__aws_firehose_source_arn` | Firehose delivery stream ARN. | `arn:aws:firehose:us-east-2:123:deliverystream/aws_firehose_test_stream` |
+| Name                        | Description                        | Example                                                                  |
+| --------------------------- | ---------------------------------- | ------------------------------------------------------------------------ |
+| `__aws_firehose_request_id` | Data Firehose request ID.          | `a1af4300-6c09-4916-ba8f-12f336176246`                                   |
+| `__aws_firehose_source_arn` | Data Firehose delivery stream ARN. | `arn:aws:firehose:us-east-2:123:deliverystream/aws_firehose_test_stream` |
 
-If the source of the Firehose record is CloudWatch logs, the request is further decoded and enriched with even more labels,
-exposed as follows:
+If the source of the Data Firehose record is CloudWatch logs, the request is further decoded and enriched with even more labels, exposed as follows:
 
-| Name                       | Description                                                                                                               | Example                                  |
-|----------------------------|---------------------------------------------------------------------------------------------------------------------------|------------------------------------------|
-| `__aws_owner`              | The AWS Account ID of the originating log data.                                                                           | `111111111111`                           |
-| `__aws_cw_log_group`       | The log group name of the originating log data.                                                                           | `CloudTrail/logs`                        |
-| `__aws_cw_log_stream`      | The log stream name of the originating log data.                                                                          | `111111111111_CloudTrail/logs_us-east-1` |
-| `__aws_cw_matched_filters` | The list of subscription filter names that match the originating log data. The list is encoded as a comma-separated list. | `Destination,Destination2`               |
-| `__aws_cw_msg_type`        | Data messages will use the `DATA_MESSAGE` type. Sometimes CloudWatch Logs may emit Kinesis Data Streams records with a `CONTROL_MESSAGE` type, mainly for checking if the destination is reachable. | `DATA_MESSAGE`                           |
+| Name                       | Description                                                                                                                                                                                           | Example                                  |
+| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- |
+| `__aws_cw_log_group`       | The log group name of the originating log data.                                                                                                                                                       | `CloudTrail/logs`                        |
+| `__aws_cw_log_stream`      | The log stream name of the originating log data.                                                                                                                                                      | `111111111111_CloudTrail/logs_us-east-1` |
+| `__aws_cw_matched_filters` | The list of subscription filter names that match the originating log data. The list is encoded as a comma-separated list.                                                                             | `Destination,Destination2`               |
+| `__aws_cw_msg_type`        | Data messages use the `DATA_MESSAGE` type. Sometimes CloudWatch Logs may emit Amazon Kinesis Data Streams records with a `CONTROL_MESSAGE` type, mainly for checking if the destination is reachable. | `DATA_MESSAGE`                           |
+| `__aws_owner`              | The AWS Account ID of the originating log data.                                                                                                                                                       | `111111111111`                           |
 
-Refer to [Examples](#example) for a full example configuration showing how to enrich each log entry with these labels.
+Refer to the [Examples](#example) for a full example configuration showing how to enrich each log entry with these labels.
 
 ## Usage
 
 ```alloy
-loki.source.awsfirehose "LABEL" {
+loki.source.awsfirehose "<LABEL>" {
     http {
-        listen_address = "LISTEN_ADDRESS"
-        listen_port = PORT
+        listen_address = "<LISTEN_ADDRESS>"
+        listen_port = "<PORT>"
     }
     forward_to = RECEIVER_LIST
 }
 ```
 
-The component will start an HTTP server on the configured port and address with the following endpoints:
+The component starts an HTTP server on the configured port and address with the following endpoints:
 
-- `/awsfirehose/api/v1/push` - accepting `POST` requests compatible with [AWS Firehose HTTP Specifications](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html).
+* `/awsfirehose/api/v1/push` - accepting `POST` requests compatible with [Data Firehose HTTP Specifications](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html).
 
-You can use the [X-Amz-Firehose-Common-Attributes](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html) header to set extra static labels. 
-You can configure the header in the **Parameters** section of the Amazon Data Firehose delivery stream configuration. 
-Label names must be prefixed with `lbl_`. The prefix is removed before the label is stored in the log entry.
+You can use the [X-Amz-Firehose-Common-Attributes](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html) header to set extra static labels.
+You can configure the header in the **Parameters** section of the Data Firehose delivery stream configuration.
+Label names must be prefixed with `lbl_`.
+The prefix is removed before the label is stored in the log entry.
 Label names and label values must be compatible with the [Prometheus data model](https://prometheus.io/docs/concepts/data_model/#metric-names-and-labels) specification.
 
 Example of the valid `X-Amz-Firehose-Common-Attributes` value with two custom labels:
+
 ```json
 {
   "commonAttributes": {
@@ -84,40 +84,38 @@ Example of the valid `X-Amz-Firehose-Common-Attributes` value with two custom la
 
 ## Arguments
 
-`loki.source.awsfirehose` supports the following arguments:
+You can use the following arguments with `loki.source.awsfirehose`:
 
 | Name                     | Type                 | Description                                                    | Default | Required |
 | ------------------------ | -------------------- | -------------------------------------------------------------- | ------- | -------- |
 | `forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.                      |         | yes      |
-| `use_incoming_timestamp` | `bool`               | Whether or not to use the timestamp received from the request. | `false` | no       |
+| `access_key`             | `secret`             | If set, require Data Firehose to provide a matching key.       | `""`    | no       |
 | `relabel_rules`          | `RelabelRules`       | Relabeling rules to apply on log entries.                      | `{}`    | no       |
-| `access_key`             | `secret`             | If set, require AWS Firehose to provide a matching key.        | `""`    | no       |
+| `use_incoming_timestamp` | `bool`               | Whether or not to use the timestamp received from the request. | `false` | no       |
 
-The `relabel_rules` field can make use of the `rules` export value from a
-[`loki.relabel`][loki.relabel] component to apply one or more relabeling rules to log entries before they're forwarded
-to the list of receivers in `forward_to`.
+The `relabel_rules` field can make use of the `rules` export value from a [`loki.relabel`][loki.relabel] component to apply one or more relabeling rules to log entries before they're forwarded to the list of receivers in `forward_to`.
 
 [loki.relabel]: ../loki.relabel/
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.awsfirehose`:
+You can use the following blocks with `loki.source.awsfirehose`:
 
-| Hierarchy | Name     | Description                                        | Required |
-|-----------|----------|----------------------------------------------------|----------|
-| `http`    | [http][] | Configures the HTTP server that receives requests. | no       |
-| `grpc`    | [grpc][] | Configures the gRPC server that receives requests. | no       |
+| Name           | Description                                        | Required |
+|----------------|----------------------------------------------------|----------|
+| [`grpc`][grpc] | Configures the gRPC server that receives requests. | no       |
+| [`http`][http] | Configures the HTTP server that receives requests. | no       |
 
 [http]: #http
 [grpc]: #grpc
 
-### http
+### `grpc`
 
-{{< docs/shared lookup="reference/components/loki-server-http.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/loki-server-grpc.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### grpc
+### `http`
 
-{{< docs/shared lookup="reference/components/loki-server-grpc.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/loki-server-http.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Exported fields
 
@@ -135,25 +133,25 @@ The following are some of the metrics that are exposed when this component is us
 The metrics include labels  such as `status_code` where relevant, which you can use to measure request success rates.
 {{< /admonition >}}
 
-- `loki_source_awsfirehose_request_errors` (counter): Count of errors while receiving a request.
-- `loki_source_awsfirehose_record_errors` (counter): Count of errors while decoding an individual record.
-- `loki_source_awsfirehose_records_received` (counter): Count of records received.
-- `loki_source_awsfirehose_batch_size` (histogram): Size (in units) of the number of records received per request.
-- `loki_source_awsfirehose_invalid_static_labels_errors` (counter): Count number of errors while processing AWS Firehose static labels.
+* `loki_source_awsfirehose_batch_size` (histogram): Size (in units) of the number of records received per request.
+* `loki_source_awsfirehose_invalid_static_labels_errors` (counter): Count number of errors while processing Data Firehose static labels.
+* `loki_source_awsfirehose_record_errors` (counter): Count of errors while decoding an individual record.
+* `loki_source_awsfirehose_records_received` (counter): Count of records received.
+* `loki_source_awsfirehose_request_errors` (counter): Count of errors while receiving a request.
 
 ## Example
 
-This example starts an HTTP server on `0.0.0.0` address and port `9999`. The server receives log entries and forwards
-them to a `loki.write` component. The `loki.write` component will send the logs to the specified loki instance using
-basic auth credentials provided.
+This example starts an HTTP server on `0.0.0.0` address and port `9999`.
+The server receives log entries and forwards them to a `loki.write` component.
+The `loki.write` component sends the logs to the specified Loki instance using basic auth credentials provided.
 
 ```alloy
 loki.write "local" {
     endpoint {
         url = "http://loki:3100/api/v1/push"
         basic_auth {
-            username = "<your username>"
-            password_file = "<your password file>"
+            username = "<USERNAME>"
+            password_file = "<PASSWORD_FILE>"
         }
     }
 }
@@ -169,17 +167,21 @@ loki.source.awsfirehose "loki_fh_receiver" {
 }
 ```
 
-As another example, if you are receiving records that originated from a CloudWatch logs subscription, you can enrich each
-received entry by relabeling internal labels. The following configuration builds upon the one above but keeps the origin
-log stream and group as `log_stream` and `log_group`, respectively.
+Replace the following:
+
+* _`<USERNAME>`_: Your username.
+* _`<PASSWORD_FILE>`_: Your password file.
+
+As another example, if you are receiving records that originated from a CloudWatch logs subscription, you can enrich each received entry by relabeling internal labels.
+The following configuration builds upon the one above but keeps the origin log stream and group as `log_stream` and `log_group`, respectively.
 
 ```alloy
 loki.write "local" {
     endpoint {
         url = "http://loki:3100/api/v1/push"
         basic_auth {
-            username = "<your username>"
-            password_file = "<your password file>"
+            username = "<USERNAME>"
+            password_file = "<PASSWORD_FILE>"
         }
     }
 }
@@ -209,6 +211,12 @@ loki.relabel "logging_origin" {
   forward_to = []
 }
 ```
+
+Replace the following:
+
+* _`<USERNAME>`_: Your username.
+* _`<PASSWORD_FILE>`_: Your password file.
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.azure_event_hubs.md b/docs/sources/reference/components/loki/loki.source.azure_event_hubs.md
index a297ac0dae..c509f695cc 100644
--- a/docs/sources/reference/components/loki/loki.source.azure_event_hubs.md
+++ b/docs/sources/reference/components/loki/loki.source.azure_event_hubs.md
@@ -4,53 +4,53 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.azure_event_hubs/ # /docs/alloy/latest/reference/components/loki.source.azure_event_hubs/
 description: Learn about loki.source.azure_event_hubs
+labels:
+  stage: general-availability
 title: loki.source.azure_event_hubs
 ---
 
-# loki.source.azure_event_hubs
+# `loki.source.azure_event_hubs`
 
-`loki.source.azure_event_hubs` receives Azure Event Hubs messages by making use of an Apache Kafka
-endpoint on Event Hubs. For more information, see
-the [Azure Event Hubs documentation](https://learn.microsoft.com/en-us/azure/event-hubs/azure-event-hubs-kafka-overview).
+`loki.source.azure_event_hubs` receives Azure Event Hubs messages by making use of an Apache Kafka endpoint on Event Hubs.
+Refer to the [Azure Event Hubs documentation](https://learn.microsoft.com/en-us/azure/event-hubs/azure-event-hubs-kafka-overview) for more information.
 
 To learn more about streaming Azure logs to an Azure Event Hubs, refer to
 Microsoft's tutorial on how to [Stream Azure Active Directory logs to an Azure event hub](https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub).
 
-Note that an Apache Kafka endpoint is not available within the Basic pricing plan. For more information, see
-the [Event Hubs pricing page](https://azure.microsoft.com/en-us/pricing/details/event-hubs/).
+An Apache Kafka endpoint isn't available within the Basic pricing plan.
+Refer to the [Event Hubs pricing page](https://azure.microsoft.com/en-us/pricing/details/event-hubs/) for more information.
 
-Multiple `loki.source.azure_event_hubs` components can be specified by giving them
-different labels.
+You can specify multiple `loki.source.azure_event_hubs` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.source.azure_event_hubs "LABEL" {
-	fully_qualified_namespace = "HOST:PORT"
-	event_hubs                = EVENT_HUB_LIST
-	forward_to                = RECEIVER_LIST
-
-	authentication {
-		mechanism = "AUTHENTICATION_MECHANISM"
-	}
+loki.source.azure_event_hubs "<LABEL>" {
+    fully_qualified_namespace = "<HOST:PORT>"
+    event_hubs                = "<EVENT_HUB_LIST>"
+    forward_to                = <RECEIVER_LIST>
+
+    authentication {
+        mechanism = "AUTHENTICATION_MECHANISM"
+    }
 }
 ```
 
 ## Arguments
 
-`loki.source.azure_event_hubs` supports the following arguments:
+You can use the following arguments with `loki.source.azure_event_hubs`:
 
-Name                        | Type                 | Description                                                        | Default                          | Required
-----------------------------|----------------------|--------------------------------------------------------------------|----------------------------------|---------
-`fully_qualified_namespace` | `string`             | Event hub namespace.                                               |                                  | yes
-`event_hubs`                | `list(string)`       | Event Hubs to consume.                                             |                                  | yes
-`group_id`                  | `string`             | The Kafka consumer group id.                                       | `"loki.source.azure_event_hubs"` | no
-`assignor`                  | `string`             | The consumer group rebalancing strategy to use.                    | `"range"`                        | no
-`use_incoming_timestamp`    | `bool`               | Whether or not to use the timestamp received from Azure Event Hub. | `false`                          | no
-`labels`                    | `map(string)`        | The labels to associate with each received event.                  | `{}`                             | no
-`forward_to`                | `list(LogsReceiver)` | List of receivers to send log entries to.                          |                                  | yes
-`relabel_rules`             | `RelabelRules`       | Relabeling rules to apply on log entries.                          | `{}`                             | no
-`disallow_custom_messages`  | `bool`               | Whether to ignore messages that don't match the [schema](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs-schema) for Azure resource logs. | `false` | no
+| Name                        | Type                 | Description                                                                         | Default                          | Required |
+| --------------------------- | -------------------- | ----------------------------------------------------------------------------------- | -------------------------------- | -------- |
+| `event_hubs`                | `list(string)`       | Event Hubs to consume.                                                              |                                  | yes      |
+| `forward_to`                | `list(LogsReceiver)` | List of receivers to send log entries to.                                           |                                  | yes      |
+| `fully_qualified_namespace` | `string`             | Event hub namespace.                                                                |                                  | yes      |
+| `assignor`                  | `string`             | The consumer group rebalancing strategy to use.                                     | `"range"`                        | no       |
+| `disallow_custom_messages`  | `bool`               | Whether to ignore messages that don't match the [schema][] for Azure resource logs. | `false`                          | no       |
+| `group_id`                  | `string`             | The Kafka consumer group ID.                                                        | `"loki.source.azure_event_hubs"` | no       |
+| `labels`                    | `map(string)`        | The labels to associate with each received event.                                   | `{}`                             | no       |
+| `relabel_rules`             | `RelabelRules`       | Relabeling rules to apply on log entries.                                           | `{}`                             | no       |
+| `use_incoming_timestamp`    | `bool`               | Whether or not to use the timestamp received from Azure Event Hub.                  | `false`                          | no       |
 
 The `fully_qualified_namespace` argument must refer to a full `HOST:PORT` that points to your event hub, such as `NAMESPACE.servicebus.windows.net:9093`.
 The `assignor` argument must be set to one of `"range"`, `"roundrobin"`, or `"sticky"`.
@@ -59,44 +59,46 @@ The `relabel_rules` field can make use of the `rules` export value from a
 `loki.relabel` component to apply one or more relabeling rules to log entries
 before they're forwarded to the list of receivers in `forward_to`.
 
+[schema]: https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs-schema
+
 ### Labels
 
 The `labels` map is applied to every message that the component reads.
 
 The following internal labels prefixed with `__` are available but are discarded if not relabeled:
 
+- `__azure_event_hubs_category`
+- `__meta_kafka_group_id`
+- `__meta_kafka_member_id`
 - `__meta_kafka_message_key`
-- `__meta_kafka_topic`
 - `__meta_kafka_partition`
-- `__meta_kafka_member_id`
-- `__meta_kafka_group_id`
-- `__azure_event_hubs_category`
+- `__meta_kafka_topic`
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.azure_event_hubs`:
+You can use the following block with `loki.source.azure_event_hubs`:
+
+| Name                               | Description                                        | Required |
+| ---------------------------------- | -------------------------------------------------- | -------- |
+| [`authentication`][authentication] | Authentication configuration with Azure Event Hub. | yes      |
 
-Hierarchy      | Name             | Description                                        | Required
----------------|------------------|----------------------------------------------------|---------
-authentication | [authentication] | Authentication configuration with Azure Event Hub. | yes
+[authentication]: #authentication
 
-[authentication]: #authentication-block
+### `authentication`
 
-### authentication block
+<span class="badge docs-labels__stage docs-labels__item">Required</span>
 
 The `authentication` block defines the authentication method when communicating with Azure Event Hub.
 
-Name                | Type           | Description                                                               | Default | Required
---------------------|----------------|---------------------------------------------------------------------------|---------|---------
-`mechanism`         | `string`       | Authentication mechanism.                                                 |         | yes
-`connection_string` | `secret`       | Event Hubs ConnectionString for authentication on Azure Cloud.            |         | no
-`scopes`            | `list(string)` | Access token scopes. Default is `fully_qualified_namespace` without port. |         | no
+| Name                | Type           | Description                                                               | Default | Required |
+| ------------------- | -------------- | ------------------------------------------------------------------------- | ------- | -------- |
+| `mechanism`         | `string`       | Authentication mechanism.                                                 |         | yes      |
+| `connection_string` | `secret`       | Event Hubs ConnectionString for authentication on Azure Cloud.            |         | no       |
+| `scopes`            | `list(string)` | Access token scopes. Default is `fully_qualified_namespace` without port. |         | no       |
 
-`mechanism` supports the values `"connection_string"` and `"oauth"`. If `"connection_string"` is used,
-you must set the `connection_string` attribute. If `"oauth"` is used, you must configure one of the supported credential
-types as documented
-here: https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azidentity/README.md#credential-types via environment
-variables or Azure CLI.
+`mechanism` supports the values `"connection_string"` and `"oauth"`.
+If `"connection_string"` is used, you must set the `connection_string` attribute.
+If `"oauth"` is used, you must configure one of the [supported credential types](https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azidentity/README.md#credential-types) via environment variables or Azure CLI.
 
 ## Exported fields
 
@@ -104,8 +106,7 @@ variables or Azure CLI.
 
 ## Component health
 
-`loki.source.azure_event_hubs` is only reported as unhealthy if given an invalid
-configuration.
+`loki.source.azure_event_hubs` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug information
 
@@ -113,23 +114,23 @@ configuration.
 
 ## Example
 
-This example consumes messages from Azure Event Hub and uses OAuth to authenticate itself.
+This example consumes messages from Azure Event Hub and uses OAuth 2.0 to authenticate itself.
 
 ```alloy
 loki.source.azure_event_hubs "example" {
-	fully_qualified_namespace = "my-ns.servicebus.windows.net:9093"
-	event_hubs                = ["gw-logs"]
-	forward_to                = [loki.write.example.receiver]
+    fully_qualified_namespace = "my-ns.servicebus.windows.net:9093"
+    event_hubs                = ["gw-logs"]
+    forward_to                = [loki.write.example.receiver]
 
-	authentication {
-		mechanism = "oauth"
-	}
+    authentication {
+        mechanism = "oauth"
+    }
 }
 
 loki.write "example" {
-	endpoint {
-		url = "loki:3100/api/v1/push"
-	}
+    endpoint {
+        url = "loki:3100/api/v1/push"
+    }
 }
 ```
 
diff --git a/docs/sources/reference/components/loki/loki.source.cloudflare.md b/docs/sources/reference/components/loki/loki.source.cloudflare.md
index 7bc1284e9e..693c5d2aa7 100644
--- a/docs/sources/reference/components/loki/loki.source.cloudflare.md
+++ b/docs/sources/reference/components/loki/loki.source.cloudflare.md
@@ -4,10 +4,12 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.cloudflare/ # /docs/alloy/latest/reference/components/loki.source.cloudflare/
 description: Learn about loki.source.cloudflare
+labels:
+  stage: general-availability
 title: loki.source.cloudflare
 ---
 
-# loki.source.cloudflare
+# `loki.source.cloudflare`
 
 `loki.source.cloudflare` pulls logs from the Cloudflare Logpull API and forwards them to other `loki.*` components.
 
@@ -18,59 +20,109 @@ You can specify multiple `loki.source.cloudflare` components by giving them diff
 ## Usage
 
 ```alloy
-loki.source.cloudflare "LABEL" {
-  zone_id   = "ZONE_ID"
-  api_token = "API_TOKEN"
+loki.source.cloudflare "<LABEL>" {
+  zone_id   = "<ZONE_ID>"
+  api_token = "<API_TOKEN>"
 
-  forward_to = RECEIVER_LIST
+  forward_to = <RECEIVER_LIST>
 }
 ```
 
 ## Arguments
 
-`loki.source.cloudflare` supports the following arguments:
+You can use the following arguments with `loki.source.cloudflare`:
 
-Name                | Type                 | Description                                                                   | Default     | Required
---------------------|----------------------|-------------------------------------------------------------------------------|-------------|---------
-`forward_to`        | `list(LogsReceiver)` | List of receivers to send log entries to.                                     |             | yes
-`api_token`         | `string`             | The API token to authenticate with.                                           |             | yes
-`zone_id`           | `string`             | The Cloudflare zone ID to use.                                                |             | yes
-`labels`            | `map(string)`        | The labels to associate with incoming log entries.                            | `{}`        | no
-`workers`           | `int`                | The number of workers to use for parsing logs.                                | `3`         | no
-`pull_range`        | `duration`           | The timeframe to fetch for each pull request.                                 | `"1m"`      | no
-`fields_type`       | `string`             | The set of fields to fetch for log entries.                                   | `"default"` | no
-`additional_fields` | `list(string)`       | The additional list of fields to supplement those provided via `fields_type`. |             | no
+| Name                | Type                 | Description                                                                   | Default     | Required |
+| ------------------- | -------------------- | ----------------------------------------------------------------------------- | ----------- | -------- |
+| `api_token`         | `string`             | The API token to authenticate with.                                           |             | yes      |
+| `forward_to`        | `list(LogsReceiver)` | List of receivers to send log entries to.                                     |             | yes      |
+| `zone_id`           | `string`             | The Cloudflare zone ID to use.                                                |             | yes      |
+| `additional_fields` | `list(string)`       | The additional list of fields to supplement those provided via `fields_type`. |             | no       |
+| `fields_type`       | `string`             | The set of fields to fetch for log entries.                                   | `"default"` | no       |
+| `labels`            | `map(string)`        | The labels to associate with incoming log entries.                            | `{}`        | no       |
+| `pull_range`        | `duration`           | The timeframe to fetch for each pull request.                                 | `"1m"`      | no       |
+| `workers`           | `int`                | The number of workers to use for parsing logs.                                | `3`         | no       |
 
-
-By default `loki.source.cloudflare` fetches logs with the `default` set of
-fields. Here are the different sets of `fields_type` available for selection,
-and the fields they include:
+By default `loki.source.cloudflare` fetches logs with the `default` set of fields.
+The following list shows the different sets of `fields_type` available for selection, and the fields they include:
 
 * `default` includes:
-```
-"ClientIP", "ClientRequestHost", "ClientRequestMethod", "ClientRequestURI", "EdgeEndTimestamp", "EdgeResponseBytes", "EdgeRequestHost", "EdgeResponseStatus", "EdgeStartTimestamp", "RayID"
-```
-plus any extra fields provided via `additional_fields` argument.
-
+{{< column-list >}}
+  * `"ClientIP"`
+  * `"ClientRequestHost"`
+  * `"ClientRequestMethod"`
+  * `"ClientRequestURI"`
+  * `"EdgeEndTimestamp"`
+  * `"EdgeResponseBytes"`
+  * `"EdgeRequestHost"`
+  * `"EdgeResponseStatus"`
+  * `"EdgeStartTimestamp"`
+  * `"RayID"`
+{{< /column-list >}}
+
+  plus any extra fields provided via `additional_fields` argument.
 * `minimal` includes all `default` fields and adds:
-```
-"ZoneID", "ClientSSLProtocol", "ClientRequestProtocol", "ClientRequestPath", "ClientRequestUserAgent", "ClientRequestReferer", "EdgeColoCode", "ClientCountry", "CacheCacheStatus", "CacheResponseStatus", "EdgeResponseContentType"
-```
-plus any extra fields provided via `additional_fields` argument.
-
+{{< column-list >}}
+  * `"ZoneID"`
+  * `"ClientSSLProtocol"`
+  * `"ClientRequestProtocol"`
+  * `"ClientRequestPath"`
+  * `"ClientRequestUserAgent"`
+  * `"ClientRequestReferer"`
+  * `"EdgeColoCode"`
+  * `"ClientCountry"`
+  * `"CacheCacheStatus"`
+  * `"CacheResponseStatus"`
+  * `"EdgeResponseContentType"`
+{{< /column-list >}}
+   plus any extra fields provided via `additional_fields` argument.
 * `extended` includes all `minimal` fields and adds:
-```
-"ClientSSLCipher", "ClientASN", "ClientIPClass", "CacheResponseBytes", "EdgePathingOp", "EdgePathingSrc", "EdgePathingStatus", "ParentRayID", "WorkerCPUTime", "WorkerStatus", "WorkerSubrequest", "WorkerSubrequestCount", "OriginIP", "OriginResponseStatus", "OriginSSLProtocol", "OriginResponseHTTPExpires", "OriginResponseHTTPLastModified"
-```
-plus any extra fields provided via `additional_fields` argument.
-
+{{< column-list >}}
+  * `"ClientSSLCipher"`
+  * `"ClientASN"`
+  * `"ClientIPClass"`
+  * `"CacheResponseBytes"`
+  * `"EdgePathingOp"`
+  * `"EdgePathingSrc"`
+  * `"EdgePathingStatus"`
+  * `"ParentRayID"`
+  * `"WorkerCPUTime"`
+  * `"WorkerStatus"`
+  * `"WorkerSubrequest"`
+  * `"WorkerSubrequestCount"`
+  * `"OriginIP"`
+  * `"OriginResponseStatus"`
+  * `"OriginSSLProtocol"`
+  * `"OriginResponseHTTPExpires"`
+  * `"OriginResponseHTTPLastModified"`
+ {{< /column-list >}}
+  plus any extra fields provided via `additional_fields` argument.
 * `all` includes all `extended` fields and adds:
-```
- "BotScore", "BotScoreSrc", "BotTags", "ClientRequestBytes", "ClientSrcPort", "ClientXRequestedWith", "CacheTieredFill", "EdgeResponseCompressionRatio", "EdgeServerIP", "FirewallMatchesSources", "FirewallMatchesActions", "FirewallMatchesRuleIDs", "OriginResponseBytes", "OriginResponseTime", "ClientDeviceType", "WAFFlags", "WAFMatchedVar", "EdgeColoID", "RequestHeaders", "ResponseHeaders", "ClientRequestSource"`
-```
-
-plus any extra fields provided via `additional_fields` argument. This is still relevant in this case if new fields are made available via Cloudflare API but are not yet included in `all`.
-
+{{< column-list >}}
+  * `"BotScore"`
+  * `"BotScoreSrc"`
+  * `"BotTags"`
+  * `"ClientRequestBytes"`
+  * `"ClientSrcPort"`
+  * `"ClientXRequestedWith"`
+  * `"CacheTieredFill"`
+  * `"EdgeResponseCompressionRatio"`
+  * `"EdgeServerIP"`
+  * `"FirewallMatchesSources"`
+  * `"FirewallMatchesActions"`
+  * `"FirewallMatchesRuleIDs"`
+  * `"OriginResponseBytes"`
+  * `"OriginResponseTime"`
+  * `"ClientDeviceType"`
+  * `"WAFFlags"`
+  * `"WAFMatchedVar"`
+  * `"EdgeColoID"`
+  * `"RequestHeaders"`
+  * `"ResponseHeaders"`
+  * `"ClientRequestSource"`
+{{< /column-list >}}
+  plus any extra fields provided via `additional_fields` argument.
+  This is still relevant in this case if new fields are made available via Cloudflare API but aren't yet included in `all`.
 * `custom` includes only the fields defined in `additional_fields`.
 
 The component saves the last successfully fetched timestamp in its positions file.
@@ -157,6 +209,10 @@ A sample log looks like this:
 }
 ```
 
+## Blocks
+
+The `loki.source.cloudflare` component doesn't support any blocks. You can configure this component with arguments.
+
 ## Exported fields
 
 `loki.source.cloudflare` doesn't export any fields.
@@ -168,6 +224,7 @@ A sample log looks like this:
 ## Debug information
 
 `loki.source.cloudflare` exposes the following debug information:
+
 * Whether the target is ready and reading logs from the API.
 * The Cloudflare zone ID.
 * The last error reported, if any.
@@ -176,13 +233,13 @@ A sample log looks like this:
 * The set of fields being fetched.
 
 ## Debug metrics
+
 * `loki_source_cloudflare_target_entries_total` (counter): Total number of successful entries sent via the cloudflare target.
 * `loki_source_cloudflare_target_last_requested_end_timestamp` (gauge): The last cloudflare request end timestamp fetched, for calculating how far behind the target is.
 
 ## Example
 
-This example pulls logs from Cloudflare's API and forwards them to a
-`loki.write` component.
+This example pulls logs from Cloudflare's API and forwards them to a `loki.write` component.
 
 ```alloy
 loki.source.cloudflare "dev" {
@@ -198,6 +255,7 @@ loki.write "local" {
   }
 }
 ```
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.docker.md b/docs/sources/reference/components/loki/loki.source.docker.md
index 41f348a26c..1981927c74 100644
--- a/docs/sources/reference/components/loki/loki.source.docker.md
+++ b/docs/sources/reference/components/loki/loki.source.docker.md
@@ -3,14 +3,16 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.docker/ # /docs/alloy/latest/reference/components/loki.source.docker/
 description: Learn about loki.source.docker
+labels:
+  stage: general-availability
 title: loki.source.docker
 ---
 
-# loki.source.docker
+# `loki.source.docker`
 
 `loki.source.docker` reads log entries from Docker containers and forwards them to other `loki.*` components. Each component can read from a single Docker daemon.
 
-Multiple `loki.source.docker` components can be specified by giving them different labels.
+You can specify multiple `loki.source.docker` components by giving them different labels.
 
 ## Usage
 
@@ -23,69 +25,69 @@ loki.source.docker "LABEL" {
 ```
 
 ## Arguments
+
 The component starts a new reader for each of the given `targets` and fans out log entries to the list of receivers passed in `forward_to`.
 
-`loki.source.docker` supports the following arguments:
+You can use the following arguments with `loki.source.docker`:
 
-Name               | Type                 | Description                                                                    | Default | Required
--------------------|----------------------|--------------------------------------------------------------------------------|---------|---------
-`host`             | `string`             | Address of the Docker daemon.                                                  |         | yes
-`targets`          | `list(map(string))`  | List of containers to read logs from.                                          |         | yes
-`forward_to`       | `list(LogsReceiver)` | List of receivers to send log entries to.                                      |         | yes
-`labels`           | `map(string)`        | The default set of labels to apply on entries.                                 | `"{}"`  | yes
-`relabel_rules`    | `RelabelRules`       | Relabeling rules to apply on log entries.                                      | `"{}"`  | no
-`refresh_interval` | `duration`           | The refresh interval to use when connecting to the Docker daemon over HTTP(S). | `"60s"` | no
+| Name               | Type                 | Description                                                                    | Default | Required |
+| ------------------ | -------------------- | ------------------------------------------------------------------------------ | ------- | -------- |
+| `forward_to`       | `list(LogsReceiver)` | List of receivers to send log entries to.                                      |         | yes      |
+| `host`             | `string`             | Address of the Docker daemon.                                                  |         | yes      |
+| `labels`           | `map(string)`        | The default set of labels to apply on entries.                                 | `"{}"`  | yes      |
+| `targets`          | `list(map(string))`  | List of containers to read logs from.                                          |         | yes      |
+| `refresh_interval` | `duration`           | The refresh interval to use when connecting to the Docker daemon over HTTP(S). | `"60s"` | no       |
+| `relabel_rules`    | `RelabelRules`       | Relabeling rules to apply on log entries.                                      | `"{}"`  | no       |
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.docker`:
+You can use the following blocks with `loki.source.docker`:
 
-Hierarchy                    | Block             | Description                                              | Required
------------------------------|-------------------|----------------------------------------------------------|---------
-client                       | [client][]        | HTTP client settings when connecting to the endpoint.    | no
-client > basic_auth          | [basic_auth][]    | Configure basic_auth for authenticating to the endpoint. | no
-client > authorization       | [authorization][] | Configure generic authorization to the endpoint.         | no
-client > oauth2              | [oauth2][]        | Configure OAuth2 for authenticating to the endpoint.     | no
-client > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
-client > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
+| Block                                            | Description                                                | Required |
+| ------------------------------------------------ | ---------------------------------------------------------- | -------- |
+| [`client`][client]                               | HTTP client settings when connecting to the endpoint.      | no       |
+| `client` > [`authorization`][authorization]      | Configure generic authorization to the endpoint.           | no       |
+| `client` > [`basic_auth`][basic_auth]            | Configure `basic_auth` for authenticating to the endpoint. | no       |
+| `client` > [`oauth2`][oauth2]                    | Configure OAuth 2.0 for authenticating to the endpoint.    | no       |
+| `client` > `oauth2` > [`tls_config`][tls_config] | Configure TLS settings for connecting to the endpoint.     | no       |
+| `client` > [`tls_config`][tls_config]            | Configure TLS settings for connecting to the endpoint.     | no       |
 
-The `>` symbol indicates deeper levels of nesting. For example, `client >
-basic_auth` refers to an `basic_auth` block defined inside a `client` block.
+The > symbol indicates deeper levels of nesting.
+For example, `client` > `basic_auth` refers to an `basic_auth` block defined inside a `client` block.
 
-These blocks are only applicable when connecting to a Docker daemon over HTTP
-or HTTPS and has no effect when connecting via a `unix:///` socket
+These blocks are only applicable when connecting to a Docker daemon over HTTP or HTTPS and has no effect when connecting via a `unix:///` socket
 
-[client]: #client-block
-[basic_auth]: #basic_auth-block
-[authorization]: #authorization-block
-[oauth2]: #oauth2-block
-[tls_config]: #tls_config-block
+[authorization]: #authorization
+[basic_auth]: #basic_auth
+[client]: #client
+[oauth2]: #oauth2
+[tls_config]: #tls_config
 
-### client block
+### `client`
 
 The `client` block configures settings used to connect to HTTP(S) Docker daemons.
 
 {{< docs/shared lookup="reference/components/http-client-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### basic_auth block
+### `authorization`
 
-The `basic_auth` block configures basic authentication for HTTP(S) Docker daemons.
+The `authorization` block configures custom authorization to use for the Docker daemon.
 
-{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### authorization block
+### `basic_auth`
 
-The `authorization` block configures custom authorization to use for the Docker daemon.
+The `basic_auth` block configures basic authentication for HTTP(S) Docker daemons.
 
-{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### oauth2 block
+### `oauth2`
 
-The `oauth2` block configures OAuth2 authorization to use for the Docker daemon.
+The `oauth2` block configures OAuth 2.0 authorization to use for the Docker daemon.
 
 {{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### tls_config block
+### `tls_config`
 
 The `tls_config` block configures TLS settings for connecting to HTTPS Docker daemons.
 
@@ -93,16 +95,16 @@ The `tls_config` block configures TLS settings for connecting to HTTPS Docker da
 
 ## Exported fields
 
-`loki.source.docker` does not export any fields.
+`loki.source.docker` doesn't export any fields.
 
 ## Component health
 
-`loki.source.docker` is only reported as unhealthy if given an invalid
-configuration.
+`loki.source.docker` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug information
 
 `loki.source.docker` exposes some debug information per target:
+
 * Whether the target is ready to tail entries.
 * The labels associated with the target.
 * The most recent time a log line was read.
@@ -113,23 +115,16 @@ configuration.
 * `loki_source_docker_target_parsing_errors_total` (gauge): Total number of parsing errors while receiving Docker messages.
 
 ## Component behavior
-The component uses its data path, a directory named after the domain's
-fully qualified name, to store its _positions file_. The positions file is used
-to store read offsets, so that if a component or {{< param "PRODUCT_NAME" >}} restarts,
-`loki.source.docker` can pick up tailing from the same spot.
-
-If the target's argument contains multiple entries with the same container
-ID (for example as a result of `discovery.docker` picking up multiple exposed
-ports or networks), `loki.source.docker` will deduplicate them, and only keep
-the first of each container ID instances, based on the
-`__meta_docker_container_id` label. As such, the Docker daemon is queried
-for each container ID only once, and only one target will be available in the
-component's debug info.
+
+The component uses its data path, a directory named after the domain's fully qualified name, to store its _positions file_.
+The positions file is used to store read offsets, so that if a component or {{< param "PRODUCT_NAME" >}} restarts, `loki.source.docker` can pick up tailing from the same spot.
+
+If the target's argument contains multiple entries with the same container ID, for example, as a result of `discovery.docker` picking up multiple exposed ports or networks, `loki.source.docker` deduplicates them, and only keeps the first of each container ID instances, based on the `__meta_docker_container_id` label.
+As such, the Docker daemon is queried for each container ID only once, and only one target is available in the component's debug info.
 
 ## Example
 
-This example collects log entries from the files specified in the `targets`
-argument and forwards them to a `loki.write` component to be written to Loki.
+This example collects log entries from the files specified in the `targets` argument and forwards them to a `loki.write` component to be written to Loki.
 
 ```alloy
 discovery.docker "linux" {
diff --git a/docs/sources/reference/components/loki/loki.source.file.md b/docs/sources/reference/components/loki/loki.source.file.md
index 33eb867a8a..7002c19727 100644
--- a/docs/sources/reference/components/loki/loki.source.file.md
+++ b/docs/sources/reference/components/loki/loki.source.file.md
@@ -3,10 +3,12 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.file/ # /docs/alloy/latest/reference/components/loki.source.file/
 description: Learn about loki.source.file
+labels:
+  stage: general-availability
 title: loki.source.file
 ---
 
-# loki.source.file
+# `loki.source.file`
 
 `loki.source.file` reads log entries from files and forwards them to other `loki.*` components.
 New log entries are forwarded whenever a log entry line ends with the `\n` character.
@@ -31,22 +33,21 @@ loki.source.file "<LABEL>" {
 
 The component starts a new reader for each of the given `targets` and fans out log entries to the list of receivers passed in `forward_to`.
 
-`loki.source.file` supports the following arguments:
+You can use the following arguments with `loki.source.file`:
 
 | Name                    | Type                 | Description                                                                 | Default | Required |
-|-------------------------|----------------------|-----------------------------------------------------------------------------|---------|----------|
-| `targets`               | `list(map(string))`  | List of files to read from.                                                 |         | yes      |
+| ----------------------- | -------------------- | --------------------------------------------------------------------------- | ------- | -------- |
 | `forward_to`            | `list(LogsReceiver)` | List of receivers to send log entries to.                                   |         | yes      |
+| `targets`               | `list(map(string))`  | List of files to read from.                                                 |         | yes      |
 | `encoding`              | `string`             | The encoding to convert from when reading files.                            | `""`    | no       |
-| `tail_from_end`         | `bool`               | Whether a log file is tailed from the end if a stored position isn't found. | `false` | no       |
 | `legacy_positions_file` | `string`             | Allows conversion from legacy positions file.                               | `""`    | no       |
+| `tail_from_end`         | `bool`               | Whether a log file is tailed from the end if a stored position isn't found. | `false` | no       |
 
-The `encoding` argument must be a valid [IANA encoding][] name. If not set, it
-defaults to UTF-8.
+The `encoding` argument must be a valid [IANA encoding][] name.
+If not set, it defaults to UTF-8.
 
 You can use the `tail_from_end` argument when you want to tail a large file without reading its entire content.
-When set to true, only new logs will be read, ignoring the existing ones.
-
+When set to true, only new logs are read, ignoring the existing ones.
 
 {{< admonition type="note" >}}
 The `legacy_positions_file` argument is used when you are transitioning from legacy. The legacy positions file is rewritten into the new format.
@@ -58,48 +59,48 @@ The legacy positions file didn't have a concept of labels in the positions file,
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.file`:
+You can use the following blocks with `loki.source.file`:
 
-| Hierarchy     | Name              | Description                                                       | Required |
-|---------------|-------------------|-------------------------------------------------------------------|----------|
-| decompression | [decompression][] | Configure reading logs from compressed files.                     | no       |
-| file_watch    | [file_watch][]    | Configure how often files should be polled from disk for changes. | no       |
+| Name                             | Description                                                       | Required |
+| -------------------------------- | ----------------------------------------------------------------- | -------- |
+| [`decompression`][decompression] | Configure reading logs from compressed files.                     | no       |
+| [`file_watch`][file_watch]       | Configure how often files should be polled from disk for changes. | no       |
 
-[decompression]: #decompression-block
-[file_watch]: #file_watch-block
+[decompression]: #decompression
+[file_watch]: #file_watch
 
-### decompression block
+### `decompression`
 
-The `decompression` block contains configuration for reading logs from
-compressed files. The following arguments are supported:
+The `decompression` block contains configuration for reading logs from compressed files.
+The following arguments are supported:
 
 | Name            | Type       | Description                                                     | Default | Required |
 | --------------- | ---------- | --------------------------------------------------------------- | ------- | -------- |
 | `enabled`       | `bool`     | Whether decompression is enabled.                               |         | yes      |
-| `initial_delay` | `duration` | Time to wait before starting to read from new compressed files. | 0       | no       |
 | `format`        | `string`   | Compression format.                                             |         | yes      |
+| `initial_delay` | `duration` | Time to wait before starting to read from new compressed files. | 0       | no       |
 
 If you compress a file under a folder being scraped, `loki.source.file` might try to ingest your file before you finish compressing it.
 To avoid it, pick an `initial_delay` that's long enough to avoid it.
 
 Currently supported compression formats are:
 
-- `gz` - for Gzip
-- `z` - for zlib
-- `bz2` - for bzip2
+* `gz` - for Gzip
+* `z` - for zlib
+* `bz2` - for bzip2
 
 The component can only support one compression format at a time.
 To handle multiple formats, you must create multiple components.
 
-### file_watch block
+### `file_watch`
 
 The `file_watch` block configures how often log files are polled from disk for changes.
 The following arguments are supported:
 
 | Name                 | Type       | Description                          | Default | Required |
 | -------------------- | ---------- | ------------------------------------ | ------- | -------- |
-| `min_poll_frequency` | `duration` | Minimum frequency to poll for files. | 250ms   | no       |
 | `max_poll_frequency` | `duration` | Maximum frequency to poll for files. | 250ms   | no       |
+| `min_poll_frequency` | `duration` | Minimum frequency to poll for files. | 250ms   | no       |
 
 If no file changes are detected, the poll frequency doubles until a file change is detected or the poll frequency reaches the `max_poll_frequency`.
 
@@ -117,17 +118,17 @@ If file changes are detected, the poll frequency is reset to `min_poll_frequency
 
 `loki.source.file` exposes some target-level debug information per reader:
 
-- The tailed path.
-- Whether the reader is running.
-- The last recorded read offset in the positions file.
+* The tailed path.
+* Whether the reader is running.
+* The last recorded read offset in the positions file.
 
 ## Debug metrics
 
-- `loki_source_file_read_bytes_total` (gauge): Number of bytes read.
-- `loki_source_file_file_bytes_total` (gauge): Number of bytes total.
-- `loki_source_file_read_lines_total` (counter): Number of lines read.
-- `loki_source_file_encoding_failures_total` (counter): Number of encoding failures.
-- `loki_source_file_files_active_total` (gauge): Number of active files.
+* `loki_source_file_encoding_failures_total` (counter): Number of encoding failures.
+* `loki_source_file_file_bytes_total` (gauge): Number of bytes total.
+* `loki_source_file_files_active_total` (gauge): Number of active files.
+* `loki_source_file_read_bytes_total` (gauge): Number of bytes read.
+* `loki_source_file_read_lines_total` (counter): Number of lines read.
 
 ## Component behavior
 
@@ -155,6 +156,8 @@ When it's added back on, `loki.source.file` starts reading it from the beginning
 
 ## Examples
 
+The following examples demonstrate how you can collect log entries with `loki.source.file`.
+
 ### Static targets
 
 This example collects log entries from the files specified in the targets argument and forwards them to a `loki.write` component.
diff --git a/docs/sources/reference/components/loki/loki.source.gcplog.md b/docs/sources/reference/components/loki/loki.source.gcplog.md
index a105505676..b88f314c0b 100644
--- a/docs/sources/reference/components/loki/loki.source.gcplog.md
+++ b/docs/sources/reference/components/loki/loki.source.gcplog.md
@@ -3,30 +3,29 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.gcplog/ # /docs/alloy/latest/reference/components/loki.source.gcplog/
 description: Learn about loki.source.gcplog
+labels:
+  stage: general-availability
 title: loki.source.gcplog
 ---
 
-# loki.source.gcplog
+# `loki.source.gcplog`
 
-`loki.source.gcplog` retrieves logs from cloud resources such as GCS buckets,
-load balancers, or Kubernetes clusters running on GCP by making use of Pub/Sub
-[subscriptions](https://cloud.google.com/pubsub/docs/subscriber).
+`loki.source.gcplog` retrieves logs from cloud resources such as GCS buckets, load balancers, or Kubernetes clusters running on GCP by making use of Pub/Sub [subscriptions](https://cloud.google.com/pubsub/docs/subscriber).
 
-The component uses either the 'push' or 'pull' strategy to retrieve log
-entries and forward them to the list of receivers in `forward_to`.
+The component uses either the 'push' or 'pull' strategy to retrieve log entries and forward them to the list of receivers in `forward_to`.
 
-Multiple `loki.source.gcplog` components can be specified by giving them different labels.
+You can specify multiple `loki.source.gcplog` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.source.gcplog "LABEL" {
+loki.source.gcplog "<LABEL>" {
   pull {
-    project_id   = "PROJECT_ID"
-    subscription = "SUB_ID"
+    project_id   = "<PROJECT_ID>"
+    subscription = "<SUB_ID>"
   }
 
-  forward_to = RECEIVER_LIST
+  forward_to = <RECEIVER_LIST>
 }
 ```
 
@@ -35,123 +34,114 @@ loki.source.gcplog "LABEL" {
 `loki.source.gcplog` supports the following arguments:
 
 | Name            | Type                 | Description                               | Default | Required |
-|-----------------|----------------------|-------------------------------------------|---------|----------|
+| --------------- | -------------------- | ----------------------------------------- | ------- | -------- |
 | `forward_to`    | `list(LogsReceiver)` | List of receivers to send log entries to. |         | yes      |
 | `relabel_rules` | `RelabelRules`       | Relabeling rules to apply on log entries. | "{}"    | no       |
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`loki.source.gcplog`:
+You can use the following blocks with `loki.source.gcplog`:
 
-| Hierarchy   | Name     | Description                                                                   | Required |
-|-------------|----------|-------------------------------------------------------------------------------|----------|
-| pull        | [pull][] | Configures a target to pull logs from a GCP Pub/Sub subscription.             | no       |
-| push        | [push][] | Configures a server to receive logs as GCP Pub/Sub push requests.             | no       |
-| push > http | [http][] | Configures the HTTP server that receives requests when using the `push` mode. | no       |
-| push > grpc | [grpc][] | Configures the gRPC server that receives requests when using the `push` mode. | no       |
+| Name                    | Description                                                                   | Required |
+| ----------------------- | ----------------------------------------------------------------------------- | -------- |
+| [`pull`][pull]          | Configures a target to pull logs from a GCP Pub/Sub subscription.             | no       |
+| [`push`][push]          | Configures a server to receive logs as GCP Pub/Sub push requests.             | no       |
+| `push` > [`grpc`][grpc] | Configures the gRPC server that receives requests when using the `push` mode. | no       |
+| `push` > [`http`][http] | Configures the HTTP server that receives requests when using the `push` mode. | no       |
 
-The `pull` and `push` inner blocks are mutually exclusive; a component must
-contain exactly one of the two in its definition. The `http` and `grpc` block
-are just used when the `push` block is configured.
+The > symbol indicates deeper levels of nesting.
+For example, `push` > `grpc` refers to a `grpc` block defined inside a `push` block.
+
+The `pull` and `push` inner blocks are mutually exclusive.
+A component must contain exactly one of the two in its definition.
+The `http` and `grpc` block are just used when the `push` block is configured.
 
-[pull]: #pull-block
-[push]: #push-block
-[http]: #http
 [grpc]: #grpc
+[http]: #http
+[pull]: #pull
+[push]: #push
 
-### pull block
+### `pull`
 
-The `pull` block defines which GCP project ID and subscription to read log
-entries from.
+The `pull` block defines which GCP project ID and subscription to read log entries from.
 
-The following arguments can be used to configure the `pull` block. Any omitted
-fields take their default values.
+The following arguments can be used to configure the `pull` block.
+Any omitted fields take their default values.
 
 | Name                     | Type          | Description                                                               | Default | Required |
-|--------------------------|---------------|---------------------------------------------------------------------------|---------|----------|
+| ------------------------ | ------------- | ------------------------------------------------------------------------- | ------- | -------- |
 | `project_id`             | `string`      | The GCP project id the subscription belongs to.                           |         | yes      |
 | `subscription`           | `string`      | The subscription to pull logs from.                                       |         | yes      |
 | `labels`                 | `map(string)` | Additional labels to associate with incoming logs.                        | `"{}"`  | no       |
-| `use_incoming_timestamp` | `bool`        | Whether to use the incoming log timestamp.                                | `false` | no       |
 | `use_full_line`          | `bool`        | Send the full line from Cloud Logging even if `textPayload` is available. | `false` | no       |
+| `use_incoming_timestamp` | `bool`        | Whether to use the incoming log timestamp.                                | `false` | no       |
 
-To make use of the `pull` strategy, the GCP project must have been
-[configured](/docs/loki/next/clients/promtail/gcplog-cloud/)
-to forward its cloud resource logs onto a Pub/Sub topic for
-`loki.source.gcplog` to consume.
+To make use of the `pull` strategy, the GCP project must have been [configured](/docs/loki/next/clients/promtail/gcplog-cloud/) to forward its cloud resource logs onto a Pub/Sub topic for `loki.source.gcplog` to consume.
 
-Typically, the host system also needs to have its GCP
-[credentials](https://cloud.google.com/docs/authentication/application-default-credentials)
-configured. One way to do it is to point the `GOOGLE_APPLICATION_CREDENTIALS`
-environment variable to the location of a credential configuration JSON file or
-a service account key.
+Typically, the host system also needs to have its GCP [credentials](https://cloud.google.com/docs/authentication/application-default-credentials) configured.
+One way to do it, is to point the `GOOGLE_APPLICATION_CREDENTIALS` environment variable to the location of a credential configuration JSON file or a service account key.
 
-### push block
+### `push`
 
-The `push` block defines the configuration of the server that receives
-push requests from GCP's Pub/Sub servers.
+The `push` block defines the configuration of the server that receives push requests from the GCP Pub/Sub servers.
 
-The following arguments can be used to configure the `push` block. Any omitted
-fields take their default values.
+The following arguments can be used to configure the `push` block.
+Any omitted fields take their default values.
 
-| Name                        | Type          | Description                                                                        | Default | Required |
-|-----------------------------|---------------|------------------------------------------------------------------------------------|---------|----------|
-| `graceful_shutdown_timeout` | `duration`    | Timeout for servers graceful shutdown. If configured, should be greater than zero. | "30s"   | no       |
-| `push_timeout`              | `duration`    | Sets a maximum processing time for each incoming GCP log entry.                    | `"0s"`  | no       |
-| `labels`                    | `map(string)` | Additional labels to associate with incoming entries.                              | `"{}"`  | no       |
-| `use_incoming_timestamp`    | `bool`        | Whether to use the incoming entry timestamp.                                       | `false` | no       |
-| `use_full_line`             | `bool`        | Send the full line from Cloud Logging even if `textPayload` is available. By default, if `textPayload` is present in the line, then it's used as log line | `false` | no  |
+| Name                        | Type          | Description                                                                                                                                                | Default | Required |
+| --------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | -------- |
+| `graceful_shutdown_timeout` | `duration`    | Timeout for servers graceful shutdown. If configured, should be greater than zero.                                                                         | "30s"   | no       |
+| `labels`                    | `map(string)` | Additional labels to associate with incoming entries.                                                                                                      | `"{}"`  | no       |
+| `push_timeout`              | `duration`    | Sets a maximum processing time for each incoming GCP log entry.                                                                                            | `"0s"`  | no       |
+| `use_full_line`             | `bool`        | Send the full line from Cloud Logging even if `textPayload` is available. By default, if `textPayload` is present in the line, then it's used as log line. | `false` | no       |
+| `use_incoming_timestamp`    | `bool`        | Whether to use the incoming entry timestamp.                                                                                                               | `false` | no       |
 
-The server listens for POST requests from GCP's Push subscriptions on `HOST:PORT/gcp/api/v1/push`.
+The server listens for POST requests from GCP Push subscriptions on `HOST:PORT/gcp/api/v1/push`.
 
-By default, for both strategies the component assigns the log entry timestamp
-as the time it was processed, except if `use_incoming_timestamp` is set to true.
+By default, for both strategies the component assigns the log entry timestamp as the time it was processed, except if `use_incoming_timestamp` is set to true.
 
 The `labels` map is applied to every entry that passes through the component.
 
-### http
+### `grpc`
 
-{{< docs/shared lookup="reference/components/loki-server-http.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/loki-server-grpc.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### grpc
+### `http`
 
-{{< docs/shared lookup="reference/components/loki-server-grpc.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/loki-server-http.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Exported fields
 
-`loki.source.gcplog` does not export any fields.
+`loki.source.gcplog` doesn't export any fields.
 
 ## Component health
 
-`loki.source.gcplog` is only reported as unhealthy if given an invalid
-configuration.
+`loki.source.gcplog` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug information
 
 `loki.source.gcplog` exposes some debug information per gcplog listener:
+
 * The configured strategy.
 * Their label set.
 * When using a `push` strategy, the listen address.
 
 ## Debug metrics
 
-When using the `pull` strategy, the component exposes the following debug
-metrics:
+When using the `pull` strategy, the component exposes the following debug metrics:
+
 * `loki_source_gcplog_pull_entries_total` (counter): Number of entries received by the gcplog target.
-* `loki_source_gcplog_pull_parsing_errors_total` (counter): Total number of parsing errors while receiving gcplog messages.
 * `loki_source_gcplog_pull_last_success_scrape` (gauge): Timestamp of target's last successful poll.
+* `loki_source_gcplog_pull_parsing_errors_total` (counter): Total number of parsing errors while receiving gcplog messages.
+
+When using the `push` strategy, the component exposes the following debug metrics:
 
-When using the `push` strategy, the component exposes the following debug
-metrics:
 * `loki_source_gcplog_push_entries_total` (counter): Number of entries received by the gcplog target.
 * `loki_source_gcplog_push_entries_total` (counter): Number of parsing errors while receiving gcplog messages.
 
-
 ## Example
 
-This example listens for GCP Pub/Sub PushRequests on `0.0.0.0:8080` and
-forwards them to a `loki.write` component.
+This example listens for GCP Pub/Sub PushRequests on `0.0.0.0:8080` and forwards them to a `loki.write` component.
 
 ```alloy
 loki.source.gcplog "local" {
@@ -167,8 +157,7 @@ loki.write "local" {
 }
 ```
 
-On the other hand, if we need the server to listen on `0.0.0.0:4040`, and forwards them
-to a `loki.write` component.
+This example listens for GCP Pub/Sub PushRequests on `0.0.0.0:4040`, and forwards them to a `loki.write` component.
 
 ```alloy
 loki.source.gcplog "local" {
@@ -187,6 +176,7 @@ loki.write "local" {
   }
 }
 ```
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.gelf.md b/docs/sources/reference/components/loki/loki.source.gelf.md
index 217067faa9..bbbccd7cbb 100644
--- a/docs/sources/reference/components/loki/loki.source.gelf.md
+++ b/docs/sources/reference/components/loki/loki.source.gelf.md
@@ -3,62 +3,63 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.gelf/ # /docs/alloy/latest/reference/components/loki.source.gelf/
 description: Learn about loki.source.gelf
+labels:
+  stage: general-availability
 title: loki.source.gelf
 ---
 
-# loki.source.gelf
+# `loki.source.gelf`
 
-`loki.source.gelf` reads [Graylog Extended Long Format (GELF) logs](https://github.com/Graylog2/graylog2-server) from a UDP listener and forwards them to other
-`loki.*` components.
+`loki.source.gelf` reads [Graylog Extended Long Format (GELF) logs](https://github.com/Graylog2/graylog2-server) from a UDP listener and forwards them to other `loki.*` components.
 
-Multiple `loki.source.gelf` components can be specified by giving them
-different labels and ports.
+You can specify multiple `loki.source.gelf` components by giving them different labels and ports.
 
 ## Usage
 
 ```alloy
-loki.source.gelf "LABEL" {
-  forward_to    = RECEIVER_LIST
+loki.source.gelf "<LABEL>" {
+  forward_to    = <RECEIVER_LIST>
 }
 ```
 
 ## Arguments
-The component starts a new UDP listener and fans out
-log entries to the list of receivers passed in `forward_to`.
 
-`loki.source.gelf` supports the following arguments:
+The component starts a new UDP listener and fans out log entries to the list of receivers passed in `forward_to`.
 
-Name                     | Type           | Description                                                                | Default         | Required
--------------------------|----------------|----------------------------------------------------------------------------|-----------------|---------
-`listen_address`         | `string`       | UDP address and port to listen for Graylog messages.                       | `0.0.0.0:12201` | no
-`use_incoming_timestamp` | `bool`         | When false, assigns the current timestamp to the log when it was processed | `false`         | no
-`relabel_rules`          | `RelabelRules` | Relabeling rules to apply on log entries.                                  | "{}"            | no
+You can use the following arguments with `loki.source.gelf`:
 
+| Name                     | Type           | Description                                                                | Default         | Required |
+| ------------------------ | -------------- | -------------------------------------------------------------------------- | --------------- | -------- |
+| `listen_address`         | `string`       | UDP address and port to listen for Graylog messages.                       | `0.0.0.0:12201` | no       |
+| `relabel_rules`          | `RelabelRules` | Relabeling rules to apply on log entries.                                  | "{}"            | no       |
+| `use_incoming_timestamp` | `bool`         | When false, assigns the current timestamp to the log when it was processed | `false`         | no       |
 
-> **NOTE**: GELF logs can be sent uncompressed or compressed with GZIP or ZLIB.
-> A `job` label is added with the full name of the component `loki.source.gelf.LABEL`.
+{{< admonition type="note" >}}
+GELF logs can be sent uncompressed or compressed with GZIP or ZLIB.
+A `job` label is added with the full name of the component `loki.source.gelf.LABEL`.
+{{< /admonition >}}
 
-The `relabel_rules` argument can make use of the `rules` export from a
-[loki.relabel][] component to apply one or more relabling rules to log entries
-before they're forward to the list of receivers specified in `forward_to`.
+The `relabel_rules` argument can make use of the `rules` export from a [`loki.relabel`][loki.relabel] component to apply one or more relabling rules to log entries before they're forward to the list of receivers specified in `forward_to`.
 
 Incoming messages have the following internal labels available:
 
-* `__gelf_message_level`: The GELF level as a string.
-* `__gelf_message_host`: The host sending the GELF message.
-* `__gelf_message_host`: The GELF level message version sent by the client.
 * `__gelf_message_facility`: The GELF facility.
+* `__gelf_message_host`: The GELF level message version sent by the client.
+* `__gelf_message_host`: The host sending the GELF message.
+* `__gelf_message_level`: The GELF level as a string.
 
-All labels starting with `__` are removed prior to forwarding log entries. To
-keep these labels, relabel them using a [loki.relabel][] component and pass its
-`rules` export to the `relabel_rules` argument.
+All labels starting with `__` are removed prior to forwarding log entries.
+To keep these labels, relabel them using a [`loki.relabel`][loki.relabel] component and pass its `rules` export to the `relabel_rules` argument.
 
 [loki.relabel]: ../loki.relabel/
 
+## Blocks
+
+The `loki.source.gelf` component doesn't support any blocks. You can configure this component with arguments.
+
 ## Component health
 
-`loki.source.gelf` is only reported as unhealthy if given an invalid
-configuration.
+`loki.source.gelf` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug Metrics
 
@@ -86,6 +87,7 @@ loki.write "endpoint" {
   }
 }
 ```
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.heroku.md b/docs/sources/reference/components/loki/loki.source.heroku.md
index fee46d818b..ff75e8c882 100644
--- a/docs/sources/reference/components/loki/loki.source.heroku.md
+++ b/docs/sources/reference/components/loki/loki.source.heroku.md
@@ -3,92 +3,90 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.heroku/ # /docs/alloy/latest/reference/components/loki.source.heroku/
 description: Learn about loki.source.heroku
+labels:
+  stage: general-availability
 title: loki.source.heroku
 ---
 
-# loki.source.heroku
+# `loki.source.heroku`
 
-`loki.source.heroku` listens for Heroku messages over TCP connections
-and forwards them to other `loki.*` components.
+`loki.source.heroku` listens for Heroku messages over TCP connections and forwards them to other `loki.*` components.
 
-The component starts a new heroku listener for the given `listener`
-block and fans out incoming entries to the list of receivers in `forward_to`.
+The component starts a new Heroku listener for the given `listener` block and fans out incoming entries to the list of receivers in `forward_to`.
 
-Before using `loki.source.heroku`, Heroku should be configured with the URL where {{< param "PRODUCT_NAME" >}} will be listening.
+Before using `loki.source.heroku`, Heroku should be configured with the URL where {{< param "PRODUCT_NAME" >}} is listening.
 Follow the steps in [Heroku HTTPS Drain docs](https://devcenter.heroku.com/articles/log-drains#https-drains) for using the Heroku CLI with a command like the following:
 
 ```shell
 heroku drains:add [http|https]://HOSTNAME:PORT/heroku/api/v1/drain -a HEROKU_APP_NAME
 ```
 
-Multiple `loki.source.heroku` components can be specified by giving them
-different labels.
+You can specify multiple `loki.source.heroku` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.source.heroku "LABEL" {
+loki.source.heroku "<LABEL>" {
     http {
-        listen_address = "LISTEN_ADDRESS"
-        listen_port    = LISTEN_PORT
+        listen_address = "<LISTEN_ADDRESS>"
+        listen_port    = "<LISTEN_PORT>"
     }
-    forward_to = RECEIVER_LIST
+    forward_to = <RECEIVER_LIST>
 }
 ```
 
 ## Arguments
 
-`loki.source.heroku` supports the following arguments:
+You can use the following arguments with `loki.source.heroku`:
 
-Name                        | Type                 | Description                                                                        | Default | Required
-----------------------------|----------------------|------------------------------------------------------------------------------------|---------|---------
-`use_incoming_timestamp`    | `bool`               | Whether or not to use the timestamp received from Heroku.                          | `false` | no
-`labels`                    | `map(string)`        | The labels to associate with each received Heroku record.                          | `{}`    | no
-`forward_to`                | `list(LogsReceiver)` | List of receivers to send log entries to.                                          |         | yes
-`relabel_rules`             | `RelabelRules`       | Relabeling rules to apply on log entries.                                          | `{}`    | no
-`graceful_shutdown_timeout` | `duration`           | Timeout for servers graceful shutdown. If configured, should be greater than zero. | "30s"   | no
+| Name                        | Type                 | Description                                                                        | Default | Required |
+| --------------------------- | -------------------- | ---------------------------------------------------------------------------------- | ------- | -------- |
+| `forward_to`                | `list(LogsReceiver)` | List of receivers to send log entries to.                                          |         | yes      |
+| `graceful_shutdown_timeout` | `duration`           | Timeout for servers graceful shutdown. If configured, should be greater than zero. | "30s"   | no       |
+| `labels`                    | `map(string)`        | The labels to associate with each received Heroku record.                          | `{}`    | no       |
+| `relabel_rules`             | `RelabelRules`       | Relabeling rules to apply on log entries.                                          | `{}`    | no       |
+| `use_incoming_timestamp`    | `bool`               | Whether or not to use the timestamp received from Heroku.                          | `false` | no       |
 
-The `relabel_rules` field can make use of the `rules` export value from a
-`loki.relabel` component to apply one or more relabeling rules to log entries
-before they're forwarded to the list of receivers in `forward_to`.
+The `relabel_rules` field can make use of the `rules` export value from a `loki.relabel` component to apply one or more relabeling rules to log entries before they're forwarded to the list of receivers in `forward_to`.
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.heroku`:
+You can use the following blocks with `loki.source.heroku`:
 
-Hierarchy | Name     | Description                                        | Required
-----------|----------|----------------------------------------------------|---------
-`http`    | [http][] | Configures the HTTP server that receives requests. | no
-`grpc`    | [grpc][] | Configures the gRPC server that receives requests. | no
+| Name           | Description                                        | Required |
+| -------------- | -------------------------------------------------- | -------- |
+| [`grpc`][grpc] | Configures the gRPC server that receives requests. | no       |
+| [`http`][http] | Configures the HTTP server that receives requests. | no       |
 
 [http]: #http
 [grpc]: #grpc
 
-### http
+### `grpc`
 
-{{< docs/shared lookup="reference/components/loki-server-http.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/loki-server-grpc.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### grpc
+### `http`
 
-{{< docs/shared lookup="reference/components/loki-server-grpc.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/loki-server-http.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Labels
 
 The `labels` map is applied to every message that the component reads.
 
-The following internal labels all prefixed with `__` are available but will be discarded if not relabeled:
-- `__heroku_drain_host`
-- `__heroku_drain_app`
-- `__heroku_drain_proc`
-- `__heroku_drain_log_id`
+The following internal labels all prefixed with `__` are available but are discarded if not relabeled:
 
-All url query params will be translated to `__heroku_drain_param_<name>`
+* `__heroku_drain_app`
+* `__heroku_drain_host`
+* `__heroku_drain_log_id`
+* `__heroku_drain_proc`
 
-If the `X-Scope-OrgID` header is set it will be translated to `__tenant_id__`
+All URL query parameters are translated to `__heroku_drain_param_<name>`
+
+If the `X-Scope-OrgID` header is set it's translated to `__tenant_id__`
 
 ## Exported fields
 
-`loki.source.heroku` does not export any fields.
+`loki.source.heroku` doesn't export any fields.
 
 ## Component health
 
@@ -98,10 +96,12 @@ configuration.
 ## Debug information
 
 `loki.source.heroku` exposes some debug information per Heroku listener:
+
 * Whether the listener is currently running.
 * The listen address.
 
 ## Debug metrics
+
 * `loki_source_heroku_drain_entries_total` (counter): Number of successful entries received by the Heroku target.
 * `loki_source_heroku_drain_parsing_errors_total` (counter): Number of parsing errors while receiving Heroku messages.
 
@@ -142,6 +142,7 @@ loki.write "local" {
     }
 }
 ```
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.journal.md b/docs/sources/reference/components/loki/loki.source.journal.md
index 23a9b32056..d75c744157 100644
--- a/docs/sources/reference/components/loki/loki.source.journal.md
+++ b/docs/sources/reference/components/loki/loki.source.journal.md
@@ -3,66 +3,61 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.journal/ # /docs/alloy/latest/reference/components/loki.source.journal/
 description: Learn about loki.source.journal
+labels:
+  stage: general-availability
 title: loki.source.journal
 ---
 
-# loki.source.journal
+# `loki.source.journal`
 
 `loki.source.journal` reads from the systemd journal and forwards them to other `loki.*` components.
 
-Multiple `loki.source.journal` components can be specified by giving them different labels.
+You can specify multiple `loki.source.journal` components by giving them different labels.
 
 {{< admonition type="note" >}}
 Make sure that the `grafana-alloy` user is a member of the following groups:
 
-* adm
-* systemd-journal
+* `adm`
+* `systemd-journal`
 {{< /admonition >}}
 
 ## Usage
 
 ```alloy
-loki.source.journal "LABEL" {
-  forward_to    = RECEIVER_LIST
+loki.source.journal "<LABEL>" {
+  forward_to    = <RECEIVER_LIST>
 }
 ```
 
 ## Arguments
-The component starts a new journal reader and fans out
-log entries to the list of receivers passed in `forward_to`.
 
-`loki.source.journal` supports the following arguments:
+The component starts a new journal reader and fans out log entries to the list of receivers passed in `forward_to`.
 
-Name             | Type                 | Description                                                                                            | Default | Required
------------------|----------------------|--------------------------------------------------------------------------------------------------------|---------|---------
-`format_as_json` | `bool`               | Whether to forward the original journal entry as JSON.                                                 | `false` | no
-`max_age`        | `duration`           | The oldest relative time from process start that will be read.                                         | `"7h"`  | no
-`path`           | `string`             | Path to a directory to read entries from.                                                              | `""`    | no
-`matches`        | `string`             | Journal matches to filter. The `+` character is not supported, only logical AND matches will be added. | `""`    | no
-`forward_to`     | `list(LogsReceiver)` | List of receivers to send log entries to.                                                              |         | yes
-`relabel_rules`  | `RelabelRules`       | Relabeling rules to apply on log entries.                                                              | `{}`    | no
-`labels`         | `map(string)`        | The labels to apply to every log coming out of the journal.                                            | `{}`    | no
+You can use the following arguments with `loki.source.journal`:
+
+| Name             | Type                 | Description                                                                                       | Default | Required |
+| ---------------- | -------------------- | ------------------------------------------------------------------------------------------------- | ------- | -------- |
+| `forward_to`     | `list(LogsReceiver)` | List of receivers to send log entries to.                                                         |         | yes      |
+| `format_as_json` | `bool`               | Whether to forward the original journal entry as JSON.                                            | `false` | no       |
+| `labels`         | `map(string)`        | The labels to apply to every log coming out of the journal.                                       | `{}`    | no       |
+| `matches`        | `string`             | Journal matches to filter. The `+` character isn't supported, only logical AND matches are added. | `""`    | no       |
+| `max_age`        | `duration`           | The oldest relative time from process start that will be read.                                    | `"7h"`  | no       |
+| `path`           | `string`             | Path to a directory to read entries from.                                                         | `""`    | no       |
+| `relabel_rules`  | `RelabelRules`       | Relabeling rules to apply on log entries.                                                         | `{}`    | no       |
 
 {{< admonition type="note" >}}
 A `job` label is added with the full name of the component `loki.source.journal.LABEL`.
 {{< /admonition >}}
 
-When the `format_as_json` argument is true, log messages are passed through as
-JSON with all of the original fields from the journal entry. Otherwise, the log
-message is taken from the content of the `MESSAGE` field from the journal
-entry.
+When the `format_as_json` argument is true, log messages are passed through as JSON with all of the original fields from the journal entry.
+Otherwise, the log message is taken from the content of the `MESSAGE` field from the journal entry.
 
-When the `path` argument is empty, `/var/log/journal` and `/run/log/journal`
-will be used for discovering journal entries.
+When the `path` argument is empty, `/var/log/journal` and `/run/log/journal` are used for discovering journal entries.
 
-The `relabel_rules` argument can make use of the `rules` export value from a
-[loki.relabel][] component to apply one or more relabeling rules to log entries
-before they're forwarded to the list of receivers in `forward_to`.
+The `relabel_rules` argument can make use of the `rules` export value from a [`loki.relabel`][loki.relabel] component to apply one or more relabeling rules to log entries before they're forwarded to the list of receivers in `forward_to`.
 
-All messages read from the journal include internal labels following the
-pattern of `__journal_FIELDNAME` and will be dropped before sending to the list
-of receivers specified in `forward_to`. To keep these labels, use the
-`relabel_rules` argument and relabel them to not be prefixed with `__`.
+All messages read from the journal include internal labels following the pattern of `__journal_FIELDNAME` and are dropped before sending to the list of receivers specified in `forward_to`.
+To keep these labels, use the `relabel_rules` argument and relabel them to not be prefixed with `__`.
 
 {{< admonition type="note" >}}
 Many field names from journald start with an `_`, such as `_systemd_unit`.
@@ -71,6 +66,10 @@ The final internal label name would be `__journal__systemd_unit`, with _two_ und
 
 [loki.relabel]: ../loki.relabel/
 
+## Blocks
+
+The `loki.source.journal` component doesn't support any blocks. You can configure this component with arguments.
+
 ## Component health
 
 `loki.source.journal` is only reported as unhealthy if given an invalid configuration.
@@ -104,6 +103,7 @@ loki.write "endpoint" {
   }
 }
 ```
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.kafka.md b/docs/sources/reference/components/loki/loki.source.kafka.md
index c016a99de0..18bdf27835 100644
--- a/docs/sources/reference/components/loki/loki.source.kafka.md
+++ b/docs/sources/reference/components/loki/loki.source.kafka.md
@@ -3,31 +3,29 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.kafka/ # /docs/alloy/latest/reference/components/loki.source.kafka/
 description: Learn about loki.source.kafka
+labels:
+  stage: general-availability
 title: loki.source.kafka
 ---
 
 # loki.source.kafka
 
-`loki.source.kafka` reads messages from Kafka using a consumer group
-and forwards them to other `loki.*` components.
+`loki.source.kafka` reads messages from Kafka using a consumer group and forwards them to other `loki.*` components.
 
-The component starts a new Kafka consumer group for the given arguments
-and fans out incoming entries to the list of receivers in `forward_to`.
+The component starts a new Kafka consumer group for the given arguments and fans out incoming entries to the list of receivers in `forward_to`.
 
-Before using `loki.source.kafka`, Kafka should have at least one producer
-writing events to at least one topic. Follow the steps in the
-[Kafka Quick Start](https://kafka.apache.org/documentation/#quickstart)
-to get started with Kafka.
+Before using `loki.source.kafka`, Kafka should have at least one producer writing events to at least one topic.
+Follow the steps in the [Kafka Quick Start](https://kafka.apache.org/documentation/#quickstart) to get started with Kafka.
 
-Multiple `loki.source.kafka` components can be specified by giving them different labels.
+You can specify multiple `loki.source.kafka` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.source.kafka "LABEL" {
-  brokers    = BROKER_LIST
-  topics     = TOPIC_LIST
-  forward_to = RECEIVER_LIST
+loki.source.kafka "<LABEL>" {
+  brokers    = "<BROKER_LIST>"
+  topics     = "<TOPIC_LIST>"
+  forward_to = <RECEIVER_LIST>
 }
 ```
 
@@ -35,99 +33,98 @@ loki.source.kafka "LABEL" {
 
 `loki.source.kafka` supports the following arguments:
 
- Name                     | Type                 | Description                                              | Default               | Required
---------------------------|----------------------|----------------------------------------------------------|-----------------------|----------
- `brokers`                | `list(string)`       | The list of brokers to connect to Kafka.                 |                       | yes
- `topics`                 | `list(string)`       | The list of Kafka topics to consume.                     |                       | yes
- `group_id`               | `string`             | The Kafka consumer group id.                             | `"loki.source.kafka"` | no
- `assignor`               | `string`             | The consumer group rebalancing strategy to use.          | `"range"`             | no
- `version`                | `string`             | Kafka version to connect to.                             | `"2.2.1"`             | no
- `use_incoming_timestamp` | `bool`               | Whether or not to use the timestamp received from Kafka. | `false`               | no
- `labels`                 | `map(string)`        | The labels to associate with each received Kafka event.  | `{}`                  | no
- `forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.                |                       | yes
- `relabel_rules`          | `RelabelRules`       | Relabeling rules to apply on log entries.                | `{}`                  | no
+| Name                     | Type                 | Description                                              | Default               | Required |
+|--------------------------|----------------------|----------------------------------------------------------|-----------------------|----------|
+| `brokers`                | `list(string)`       | The list of brokers to connect to Kafka.                 |                       | yes      |
+| `forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.                |                       | yes      |
+| `topics`                 | `list(string)`       | The list of Kafka topics to consume.                     |                       | yes      |
+| `assignor`               | `string`             | The consumer group rebalancing strategy to use.          | `"range"`             | no       |
+| `group_id`               | `string`             | The Kafka consumer group id.                             | `"loki.source.kafka"` | no       |
+| `labels`                 | `map(string)`        | The labels to associate with each received Kafka event.  | `{}`                  | no       |
+| `relabel_rules`          | `RelabelRules`       | Relabeling rules to apply on log entries.                | `{}`                  | no       |
+| `use_incoming_timestamp` | `bool`               | Whether or not to use the timestamp received from Kafka. | `false`               | no       |
+| `version`                | `string`             | Kafka version to connect to.                             | `"2.2.1"`             | no       |
 
 `assignor` values can be either `"range"`, `"roundrobin"`, or `"sticky"`.
 
-If a topic starts with a '^', it is treated as a regular expression and may match multiple topics.
+If a topic starts with a '^', it's treated as a regular expression and may match multiple topics.
 
 Labels from the `labels` argument are applied to every message that the component reads.
 
-The `relabel_rules` field can make use of the `rules` export value from a
-[loki.relabel][] component to apply one or more relabeling rules to log entries
-before they're forwarded to the list of receivers in `forward_to`.
+The `relabel_rules` field can make use of the `rules` export value from a [`loki.relabel`][loki.relabel] component to apply one or more relabeling rules to log entries before they're forwarded to the list of receivers in `forward_to`.
 
 In addition to custom labels, the following internal labels prefixed with `__` are available:
 
+- `__meta_kafka_group_id`
+- `__meta_kafka_member_id`
 - `__meta_kafka_message_key`
 - `__meta_kafka_message_offset`
-- `__meta_kafka_topic`
 - `__meta_kafka_partition`
-- `__meta_kafka_member_id`
-- `__meta_kafka_group_id`
+- `__meta_kafka_topic`
 
-All labels starting with `__` are removed prior to forwarding log entries. To
-keep these labels, relabel them using a [loki.relabel][] component and pass its
-`rules` export to the `relabel_rules` argument.
+All labels starting with `__` are removed prior to forwarding log entries.
+To keep these labels, relabel them using a [`loki.relabel`][loki.relabel] component and pass its `rules` export to the `relabel_rules` argument.
 
 [loki.relabel]: ../loki.relabel/
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.kafka`:
+You can use the following blocks with `loki.source.kafka`:
 
- Hierarchy                                   | Name             | Description                                               | Required
----------------------------------------------|------------------|-----------------------------------------------------------|----------
- authentication                              | [authentication] | Optional authentication configuration with Kafka brokers. | no
- authentication > tls_config                 | [tls_config]     | Optional authentication configuration with Kafka brokers. | no
- authentication > sasl_config                | [sasl_config]    | Optional authentication configuration with Kafka brokers. | no
- authentication > sasl_config > tls_config   | [tls_config]     | Optional authentication configuration with Kafka brokers. | no
- authentication > sasl_config > oauth_config | [oauth_config]   | Optional authentication configuration with Kafka brokers. | no
+| Name                                                              | Description                                               | Required |
+| ----------------------------------------------------------------- | --------------------------------------------------------- | -------- |
+| [`authentication`][authentication]                                | Optional authentication configuration with Kafka brokers. | no       |
+| `authentication` >  [`sasl_config`][sasl_config]                  | Optional authentication configuration with Kafka brokers. | no       |
+| `authentication` > `sasl_config` > [`oauth_config`][oauth_config] | Optional authentication configuration with Kafka brokers. | no       |
+| `authentication` > `sasl_config` > [`tls_config`][tls_config]     | Optional authentication configuration with Kafka brokers. | no       |
+| `authentication` >  [`tls_config`][tls_config]                    | Optional authentication configuration with Kafka brokers. | no       |
 
-[authentication]: #authentication-block
-[tls_config]: #tls_config-block
-[sasl_config]: #sasl_config-block
-[oauth_config]: #oauth_config-block
+The > symbol indicates deeper levels of nesting.
+For example, `authentication` > `sasl_config` refers to a `sasl_config` block defined inside a `authentication` block.
 
-### authentication block
+[authentication]: #authentication
+[oauth_config]: #oauth_config
+[sasl_config]: #sasl_config
+[tls_config]: #tls_config
+
+### `authentication`
 
 The `authentication` block defines the authentication method when communicating with the Kafka event brokers.
 
- Name   | Type     | Description             | Default  | Required
---------|----------|-------------------------|----------|----------
- `type` | `string` | Type of authentication. | `"none"` | no
+| Name   | Type     | Description             | Default  | Required |
+| ------ | -------- | ----------------------- | -------- | -------- |
+| `type` | `string` | Type of authentication. | `"none"` | no       |
 
 `type` supports the values `"none"`, `"ssl"`, and `"sasl"`. If `"ssl"` is used,
 you must set the `tls_config` block. If `"sasl"` is used, you must set the `sasl_config` block.
 
-### tls_config block
+### `sasl_config`
 
-{{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+The `sasl_config` block defines the listen address and port where the listener expects Kafka messages to be sent to.
 
-### sasl_config block
+| Name        | Type     | Description                                                                   | Default    | Required |
+| ----------- | -------- | ----------------------------------------------------------------------------- | ---------- | -------- |
+| `mechanism` | `string` | Specifies the SASL mechanism the client uses to authenticate with the broker. | `"PLAIN""` | no       |
+| `password`  | `secret` | The password to use for SASL authentication.                                  | `""`       | no       |
+| `use_tls`   | `bool`   | If true, SASL authentication is executed over TLS.                            | `false`    | no       |
+| `user`      | `string` | The user name to use for SASL authentication.                                 | `""`       | no       |
 
-The `sasl_config` block defines the listen address and port where the listener
-expects Kafka messages to be sent to.
+### `oauth_config`
 
- Name        | Type     | Description                                                                   | Default    | Required
--------------|----------|--------------------------------------------------------------------|----------|-----------------------
- `mechanism` | `string` | Specifies the SASL mechanism the client uses to authenticate with the broker. | `"PLAIN""` | no
- `user`      | `string` | The user name to use for SASL authentication.                                 | `""`       | no
- `password`  | `secret` | The password to use for SASL authentication.                                  | `""`       | no
- `use_tls`   | `bool`   | If true, SASL authentication is executed over TLS.                            | `false`    | no
+The `oauth_config` is required when the SASL mechanism is set to `OAUTHBEARER`.
 
-### oauth_config block
+| Name             | Type           | Description                                                                | Default | Required |
+| ---------------- | -------------- | -------------------------------------------------------------------------- | ------- | -------- |
+| `scopes`         | `list(string)` | The scopes to set in the access token                                      | `[]`    | yes      |
+| `token_provider` | `string`       | The OAuth 2.0 provider to be used. The only supported provider is `azure`. | `""`    | yes      |
 
-The `oauth_config` is required when the SASL mechanism is set to `OAUTHBEARER`.
+### `tls_config`
 
- Name             | Type           | Description                                                            | Default | Required
-------------------|----------------|------------------------------------------------------------------------|---------|----------
- `token_provider` | `string`       | The OAuth provider to be used. The only supported provider is `azure`. | `""`    | yes
- `scopes`         | `list(string)` | The scopes to set in the access token                                  | `[]`    | yes
+{{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Exported fields
 
-`loki.source.kafka` does not export any fields.
+`loki.source.kafka` doesn't export any fields.
 
 ## Component health
 
@@ -135,12 +132,11 @@ The `oauth_config` is required when the SASL mechanism is set to `OAUTHBEARER`.
 
 ## Debug information
 
-`loki.source.kafka` does not expose additional debug info.
+`loki.source.kafka` doesn't expose additional debug info.
 
 ## Example
 
-This example consumes Kafka events from the specified brokers and topics
-then forwards them to a `loki.write` component using the Kafka timestamp.
+This example consumes Kafka events from the specified brokers and topics then forwards them to a `loki.write` component using the Kafka timestamp.
 
 ```alloy
 loki.source.kafka "local" {
diff --git a/docs/sources/reference/components/loki/loki.source.kubernetes.md b/docs/sources/reference/components/loki/loki.source.kubernetes.md
index 4cb86cc620..446afa225c 100644
--- a/docs/sources/reference/components/loki/loki.source.kubernetes.md
+++ b/docs/sources/reference/components/loki/loki.source.kubernetes.md
@@ -3,10 +3,12 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.kubernetes/ # /docs/alloy/latest/reference/components/loki.source.kubernetes/
 description: Learn about loki.source.kubernetes
+labels:
+  stage: general-availability
 title: loki.source.kubernetes
 ---
 
-# loki.source.kubernetes
+# `loki.source.kubernetes`
 
 `loki.source.kubernetes` tails logs from Kubernetes containers using the Kubernetes API.
 
@@ -30,9 +32,9 @@ You can specify multiple `loki.source.kubernetes` components by giving them diff
 ## Usage
 
 ```alloy
-loki.source.kubernetes "LABEL" {
-  targets    = TARGET_LIST
-  forward_to = RECEIVER_LIST
+loki.source.kubernetes "<LABEL>" {
+  targets    = <TARGET_LIST>
+  forward_to = <RECEIVER_LIST>
 }
 ```
 
@@ -40,100 +42,100 @@ loki.source.kubernetes "LABEL" {
 
 The component starts a new reader for each of the given `targets` and fans out log entries to the list of receivers passed in `forward_to`.
 
-`loki.source.kubernetes` supports the following arguments:
+You can use the following arguments with `loki.source.kubernetes`:
 
-Name         | Type                 | Description                               | Default | Required
--------------|----------------------|-------------------------------------------|---------|---------
-`targets`    | `list(map(string))`  | List of files to read from.               |         | yes
-`forward_to` | `list(LogsReceiver)` | List of receivers to send log entries to. |         | yes
+| Name         | Type                 | Description                               | Default | Required |
+| ------------ | -------------------- | ----------------------------------------- | ------- | -------- |
+| `forward_to` | `list(LogsReceiver)` | List of receivers to send log entries to. |         | yes      |
+| `targets`    | `list(map(string))`  | List of files to read from.               |         | yes      |
 
 Each target in `targets` must have the following labels:
 
-* `__meta_kubernetes_namespace` or `__pod_namespace__` to specify the namespace of the pod to tail.
-* `__meta_kubernetes_pod_name` or `__pod_name__` to specify the name of the pod to tail.
-* `__meta_kubernetes_pod_container_name` or `__pod_container_name__` to specify the container within the pod to tail.
-* `__meta_kubernetes_pod_uid` or `__pod_uid__` to specify the UID of the pod to tail.
+* `__meta_kubernetes_namespace` or `__pod_namespace__` to specify the namespace of the Pod to tail.
+* `__meta_kubernetes_pod_container_name` or `__pod_container_name__` to specify the container within the Pod to tail.
+* `__meta_kubernetes_pod_name` or `__pod_name__` to specify the name of the Pod to tail.
+* `__meta_kubernetes_pod_uid` or `__pod_uid__` to specify the UID of the Pod to tail.
 
 By default, all of these labels are present when the output `discovery.kubernetes` is used.
 
 A log tailer is started for each unique target in `targets`.
-Log tailers will reconnect with exponential backoff to Kubernetes if the log stream returns before the container has permanently terminated.
+Log tailers reconnect with exponential backoff to Kubernetes if the log stream returns before the container has permanently terminated.
 
 ## Blocks
 
-The following blocks are supported inside the definition of `loki.source.kubernetes`:
+You can use the following blocks with `loki.source.kubernetes`:
 
-Hierarchy                    | Block             | Description                                                                                 | Required
------------------------------|-------------------|---------------------------------------------------------------------------------------------|---------
-client                       | [client][]        | Configures Kubernetes client used to tail logs.                                             | no
-client > basic_auth          | [basic_auth][]    | Configure `basic_auth` for authenticating to the endpoint.                                  | no
-client > authorization       | [authorization][] | Configure generic authorization to the endpoint.                                            | no
-client > oauth2              | [oauth2][]        | Configure OAuth2 for authenticating to the endpoint.                                        | no
-client > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the endpoint.                                      | no
-client > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the endpoint.                                      | no
-clustering                   | [clustering][]    | Configure the component for when {{< param "PRODUCT_NAME" >}} is running in clustered mode. | no
+| Block                                            | Description                                                                                 | Required |
+| ------------------------------------------------ | ------------------------------------------------------------------------------------------- | -------- |
+| [`client`][client]                               | Configures Kubernetes client used to tail logs.                                             | no       |
+| `client` > [`authorization`][authorization]      | Configure generic authorization to the endpoint.                                            | no       |
+| `client` > [`basic_auth`][basic_auth]            | Configure `basic_auth` for authenticating to the endpoint.                                  | no       |
+| `client` > [`oauth2`][oauth2]                    | Configure OAuth 2.0 for authenticating to the endpoint.                                     | no       |
+| `client` > `oauth2` > [`tls_config`][tls_config] | Configure TLS settings for connecting to the endpoint.                                      | no       |
+| `client` > [`tls_config`][tls_config]            | Configure TLS settings for connecting to the endpoint.                                      | no       |
+| [`clustering`][clustering]                       | Configure the component for when {{< param "PRODUCT_NAME" >}} is running in clustered mode. | no       |
 
-The `>` symbol indicates deeper levels of nesting.
-For example, `client > basic_auth` refers to a `basic_auth` block defined inside a `client` block.
+The > symbol indicates deeper levels of nesting.
+For example, `client` > `basic_auth` refers to a `basic_auth` block defined inside a `client` block.
 
-[client]: #client-block
-[basic_auth]: #basic_auth-block
-[authorization]: #authorization-block
-[oauth2]: #oauth2-block
-[tls_config]: #tls_config-block
-[clustering]: #clustering-block
+[client]: #client
+[authorization]: #authorization
+[basic_auth]: #basic_auth
+[clustering]: #clustering
+[oauth2]: #oauth2
+[tls_config]: #tls_config
 
-### client block
+### `client`
 
 The `client` block configures the Kubernetes client used to tail logs from containers.
-If the `client` block isn't provided, the default in-cluster configuration with the service account of the running {{< param "PRODUCT_NAME" >}} pod is used.
+If the `client` block isn't provided, the default in-cluster configuration with the service account of the running {{< param "PRODUCT_NAME" >}} Pod is used.
 
 The following arguments are supported:
 
-Name                     | Type                | Description                                                                                      | Default | Required
--------------------------|---------------------|--------------------------------------------------------------------------------------------------|---------|---------
-`api_server`             | `string`            | URL of the Kubernetes API server.                                                                |         | no
-`kubeconfig_file`        | `string`            | Path of the `kubeconfig` file to use for connecting to Kubernetes.                               |         | no
-`bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |         | no
-`bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |         | no
-`enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`  | no
-`follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`  | no
-`proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no
-`no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no
-`proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no
-`proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no
+| Name                     | Type                | Description                                                                                      | Default | Required |
+| ------------------------ | ------------------- | ------------------------------------------------------------------------------------------------ | ------- | -------- |
+| `api_server`             | `string`            | URL of the Kubernetes API server.                                                                |         | no       |
+| `bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |         | no       |
+| `bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |         | no       |
+| `enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`  | no       |
+| `follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`  | no       |
+| `kubeconfig_file`        | `string`            | Path of the `kubeconfig` file to use for connecting to Kubernetes.                               |         | no       |
+| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no       |
+| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no       |
+| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no       |
+| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no       |
 
  At most, one of the following can be provided:
 
- - [`bearer_token` argument][client].
- - [`bearer_token_file` argument][client].
- - [`basic_auth` block][basic_auth].
- - [`authorization` block][authorization].
- - [`oauth2` block][oauth2].
+* [`authorization`][authorization] block
+* [`basic_auth`][basic_auth] block
+* [`bearer_token_file`][client] argument
+* [`bearer_token`][client] argument
+* [`oauth2`][oauth2] block
 
 {{< docs/shared lookup="reference/components/http-client-proxy-config-description.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### basic_auth block
+### `authorization`
 
-{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### authorization block
+### `basic_auth`
 
-{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### oauth2 block
+### `oauth2`
 
 {{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### tls_config block
+### `tls_config`
 
 {{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### clustering block
+### `clustering`
 
-Name      | Type   | Description                                         | Default | Required
-----------|--------|-----------------------------------------------------|---------|---------
-`enabled` | `bool` | Distribute log collection with other cluster nodes. |         | yes
+| Name      | Type   | Description                                         | Default | Required |
+| --------- | ------ | --------------------------------------------------- | ------- | -------- |
+| `enabled` | `bool` | Distribute log collection with other cluster nodes. |         | yes      |
 
 When {{< param "PRODUCT_NAME" >}} is [using clustering][], and `enabled` is set to true, then this `loki.source.kubernetes` component instance opts-in to participating in the cluster to distribute the load of log collection between all cluster nodes.
 
@@ -141,18 +143,18 @@ If {{< param "PRODUCT_NAME" >}} is _not_ running in clustered mode, then the blo
 
 Clustering looks only at the following labels for determining the shard key:
 
-* `__pod_namespace__`
-* `__pod_name__`
-* `__pod_container_name__`
-* `__pod_uid__`
 * `__meta_kubernetes_namespace`
-* `__meta_kubernetes_pod_name`
 * `__meta_kubernetes_pod_container_name`
+* `__meta_kubernetes_pod_name`
 * `__meta_kubernetes_pod_uid`
+* `__pod_container_name__`
+* `__pod_name__`
+* `__pod_namespace__`
+* `__pod_uid__`
 * `container`
-* `pod`
 * `job`
 * `namespace`
+* `pod`
 
 [using clustering]: ../../../../get-started/clustering/
 
@@ -175,11 +177,11 @@ Clustering looks only at the following labels for determining the shard key:
 
 ## Debug metrics
 
-`loki.source.kubernetes` does not expose any component-specific debug metrics.
+`loki.source.kubernetes` doesn't expose any component-specific debug metrics.
 
 ## Example
 
-This example collects logs from all Kubernetes Pods and forwards them to a `loki.write` component so they are written to Loki.
+This example collects logs from all Kubernetes Pods and forwards them to a `loki.write` component so they're written to Loki.
 
 ```alloy
 discovery.kubernetes "pods" {
@@ -193,7 +195,7 @@ loki.source.kubernetes "pods" {
 
 loki.write "local" {
   endpoint {
-    url = sys.env("LOKI_URL")
+    url = sys.env("<LOKI_URL>")
   }
 }
 ```
diff --git a/docs/sources/reference/components/loki/loki.source.kubernetes_events.md b/docs/sources/reference/components/loki/loki.source.kubernetes_events.md
index c4f8de4e3f..3172eba939 100644
--- a/docs/sources/reference/components/loki/loki.source.kubernetes_events.md
+++ b/docs/sources/reference/components/loki/loki.source.kubernetes_events.md
@@ -3,43 +3,42 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.kubernetes_events/ # /docs/alloy/latest/reference/components/loki.source.kubernetes_events/
 description: Learn about loki.source.kubernetes_events
+labels:
+  stage: general-availability
 title: loki.source.kubernetes_events
 ---
 
-# loki.source.kubernetes_events
+# `loki.source.kubernetes_events`
 
-`loki.source.kubernetes_events` tails events from the Kubernetes API and
-converts them into log lines to forward to other `loki` components.
+`loki.source.kubernetes_events` tails events from the Kubernetes API and converts them into log lines to forward to other `loki` components.
 
-Multiple `loki.source.kubernetes_events` components can be specified by giving them different labels.
+You can specify multiple `loki.source.kubernetes_events` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.source.kubernetes_events "LABEL" {
-  forward_to = RECEIVER_LIST
+loki.source.kubernetes_events "<LABEL>" {
+  forward_to = <RECEIVER_LIST>
 }
 ```
 
 ## Arguments
 
-The component starts a new reader for each of the given `targets` and fans out
-log entries to the list of receivers passed in `forward_to`.
+The component starts a new reader for each of the given `targets` and fans out log entries to the list of receivers passed in `forward_to`.
 
-`loki.source.kubernetes_events` supports the following arguments:
+You can use the following arguments with `loki.source.kubernetes_events`:
 
-Name         | Type                 | Description                                      | Default                           | Required
--------------|----------------------|--------------------------------------------------|-----------------------------------|---------
-`job_name`   | `string`             | Value to use for `job` label for generated logs. | `"loki.source.kubernetes_events"` | no
-`log_format` | `string`             | Format of the log.                               | `"logfmt"`                        | no
-`namespaces` | `list(string)`       | Namespaces to watch for Events in.               | `[]`                              | no
-`forward_to` | `list(LogsReceiver)` | List of receivers to send log entries to.        |                                   | yes
+| Name         | Type                 | Description                                      | Default                           | Required |
+| ------------ | -------------------- | ------------------------------------------------ | --------------------------------- | -------- |
+| `forward_to` | `list(LogsReceiver)` | List of receivers to send log entries to.        |                                   | yes      |
+| `job_name`   | `string`             | Value to use for `job` label for generated logs. | `"loki.source.kubernetes_events"` | no       |
+| `log_format` | `string`             | Format of the log.                               | `"logfmt"`                        | no       |
+| `namespaces` | `list(string)`       | Namespaces to watch for Events in.               | `[]`                              | no       |
 
-By default, `loki.source.kubernetes_events` will watch for events in all
-namespaces. A list of explicit namespaces to watch can be provided in the
-`namespaces` argument.
+By default, `loki.source.kubernetes_events` watches for events in all namespaces.
+A list of explicit namespaces to watch can be provided in the `namespaces` argument.
 
-By default, the generated log lines will be in the `logfmt` format.
+By default, the generated log lines are in the `logfmt` format.
 Use the `log_format` argument to change it to `json`.
 These formats are also names of LogQL parsers, which can be used for processing the logs.
 
@@ -54,88 +53,84 @@ Log lines generated by `loki.source.kubernetes_events` have the following labels
 * `job`: Value specified by the `job_name` argument.
 * `instance`: Value matching the component ID.
 
-If `job_name` argument is the empty string, the component will fail to load. To
-remove the job label, forward the output of `loki.source.kubernetes_events` to
-[a `loki.relabel` component][loki.relabel].
+If `job_name` argument is the empty string, the component will fail to load.
+To remove the job label, forward the output of `loki.source.kubernetes_events` to [a `loki.relabel` component][loki.relabel].
 
-For compatibility with the `eventhandler` integration from static mode,
-`job_name` can be set to `"integrations/kubernetes/eventhandler"`.
+For compatibility with the `eventhandler` integration from static mode, `job_name` can be set to `"integrations/kubernetes/eventhandler"`.
 
 [loki.relabel]: ../loki.relabel/
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`loki.source.kubernetes_events`:
+You can use the following blocks with `loki.source.kubernetes_events`:
 
-Hierarchy                    | Block             | Description                                              | Required
------------------------------|-------------------|----------------------------------------------------------|---------
-client                       | [client][]        | Configures Kubernetes client used to tail logs.          | no
-client > basic_auth          | [basic_auth][]    | Configure basic_auth for authenticating to the endpoint. | no
-client > authorization       | [authorization][] | Configure generic authorization to the endpoint.         | no
-client > oauth2              | [oauth2][]        | Configure OAuth2 for authenticating to the endpoint.     | no
-client > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
-client > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
+| Block                                            | Description                                                | Required |
+| ------------------------------------------------ | ---------------------------------------------------------- | -------- |
+| [`client`][client]                               | Configures Kubernetes client used to tail logs.            | no       |
+| `client` > [`authorization`][authorization]      | Configure generic authorization to the endpoint.           | no       |
+| `client` > [`basic_auth`][basic_auth]            | Configure `basic_auth` for authenticating to the endpoint. | no       |
+| `client` > [`oauth2`][oauth2]                    | Configure OAuth 2.0 for authenticating to the endpoint.    | no       |
+| `client` > `oauth2` > [`tls_config`][tls_config] | Configure TLS settings for connecting to the endpoint.     | no       |
+| `client` > [`tls_config`][]                      | Configure TLS settings for connecting to the endpoint.     | no       |
 
-The `>` symbol indicates deeper levels of nesting. For example, `client >
-basic_auth` refers to a `basic_auth` block defined
-inside a `client` block.
+The > symbol indicates deeper levels of nesting.
+For example, `client` > `basic_auth` refers to a `basic_auth` block defined inside a `client` block.
 
-[client]: #client-block
-[basic_auth]: #basic_auth-block
-[authorization]: #authorization-block
-[oauth2]: #oauth2-block
-[tls_config]: #tls_config-block
+[authorization]: #authorization
+[basic_auth]: #basic_auth
+[client]: #client
+[oauth2]: #oauth2
+[tls_config]: #tls_config
 
-### client block
+### `client`
 
-The `client` block configures the Kubernetes client used to tail logs from
-containers. If the `client` block isn't provided, the default in-cluster
-configuration with the service account of the running {{< param "PRODUCT_NAME" >}} pod is used.
+The `client` block configures the Kubernetes client used to tail logs from containers.
+If the `client` block isn't provided, the default in-cluster configuration with the service account of the running {{< param "PRODUCT_NAME" >}} Pod is used.
 
 The following arguments are supported:
 
-Name                     | Type                | Description                                                                                      | Default | Required
--------------------------|---------------------|--------------------------------------------------------------------------------------------------|---------|---------
-`api_server`             | `string`            | URL of the Kubernetes API server.                                                                |         | no
-`kubeconfig_file`        | `string`            | Path of the `kubeconfig` file to use for connecting to Kubernetes.                               |         | no
-`bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |         | no
-`bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |         | no
-`enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`  | no
-`follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`  | no
-`proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no
-`no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no
-`proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no
-`proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no
+| Name                     | Type                | Description                                                                                      | Default | Required |
+| ------------------------ | ------------------- | ------------------------------------------------------------------------------------------------ | ------- | -------- |
+| `api_server`             | `string`            | URL of the Kubernetes API server.                                                                |         | no       |
+| `bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |         | no       |
+| `bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |         | no       |
+| `enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`  | no       |
+| `follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`  | no       |
+| `kubeconfig_file`        | `string`            | Path of the `kubeconfig` file to use for connecting to Kubernetes.                               |         | no       |
+| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no       |
+| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no       |
+| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no       |
+| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no       |
 
  At most, one of the following can be provided:
- - [`bearer_token` argument][client].
- - [`bearer_token_file` argument][client].
- - [`basic_auth` block][basic_auth].
- - [`authorization` block][authorization].
- - [`oauth2` block][oauth2].
+
+* [`authorization`][authorization] block
+* [`basic_auth`][basic_auth] block
+* [`bearer_token_file`][client] argument
+* [`bearer_token`][client] argument
+* [`oauth2`][oauth2] block
 
 {{< docs/shared lookup="reference/components/http-client-proxy-config-description.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### basic_auth block
+### `authorization`
 
-{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### authorization block
+### `basic_auth`
 
-{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### oauth2 block
+### `oauth2`
 
 {{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### tls_config block
+### `tls_config`
 
 {{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Exported fields
 
-`loki.source.kubernetes_events` does not export any fields.
+`loki.source.kubernetes_events` doesn't export any fields.
 
 ## Component health
 
@@ -147,26 +142,20 @@ Name                     | Type                | Description
 
 ## Debug metrics
 
-`loki.source.kubernetes_events` does not expose any component-specific debug metrics.
+`loki.source.kubernetes_events` doesn't expose any component-specific debug metrics.
 
 ## Component behavior
 
-The component uses its data path, a directory named after the domain's
-fully qualified name, to store its _positions file_. The positions file is used
-to store read offsets, so that if a component or {{< param "PRODUCT_NAME" >}} restarts,
-`loki.source.kubernetes_events` can pick up tailing from the same spot.
+The component uses its data path, a directory named after the domain's fully qualified name, to store its _positions file_.
+The positions file is used to store read offsets, so that if a component or {{< param "PRODUCT_NAME" >}} restarts, `loki.source.kubernetes_events` can pick up tailing from the same spot.
 
 The data path is inside the directory configured by the `--storage.path` [command line argument][cmd-args].
 
-In Grafana Agent Static's [eventhandler integration][eventhandler-integration], a `cache_path` argument is used to configure a positions file.
-In {{< param "PRODUCT_NAME" >}}, this argument is no longer necessary.
-
 [cmd-args]: ../../../cli/run/
-[eventhandler-integration]: https://grafana.com/docs/agent/latest/static/configuration/integrations/integrations-next/eventhandler-config/
 
 ## Example
 
-This example collects watches events in the `kube-system` namespace and forwards them to a `loki.write` component so they are written to Loki.
+This example collects watches events in the `kube-system` namespace and forwards them to a `loki.write` component so they're written to Loki.
 
 ```alloy
 loki.source.kubernetes_events "example" {
@@ -182,6 +171,7 @@ loki.write "local" {
   }
 }
 ```
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.podlogs.md b/docs/sources/reference/components/loki/loki.source.podlogs.md
index ae4703f675..6acfcd4177 100644
--- a/docs/sources/reference/components/loki/loki.source.podlogs.md
+++ b/docs/sources/reference/components/loki/loki.source.podlogs.md
@@ -3,10 +3,12 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.podlogs/ # /docs/alloy/latest/reference/components/loki.source.podlogs/
 description: Learn about loki.source.podlogs
+labels:
+  stage: general-availability
 title: loki.source.podlogs
 ---
 
-# loki.source.podlogs
+# `loki.source.podlogs`
 
 `loki.source.podlogs` discovers `PodLogs` resources on Kubernetes.
 The `PodLogs` resources provide rules for which Kubernetes Pods to discover on your cluster.
@@ -19,58 +21,56 @@ The `PodLogs` resources provide rules for which Kubernetes Pods to discover on y
 Because `loki.source.podlogs` uses the Kubernetes API to tail logs, it uses more network traffic and CPU consumption of Kubelets than `loki.source.file`.
 {{< /admonition >}}
 
-Multiple `loki.source.podlogs` components can be specified by giving them
-different labels.
+You can specify multiple `loki.source.podlogs` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.source.podlogs "LABEL" {
-  forward_to = RECEIVER_LIST
+loki.source.podlogs "<LABEL>" {
+  forward_to = <RECEIVER_LIST>
 }
 ```
 
 ## Arguments
 
-The component starts a new reader for each of the given `targets` and fans out
-log entries to the list of receivers passed in `forward_to`.
+The component starts a new reader for each of the given `targets` and fans out log entries to the list of receivers passed in `forward_to`.
 
 `loki.source.podlogs` supports the following arguments:
 
-Name         | Type                 | Description                               | Default | Required
--------------|----------------------|-------------------------------------------|---------|---------
-`forward_to` | `list(LogsReceiver)` | List of receivers to send log entries to. |         | yes
+| Name         | Type                 | Description                               | Default | Required |
+| ------------ | -------------------- | ----------------------------------------- | ------- | -------- |
+| `forward_to` | `list(LogsReceiver)` | List of receivers to send log entries to. |         | yes      |
 
-`loki.source.podlogs` searches for `PodLogs` resources on Kubernetes. Each
-`PodLogs` resource describes a set of pods to tail logs from.
+`loki.source.podlogs` searches for `PodLogs` resources on Kubernetes.
+Each `PodLogs` resource describes a set of pods to tail logs from.
 
-## PodLogs custom resource
+## `PodLogs` custom resource
 
 The `PodLogs` resource describes a set of Pods to collect logs from.
 
 {{< admonition type="note" >}}
-`loki.source.podlogs` looks for `PodLogs` of `monitoring.grafana.com/v1alpha2`, and is not compatible with `PodLogs` from the Agent Operator, which are version `v1alpha1`.
+`loki.source.podlogs` looks for `PodLogs` of `monitoring.grafana.com/v1alpha2`, and isn't compatible with `PodLogs` from the Agent Operator, which are version `v1alpha1`.
 {{< /admonition >}}
 
-Field        | Type            | Description
--------------|-----------------|----------------------------------------------
-`apiVersion` | string          | `monitoring.grafana.com/v1alpha2`
-`kind`       | string          | `PodLogs`
-`metadata`   | [ObjectMeta][]  | Metadata for the PodLogs.
-`spec`       | [PodLogsSpec][] | Definition of what Pods to collect logs from.
+| Field        | Type            | Description                                   |
+| ------------ | --------------- | --------------------------------------------- |
+| `apiVersion` | string          | `monitoring.grafana.com/v1alpha2`             |
+| `kind`       | string          | `PodLogs`                                     |
+| `metadata`   | [ObjectMeta][]  | Metadata for the PodLogs.                     |
+| `spec`       | [PodLogsSpec][] | Definition of what Pods to collect logs from. |
 
 [ObjectMeta]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#objectmeta-v1-meta
 [PodLogsSpec]: #podlogsspec
 
-### PodLogsSpec
+### `PodLogsSpec`
 
 `PodLogsSpec` describes a set of Pods to collect logs from.
 
-Field               | Type              | Description
---------------------|-------------------|-------------------------------------------------------------
-`selector`          | [LabelSelector][] | Label selector of Pods to collect logs from.
-`namespaceSelector` | [LabelSelector][] | Label selector of Namespaces that Pods can be discovered in.
-`relabelings`       | [RelabelConfig][] | Relabel rules to apply to discovered Pods.
+| Field               | Type              | Description                                                  |
+| ------------------- | ----------------- | ------------------------------------------------------------ |
+| `selector`          | [LabelSelector][] | Label selector of Pods to collect logs from.                 |
+| `namespaceSelector` | [LabelSelector][] | Label selector of Namespaces that Pods can be discovered in. |
+| `relabelings`       | [RelabelConfig][] | Relabel rules to apply to discovered Pods.                   |
 
 If `selector` is left as the default value, all Pods are discovered.
 If `namespaceSelector` is left as the default value, all Namespaces are used for Pod discovery.
@@ -79,29 +79,28 @@ The `relabelings` field can be used to modify labels from discovered Pods.
 The following meta labels are available for relabeling:
 
 * `__meta_kubernetes_namespace`: The namespace of the Pod.
-* `__meta_kubernetes_pod_name`: The name of the Pod.
-* `__meta_kubernetes_pod_ip`: The pod IP of the Pod.
-* `__meta_kubernetes_pod_label_<labelname>`: Each label from the Pod.
-* `__meta_kubernetes_pod_labelpresent_<labelname>`: `true` for each label from the Pod.
 * `__meta_kubernetes_pod_annotation_<annotationname>`: Each annotation from the Pod.
 * `__meta_kubernetes_pod_annotationpresent_<annotationname>`: `true` for each annotation from the Pod.
+* `__meta_kubernetes_pod_container_image`: The image the container is using.
 * `__meta_kubernetes_pod_container_init`: `true` if the container is an `InitContainer`.
 * `__meta_kubernetes_pod_container_name`: Name of the container.
-* `__meta_kubernetes_pod_container_image`: The image the container is using.
-* `__meta_kubernetes_pod_ready`: Set to `true` or `false` for the Pod's ready state.
-* `__meta_kubernetes_pod_phase`: Set to `Pending`, `Running`, `Succeeded`, `Failed` or `Unknown` in the lifecycle.
-* `__meta_kubernetes_pod_node_name`: The name of the node the pod is scheduled onto.
-* `__meta_kubernetes_pod_host_ip`: The current host IP of the pod object.
-* `__meta_kubernetes_pod_uid`: The UID of the Pod.
 * `__meta_kubernetes_pod_controller_kind`: Object kind of the Pod's controller.
 * `__meta_kubernetes_pod_controller_name`: Name of the Pod's controller.
+* `__meta_kubernetes_pod_host_ip`: The current host IP of the Pod object.
+* `__meta_kubernetes_pod_ip`: The Pod IP of the Pod.
+* `__meta_kubernetes_pod_label_<labelname>`: Each label from the Pod.
+* `__meta_kubernetes_pod_labelpresent_<labelname>`: `true` for each label from the Pod.
+* `__meta_kubernetes_pod_name`: The name of the Pod.
+* `__meta_kubernetes_pod_node_name`: The name of the node the Pod is scheduled onto.
+* `__meta_kubernetes_pod_phase`: Set to `Pending`, `Running`, `Succeeded`, `Failed` or `Unknown` in the lifecycle.
+* `__meta_kubernetes_pod_ready`: Set to `true` or `false` for the Pod's ready state.
+* `__meta_kubernetes_pod_uid`: The UID of the Pod.
 
-In addition to the meta labels, the following labels are exposed to tell
-`loki.source.podlogs` which container to tail:
+In addition to the meta labels, the following labels are exposed to tell `loki.source.podlogs` which container to tail:
 
-* `__pod_namespace__`: The namespace of the Pod.
-* `__pod_name__`: The name of the Pod.
 * `__pod_container_name__`: The container name within the Pod.
+* `__pod_name__`: The name of the Pod.
+* `__pod_namespace__`: The namespace of the Pod.
 * `__pod_uid__`: The UID of the Pod.
 
 [LabelSelector]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#labelselector-v1-meta
@@ -109,104 +108,113 @@ In addition to the meta labels, the following labels are exposed to tell
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`loki.source.podlogs`:
-
-Hierarchy                             | Block                | Description                                                                                      | Required
---------------------------------------|----------------------|--------------------------------------------------------------------------------------------------|---------
-client                                | [client][]           | Configures Kubernetes client used to tail logs.                                                  | no
-client > basic_auth                   | [basic_auth][]       | Configure basic_auth for authenticating to the endpoint.                                         | no
-client > authorization                | [authorization][]    | Configure generic authorization to the endpoint.                                                 | no
-client > oauth2                       | [oauth2][]           | Configure OAuth2 for authenticating to the endpoint.                                             | no
-client > oauth2 > tls_config          | [tls_config][]       | Configure TLS settings for connecting to the endpoint.                                           | no
-client > tls_config                   | [tls_config][]       | Configure TLS settings for connecting to the endpoint.                                           | no
-selector                              | [selector][]         | Label selector for which `PodLogs` to discover.                                                  | no
-selector > match_expression           | [match_expression][] | Label selector expression for which `PodLogs` to discover.                                       | no
-namespace_selector                    | [selector][]         | Label selector for which namespaces to discover `PodLogs` in.                                    | no
-namespace_selector > match_expression | [match_expression][] | Label selector expression for which namespaces to discover `PodLogs` in.                         | no
-clustering                            | [clustering][]       | Configure the component for when {{< param "PRODUCT_NAME" >}} is running in clustered mode.      | no
-
-The `>` symbol indicates deeper levels of nesting.
-For example, `client > basic_auth` refers to a `basic_auth` block defined inside a `client` block.
-
-[client]: #client-block
-[basic_auth]: #basic_auth-block
-[authorization]: #authorization-block
-[oauth2]: #oauth2-block
-[tls_config]: #tls_config-block
-[selector]: #selector-block
-[match_expression]: #match_expression-block
-[clustering]: #clustering-block
-
-### client block
-
-The `client` block configures the Kubernetes client used to tail logs from
-containers. If the `client` block isn't provided, the default in-cluster
-configuration with the service account of the running {{< param "PRODUCT_NAME" >}} pod is used.
+You can use the following blocks with `loki.source.podlogs`:
+
+| Block                                                         | Description                                                                                 | Required |
+| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------- |
+| [`client`][client]                                            | Configures Kubernetes client used to tail logs.                                             | no       |
+| `client` > [`authorization`][authorization]                   | Configure generic authorization to the endpoint.                                            | no       |
+| `client` > [`basic_auth`][basic_auth]                         | Configure `basic_auth` for authenticating to the endpoint.                                  | no       |
+| `client` > [`oauth2`][oauth2]                                 | Configure OAuth 2.0 for authenticating to the endpoint.                                     | no       |
+| `client` > `oauth2` > [`tls_config`][tls_config]              | Configure TLS settings for connecting to the endpoint.                                      | no       |
+| `client` > [`tls_config`][tls_config]                         | Configure TLS settings for connecting to the endpoint.                                      | no       |
+| [`clustering`][clustering]                                    | Configure the component for when {{< param "PRODUCT_NAME" >}} is running in clustered mode. | no       |
+| [`namespace_selector`][selector]                              | Label selector for which namespaces to discover `PodLogs` in.                               | no       |
+| `namespace_selector` > [`match_expression`][match_expression] | Label selector expression for which namespaces to discover `PodLogs` in.                    | no       |
+| [`selector`][selector]                                        | Label selector for which `PodLogs` to discover.                                             | no       |
+| `selector` > [`match_expression`][match_expression]           | Label selector expression for which `PodLogs` to discover.                                  | no       |
+
+The > symbol indicates deeper levels of nesting.
+For example, `client` > `basic_auth` refers to a `basic_auth` block defined inside a `client` block.
+
+[client]: #client
+[authorization]: #authorization
+[basic_auth]: #basic_auth
+[clustering]: #clustering
+[match_expression]: #match_expression
+[oauth2]: #oauth2
+[selector]: #selector-and-namespace_selector
+[tls_config]: #tls_config
+
+### `client`
+
+The `client` block configures the Kubernetes client used to tail logs from containers.
+If the `client` block isn't provided, the default in-cluster configuration with the service account of the running {{< param "PRODUCT_NAME" >}} Pod is used.
 
 The following arguments are supported:
 
-Name                     | Type                | Description                                                                                      | Default | Required
--------------------------|---------------------|--------------------------------------------------------------------------------------------------|---------|---------
-`api_server`             | `string`            | URL of the Kubernetes API server.                                                                |         | no
-`kubeconfig_file`        | `string`            | Path of the `kubeconfig` file to use for connecting to Kubernetes.                               |         | no
-`bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |         | no
-`bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |         | no
-`enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`  | no
-`follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`  | no
-`proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no
-`no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no
-`proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no
-`proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no
-
- At most, one of the following can be provided:
- - [`bearer_token` argument][client].
- - [`bearer_token_file` argument][client].
- - [`basic_auth` block][basic_auth].
- - [`authorization` block][authorization].
- - [`oauth2` block][oauth2].
+| Name                     | Type                | Description                                                                                      | Default | Required |
+|--------------------------|---------------------|--------------------------------------------------------------------------------------------------|---------|----------|
+| `api_server`             | `string`            | URL of the Kubernetes API server.                                                                |         | no       |
+| `bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |         | no       |
+| `bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |         | no       |
+| `enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`  | no       |
+| `follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`  | no       |
+| `kubeconfig_file`        | `string`            | Path of the `kubeconfig` file to use for connecting to Kubernetes.                               |         | no       |
+| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no       |
+| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no       |
+| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no       |
+| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no       |
+
+At most, one of the following can be provided:
+
+* [`authorization`][authorization] block
+* [`basic_auth`][basic_auth]block
+* [`bearer_token_file`][client] argument
+* [`bearer_token`][client] argument
+* [`oauth2`][oauth2] block
 
 {{< docs/shared lookup="reference/components/http-client-proxy-config-description.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### basic_auth block
-
-{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
-
-### authorization block
+### `authorization`
 
 {{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### oauth2 block
+### `basic_auth`
 
-{{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### tls_config block
+### `clustering`
 
-{{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+| Name      | Type   | Description                                         | Default | Required |
+|-----------|--------|-----------------------------------------------------|---------|----------|
+| `enabled` | `bool` | Distribute log collection with other cluster nodes. |         | yes      |
 
-### selector block
+When {{< param "PRODUCT_NAME" >}} is [using clustering][], and `enabled` is set to true, then this
+`loki.source.podlogs` component instance opts-in to participating in the
+cluster to distribute the load of log collection between all cluster nodes.
 
-The `selector` block describes a Kubernetes label selector for `PodLogs` or Namespace discovery.
+If {{< param "PRODUCT_NAME" >}} is _not_ running in clustered mode, then the block is a no-op and
+`loki.source.podlogs` collects logs based on every PodLogs resource discovered.
 
-The following arguments are supported:
+Clustering looks only at the following labels for determining the shard key:
 
-Name           | Type          | Description                                       | Default | Required
----------------|---------------|---------------------------------------------------|---------|---------
-`match_labels` | `map(string)` | Label keys and values used to discover resources. | `{}`    | no
+* `__pod_namespace__`
+* `__pod_name__`
+* `__pod_container_name__`
+* `__pod_uid__`
+* `__meta_kubernetes_namespace`
+* `__meta_kubernetes_pod_name`
+* `__meta_kubernetes_pod_container_name`
+* `__meta_kubernetes_pod_uid`
+* `container`
+* `pod`
+* `job`
+* `namespace`
 
-When the `match_labels` argument is empty, all resources will be matched.
+[using clustering]: ../../../../get-started/clustering/
 
-### match_expression block
+### `match_expression`
 
 The `match_expression` block describes a Kubernetes label match expression for `PodLogs` or Namespace discovery.
 
 The following arguments are supported:
 
-Name       | Type           | Description                        | Default | Required
------------|----------------|------------------------------------|---------|---------
-`key`      | `string`       | The label name to match against.   |         | yes
-`operator` | `string`       | The operator to use when matching. |         | yes
-`values`   | `list(string)` | The values used when matching.     |         | no
+| Name       | Type           | Description                        | Default | Required |
+|------------|----------------|------------------------------------|---------|----------|
+| `key`      | `string`       | The label name to match against.   |         | yes      |
+| `operator` | `string`       | The operator to use when matching. |         | yes      |
+| `values`   | `list(string)` | The values used when matching.     |         | no       |
 
 The `operator` argument must be one of the following strings:
 
@@ -218,44 +226,33 @@ The `operator` argument must be one of the following strings:
 Both `selector` and `namespace_selector` can make use of multiple
 `match_expression` inner blocks which are treated as AND clauses.
 
-### clustering block
+### `oauth2`
 
-Name      | Type   | Description                                         | Default | Required
-----------|--------|-----------------------------------------------------|---------|---------
-`enabled` | `bool` | Distribute log collection with other cluster nodes. |         | yes
+{{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-When {{< param "PRODUCT_NAME" >}} is [using clustering][], and `enabled` is set to true, then this
-`loki.source.podlogs` component instance opts-in to participating in the
-cluster to distribute the load of log collection between all cluster nodes.
+### `selector` and `namespace_selector`
 
-If {{< param "PRODUCT_NAME" >}} is _not_ running in clustered mode, then the block is a no-op and
-`loki.source.podlogs` collects logs based on every PodLogs resource discovered.
+The `selector` and `namespce_selector` blocks describe a Kubernetes label selector for `PodLogs` or Namespace discovery.
 
-Clustering looks only at the following labels for determining the shard key:
+The following arguments are supported:
 
-* `__pod_namespace__`
-* `__pod_name__`
-* `__pod_container_name__`
-* `__pod_uid__`
-* `__meta_kubernetes_namespace`
-* `__meta_kubernetes_pod_name`
-* `__meta_kubernetes_pod_container_name`
-* `__meta_kubernetes_pod_uid`
-* `container`
-* `pod`
-* `job`
-* `namespace`
+| Name           | Type          | Description                                       | Default | Required |
+|----------------|---------------|---------------------------------------------------|---------|----------|
+| `match_labels` | `map(string)` | Label keys and values used to discover resources. | `{}`    | no       |
 
-[using clustering]: ../../../../get-started/clustering/
+When the `match_labels` argument is empty, all resources are matched.
+
+### `tls_config`
+
+{{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Exported fields
 
-`loki.source.podlogs` does not export any fields.
+`loki.source.podlogs` doesn't export any fields.
 
 ## Component health
 
-`loki.source.podlogs` is only reported as unhealthy if given an invalid
-configuration.
+`loki.source.podlogs` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug information
 
@@ -263,18 +260,16 @@ configuration.
 
 * The labels associated with the target.
 * The full set of labels which were found during service discovery.
-* The most recent time a log line was read and forwarded to the next components
-  in the pipeline.
+* The most recent time a log line was read and forwarded to the next components in the pipeline.
 * The most recent error from tailing, if any.
 
 ## Debug metrics
 
-`loki.source.podlogs` does not expose any component-specific debug metrics.
+`loki.source.podlogs` doesn't expose any component-specific debug metrics.
 
 ## Example
 
-This example discovers all `PodLogs` resources and forwards collected logs to a
-`loki.write` component so they are written to Loki.
+This example discovers all `PodLogs` resources and forwards collected logs to a `loki.write` component so they're written to Loki.
 
 ```alloy
 loki.source.podlogs "default" {
@@ -287,6 +282,7 @@ loki.write "local" {
   }
 }
 ```
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components
diff --git a/docs/sources/reference/components/loki/loki.source.syslog.md b/docs/sources/reference/components/loki/loki.source.syslog.md
index eba0ebf135..ba48845914 100644
--- a/docs/sources/reference/components/loki/loki.source.syslog.md
+++ b/docs/sources/reference/components/loki/loki.source.syslog.md
@@ -3,104 +3,96 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.syslog/ # /docs/alloy/latest/reference/components/loki.source.syslog/
 description: Learn about loki.source.syslog
+labels:
+  stage: general-availability
 title: loki.source.syslog
 ---
 
-# loki.source.syslog
+# `loki.source.syslog`
 
-`loki.source.syslog` listens for syslog messages over TCP or UDP connections and
-forwards them to other `loki.*` components. The messages must be compliant with
-the [RFC5424](https://www.rfc-editor.org/rfc/rfc5424) syslog protocol or the
-[RFC3164](https://datatracker.ietf.org/doc/html/rfc3164) BSD syslog protocol.
+`loki.source.syslog` listens for syslog messages over TCP or UDP connections and forwards them to other `loki.*` components.
+The messages must be compliant with the [RFC5424](https://www.rfc-editor.org/rfc/rfc5424) syslog protocol or the [RFC3164](https://datatracker.ietf.org/doc/html/rfc3164) BSD syslog protocol.
 
-The component starts a new syslog listener for each of the given `config`
-blocks and fans out incoming entries to the list of receivers in `forward_to`.
+The component starts a new syslog listener for each of the given `config` blocks and fans out incoming entries to the list of receivers in `forward_to`.
 
-Multiple `loki.source.syslog` components can be specified by giving them different labels.
+You can specify multiple `loki.source.syslog` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.source.syslog "LABEL" {
+loki.source.syslog "<LABEL>" {
   listener {
-    address = "LISTEN_ADDRESS"
+    address = "<LISTEN_ADDRESS>"
   }
   ...
 
-  forward_to = RECEIVER_LIST
+  forward_to = <RECEIVER_LIST>
 }
 ```
 
 ## Arguments
 
-`loki.source.syslog` supports the following arguments:
+You can use the following arguments with `loki.source.syslog`:
 
-Name            | Type                 | Description                               | Default | Required
-----------------|----------------------|-------------------------------------------|---------|---------
-`forward_to`    | `list(LogsReceiver)` | List of receivers to send log entries to. |         | yes
-`relabel_rules` | `RelabelRules`       | Relabeling rules to apply on log entries. | "{}"    | no
+| Name            | Type                 | Description                               | Default | Required |
+| --------------- | -------------------- | ----------------------------------------- | ------- | -------- |
+| `forward_to`    | `list(LogsReceiver)` | List of receivers to send log entries to. |         | yes      |
+| `relabel_rules` | `RelabelRules`       | Relabeling rules to apply on log entries. | "{}"    | no       |
 
-The `relabel_rules` field can make use of the `rules` export value from a
-[loki.relabel][] component to apply one or more relabeling rules to log entries
-before they're forwarded to the list of receivers in `forward_to`.
+The `relabel_rules` field can make use of the `rules` export value from a [`loki.relabel`][loki.relabel] component to apply one or more relabeling rules to log entries before they're forwarded to the list of receivers in `forward_to`.
 
 [loki.relabel]: ../loki.relabel/
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`loki.source.syslog`:
+You can use the following blocks with `loki.source.syslog`:
 
-Hierarchy             | Name           | Description                                                                 | Required
-----------------------|----------------|-----------------------------------------------------------------------------|---------
-listener              | [listener][]   | Configures a listener for IETF Syslog (RFC5424) messages.                   | no
-listener > tls_config | [tls_config][] | Configures TLS settings for connecting to the endpoint for TCP connections. | no
+| Name                                    | Description                                                                 | Required |
+| --------------------------------------- | --------------------------------------------------------------------------- | -------- |
+| [`listener`][listener]                  | Configures a listener for IETF Syslog (RFC5424) messages.                   | no       |
+| `listener` > [`tls_config`][tls_config] | Configures TLS settings for connecting to the endpoint for TCP connections. | no       |
 
-The `>` symbol indicates deeper levels of nesting. For example, `config > tls_config`
-refers to a `tls_config` block defined inside a `config` block.
+The > symbol indicates deeper levels of nesting.
+For example, `listener` > `tls_config` refers to a `tls_config` block defined inside a `listener` block.
 
-[listener]: #listener-block
-[tls_config]: #tls_config-block
+[listener]: #listener
+[tls_config]: #tls_config
 
-### listener block
+### `listener`
 
-The `listener` block defines the listen address and protocol where the listener
-expects syslog messages to be sent to, as well as its behavior when receiving
-messages.
+The `listener` block defines the listen address and protocol where the listener expects syslog messages to be sent to, as well as its behavior when receiving messages.
 
-The following arguments can be used to configure a `listener`. Only the
-`address` field is required and any omitted fields take their default
-values.
+The following arguments can be used to configure a `listener`.
+Only the `address` field is required and any omitted fields take their default values.
 
-Name                     | Type          | Description                                                                   | Default   | Required
--------------------------|---------------|-------------------------------------------------------------------------------|-----------|---------
-`address`                | `string`      | The `<host:port>` address to listen to for syslog messages.                   |           | yes
-`protocol`               | `string`      | The protocol to listen to for syslog messages. Must be either `tcp` or `udp`. | `tcp`     | no
-`idle_timeout`           | `duration`    | The idle timeout for tcp connections.                                         | `"120s" ` | no
-`label_structured_data`  | `bool`        | Whether to translate syslog structured data to loki labels.                   | `false`   | no
-`labels`                 | `map(string)` | The labels to associate with each received syslog record.                     | `{}`      | no
-`use_incoming_timestamp` | `bool`        | Whether to set the timestamp to the incoming syslog record timestamp.         | `false`   | no
-`use_rfc5424_message`    | `bool`        | Whether to forward the full RFC5424-formatted syslog message.                 | `false`   | no
-`max_message_length`     | `int`         | The maximum limit to the length of syslog messages.                           | `8192`    | no
-`syslog_format`          | `string`      | The format for incoming messages. Must be either `rfc5424` or `rfc3164`.      | `rfc5424` | no
+| Name                     | Type          | Description                                                                   | Default   | Required |
+| ------------------------ | ------------- | ----------------------------------------------------------------------------- | --------- | -------- |
+| `address`                | `string`      | The `<host:port>` address to listen to for syslog messages.                   |           | yes      |
+| `idle_timeout`           | `duration`    | The idle timeout for TCP connections.                                         | `"120s"`  | no       |
+| `label_structured_data`  | `bool`        | Whether to translate syslog structured data to Loki labels.                   | `false`   | no       |
+| `labels`                 | `map(string)` | The labels to associate with each received syslog record.                     | `{}`      | no       |
+| `max_message_length`     | `int`         | The maximum limit to the length of syslog messages.                           | `8192`    | no       |
+| `protocol`               | `string`      | The protocol to listen to for syslog messages. Must be either `tcp` or `udp`. | `tcp`     | no       |
+| `syslog_format`          | `string`      | The format for incoming messages. Must be either `rfc5424` or `rfc3164`.      | `rfc5424` | no       |
+| `use_incoming_timestamp` | `bool`        | Whether to set the timestamp to the incoming syslog record timestamp.         | `false`   | no       |
+| `use_rfc5424_message`    | `bool`        | Whether to forward the full RFC5424-formatted syslog message.                 | `false`   | no       |
 
 By default, the component assigns the log entry timestamp as the time it was processed.
 
 The `labels` map is applied to every message that the component reads.
 
-All header fields from the parsed RFC5424 messages are brought in as
-internal labels, prefixed with `__syslog_`.
+All header fields from the parsed RFC5424 messages are brought in as internal labels, prefixed with `__syslog_`.
 
 If `label_structured_data` is set, structured data in the syslog header is also translated to internal labels in the form of `__syslog_message_sd_<ID>_<KEY>`.
 For example, a  structured data entry of `[example@99999 test="yes"]` becomes the label `__syslog_message_sd_example_99999_test` with the value `"yes"`.
 
-### tls_config block
+### `tls_config`
 
 {{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ## Exported fields
 
-`loki.source.syslog` does not export any fields.
+`loki.source.syslog` doesn't export any fields.
 
 ## Component health
 
@@ -110,19 +102,20 @@ configuration.
 ## Debug information
 
 `loki.source.syslog` exposes some debug information per syslog listener:
-* Whether the listener is currently running.
+
+* Whether the listener is running.
 * The listen address.
 * The labels that the listener applies to incoming log entries.
 
 ## Debug metrics
+
+* `loki_source_syslog_empty_messages_total` (counter): Total number of empty messages received from the syslog component.
 * `loki_source_syslog_entries_total` (counter): Total number of successful entries sent to the syslog component.
 * `loki_source_syslog_parsing_errors_total` (counter): Total number of parsing errors while receiving syslog messages.
-* `loki_source_syslog_empty_messages_total` (counter): Total number of empty messages received from the syslog component.
 
 ## Example
 
-This example listens for Syslog messages in valid RFC5424 format over TCP and
-UDP in the specified ports and forwards them to a `loki.write` component.
+This example listens for syslog messages in valid RFC5424 format over TCP and UDP in the specified ports and forwards them to a `loki.write` component.
 
 ```alloy
 loki.source.syslog "local" {
diff --git a/docs/sources/reference/components/loki/loki.source.windowsevent.md b/docs/sources/reference/components/loki/loki.source.windowsevent.md
index 5f4e9a302d..c484d5bfad 100644
--- a/docs/sources/reference/components/loki/loki.source.windowsevent.md
+++ b/docs/sources/reference/components/loki/loki.source.windowsevent.md
@@ -3,10 +3,12 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.source.windowsevent/ # /docs/alloy/latest/reference/components/loki.source.windowsevent/
 description: Learn about loki.windowsevent
+labels:
+  stage: general-availability
 title: loki.source.windowsevent
 ---
 
-# loki.source.windowsevent
+# `loki.source.windowsevent`
 
 `loki.source.windowsevent` reads events from Windows Event Logs and forwards them to other `loki.*` components.
 
@@ -15,9 +17,9 @@ You can specify multiple `loki.source.windowsevent` components by giving them di
 ## Usage
 
 ```alloy
-loki.source.windowsevent "LABEL" {
-  eventlog_name = EVENTLOG_NAME
-  forward_to    = RECEIVER_LIST
+loki.source.windowsevent "<LABEL>" {
+  eventlog_name = "<EVENTLOG_NAME>"
+  forward_to    = <RECEIVER_LIST>
 }
 ```
 
@@ -25,21 +27,21 @@ loki.source.windowsevent "LABEL" {
 
 The component starts a reader and fans out log entries to the list of receivers passed in `forward_to`.
 
-`loki.source.windowsevent` supports the following arguments:
-
-Name                     | Type                 | Description                                                 | Default                    | Required
--------------------------|----------------------|-------------------------------------------------------------|----------------------------|-----------
-`locale`                 | `number`             | Locale ID for event rendering. 0 default is Windows Locale. | `0`                        | no
-`eventlog_name`          | `string`             | Event log to read from.                                     |                            | See below.
-`xpath_query`            | `string`             | Event log to read from.                                     | `"*"`                      | See below.
-`bookmark_path`          | `string`             | Keeps position in event log.                                | `"DATA_PATH/bookmark.xml"` | no
-`poll_interval`          | `duration`           | How often to poll the event log.                            | `"3s"`                     | no
-`exclude_event_data`     | `bool`               | Exclude event data.                                         | `false`                    | no
-`exclude_user_data`      | `bool`               | Exclude user data.                                          | `false`                    | no
-`exclude_event_message`  | `bool`               | Exclude the human-friendly event message.                   | `false`                    | no
-`use_incoming_timestamp` | `bool`               | When false, assigns the current timestamp to the log.       | `false`                    | no
-`forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.                   |                            | yes
-`labels`                 | `map(string)`        | The labels to associate with incoming logs.                 |                            | no
+You can use the following arguments with `loki.source.windowsevent`:
+
+| Name                     | Type                 | Description                                                 | Default                    | Required  |
+| ------------------------ | -------------------- | ----------------------------------------------------------- | -------------------------- | --------- |
+| `forward_to`             | `list(LogsReceiver)` | List of receivers to send log entries to.                   |                            | yes       |
+| `eventlog_name`          | `string`             | Event log to read from.                                     |                            | See below |
+| `xpath_query`            | `string`             | Event log to read from.                                     | `"*"`                      | See below |
+| `bookmark_path`          | `string`             | Keeps position in event log.                                | `"DATA_PATH/bookmark.xml"` | no        |
+| `exclude_event_data`     | `bool`               | Exclude event data.                                         | `false`                    | no        |
+| `exclude_event_message`  | `bool`               | Exclude the human-friendly event message.                   | `false`                    | no        |
+| `exclude_user_data`      | `bool`               | Exclude user data.                                          | `false`                    | no        |
+| `labels`                 | `map(string)`        | The labels to associate with incoming logs.                 |                            | no        |
+| `locale`                 | `number`             | Locale ID for event rendering. 0 default is Windows Locale. | `0`                        | no        |
+| `poll_interval`          | `duration`           | How often to poll the event log.                            | `"3s"`                     | no        |
+| `use_incoming_timestamp` | `bool`               | When false, assigns the current timestamp to the log.       | `false`                    | no        |
 
 {{< admonition type="note" >}}
 `eventlog_name` is required if `xpath_query` doesn't specify the event log.
@@ -52,6 +54,10 @@ If you use the short form, you must define `eventlog_name`.
 `legacy_bookmark_path` converts the legacy Grafana Agent Static bookmark to a {{< param "PRODUCT_NAME" >}} bookmark, if `bookmark_path` doesn't exist.
 {{< /admonition >}}
 
+## Blocks
+
+The `loki.source.windowsevent` component doesn't support any blocks. You can configure this component with arguments.
+
 ## Component health
 
 `loki.source.windowsevent` is only reported as unhealthy if given an invalid configuration.
diff --git a/docs/sources/reference/components/loki/loki.write.md b/docs/sources/reference/components/loki/loki.write.md
index e1a108a012..9406cf917d 100644
--- a/docs/sources/reference/components/loki/loki.write.md
+++ b/docs/sources/reference/components/loki/loki.write.md
@@ -3,169 +3,173 @@ canonical: https://grafana.com/docs/alloy/latest/reference/components/loki/loki.
 aliases:
   - ../loki.write/ # /docs/alloy/latest/reference/components/loki.write/
 description: Learn about loki.write
+labels:
+  stage: general-availability
 title: loki.write
 ---
 
-# loki.write
+# `loki.write`
 
 `loki.write` receives log entries from other loki components and sends them over the network using the Loki `logproto` format.
 
-Multiple `loki.write` components can be specified by giving them different labels.
+You can specify multiple `loki.write` components by giving them different labels.
 
 ## Usage
 
 ```alloy
-loki.write "LABEL" {
+loki.write "<LABEL>" {
   endpoint {
-    url = REMOTE_WRITE_URL
+    url = "<REMOTE_WRITE_URL>"
   }
 }
 ```
 
 ## Arguments
 
-`loki.write` supports the following arguments:
+You can use the following arguments with `loki.write`:
 
-Name              | Type          | Description                                  | Default      | Required
-------------------|---------------|----------------------------------------------|--------------|---------
-`max_streams`     | `int`         | Maximum number of active streams.            | 0 (no limit) | no
-`external_labels` | `map(string)` | Labels to add to logs sent over the network. |              | no
+| Name              | Type          | Description                                  | Default        | Required |
+| ----------------- | ------------- | -------------------------------------------- | -------------- | -------- |
+| `external_labels` | `map(string)` | Labels to add to logs sent over the network. |                | no       |
+| `max_streams`     | `int`         | Maximum number of active streams.            | `0` (no limit) | no       |
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`loki.write`:
-
-Hierarchy                      | Block             | Description                                                | Required
--------------------------------|-------------------|------------------------------------------------------------|---------
-endpoint                       | [endpoint][]      | Location to send logs to.                                  | no
-wal                            | [wal][]           | Write-ahead log configuration.                             | no
-endpoint > basic_auth          | [basic_auth][]    | Configure `basic_auth` for authenticating to the endpoint. | no
-endpoint > authorization       | [authorization][] | Configure generic authorization to the endpoint.           | no
-endpoint > oauth2              | [oauth2][]        | Configure OAuth2 for authenticating to the endpoint.       | no
-endpoint > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the endpoint.     | no
-endpoint > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the endpoint.     | no
-endpoint > queue_config        | [queue_config][]  | When WAL is enabled, configures the queue client.          | no
-
-The `>` symbol indicates deeper levels of nesting.
-For example, `endpoint > basic_auth` refers to a `basic_auth` block defined inside an `endpoint` block.
-
-[endpoint]: #endpoint-block
-[wal]: #wal-block
-[basic_auth]: #basic_auth-block
-[authorization]: #authorization-block
-[oauth2]: #oauth2-block
-[tls_config]: #tls_config-block
-[queue_config]: #queue_config-block
-
-### endpoint block
+You can use the following blocks with `loki.write`:
+
+| Block                                              | Description                                                | Required |
+| -------------------------------------------------- | ---------------------------------------------------------- | -------- |
+| [`endpoint`][endpoint]                             | Location to send logs to.                                  | no       |
+| `endpoint` > [`authorization`][authorization]      | Configure generic authorization to the endpoint.           | no       |
+| `endpoint` > [`basic_auth`][basic_auth]            | Configure `basic_auth` for authenticating to the endpoint. | no       |
+| `endpoint` > [`oauth2`][oauth2]                    | Configure OAuth 2.0 for authenticating to the endpoint.    | no       |
+| `endpoint` > `oauth2` > [`tls_config`][tls_config] | Configure TLS settings for connecting to the endpoint.     | no       |
+| `endpoint` > [`queue_config`][queue_config]        | When WAL is enabled, configures the queue client.          | no       |
+| `endpoint` > [`tls_config`][tls_config]            | Configure TLS settings for connecting to the endpoint.     | no       |
+| [`wal`][wal]                                       | Write-ahead log configuration.                             | no       |
+
+The > symbol indicates deeper levels of nesting.
+For example, `endpoint` > `basic_auth` refers to a `basic_auth` block defined inside an `endpoint` block.
+
+[authorization]: #authorization
+[basic_auth]: #basic_auth
+[endpoint]: #endpoint
+[oauth2]: #oauth2
+[queue_config]: #queue_config
+[tls_config]: #tls_config
+[wal]: #wal
+
+### `endpoint`
 
 The `endpoint` block describes a single location to send logs to.
 You can use multiple `endpoint` blocks to send logs to multiple locations.
 
 The following arguments are supported:
 
-Name                     | Type                | Description                                                                                      | Default   | Required
--------------------------|---------------------|--------------------------------------------------------------------------------------------------|-----------|---------
-`url`                    | `string`            | Full URL to send logs to.                                                                        |           | yes
-`name`                   | `string`            | Optional name to identify this endpoint with.                                                    |           | no
-`headers`                | `map(string)`       | Extra headers to deliver with the request.                                                       |           | no
-`batch_wait`             | `duration`          | Maximum amount of time to wait before sending a batch.                                           | `"1s"`    | no
-`batch_size`             | `string`            | Maximum batch size of logs to accumulate before sending.                                         | `"1MiB"`  | no
-`remote_timeout`         | `duration`          | Timeout for requests made to the URL.                                                            | `"10s"`   | no
-`tenant_id`              | `string`            | The tenant ID used by default to push logs.                                                      |           | no
-`min_backoff_period`     | `duration`          | Initial backoff time between retries.                                                            | `"500ms"` | no
-`max_backoff_period`     | `duration`          | Maximum backoff time between retries.                                                            | `"5m"`    | no
-`max_backoff_retries`    | `int`               | Maximum number of retries.                                                                       | 10        | no
-`retry_on_http_429`      | `bool`              | Retry when an HTTP 429 status code is received.                                                  | `true`    | no
-`bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |           | no
-`bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |           | no
-`enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`    | no
-`follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`    | no
-`proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |           | no
-`no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |           | no
-`proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false`   | no
-`proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |           | no
+| Name                     | Type                | Description                                                                                      | Default   | Required |
+| ------------------------ | ------------------- | ------------------------------------------------------------------------------------------------ | --------- | -------- |
+| `url`                    | `string`            | Full URL to send logs to.                                                                        |           | yes      |
+| `batch_size`             | `string`            | Maximum batch size of logs to accumulate before sending.                                         | `"1MiB"`  | no       |
+| `batch_wait`             | `duration`          | Maximum amount of time to wait before sending a batch.                                           | `"1s"`    | no       |
+| `bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |           | no       |
+| `bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |           | no       |
+| `enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`    | no       |
+| `follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`    | no       |
+| `headers`                | `map(string)`       | Extra headers to deliver with the request.                                                       |           | no       |
+| `max_backoff_period`     | `duration`          | Maximum backoff time between retries.                                                            | `"5m"`    | no       |
+| `max_backoff_retries`    | `int`               | Maximum number of retries.                                                                       | 10        | no       |
+| `min_backoff_period`     | `duration`          | Initial backoff time between retries.                                                            | `"500ms"` | no       |
+| `name`                   | `string`            | Optional name to identify this endpoint with.                                                    |           | no       |
+| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |           | no       |
+| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |           | no       |
+| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false`   | no       |
+| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |           | no       |
+| `remote_timeout`         | `duration`          | Timeout for requests made to the URL.                                                            | `"10s"`   | no       |
+| `retry_on_http_429`      | `bool`              | Retry when an HTTP 429 status code is received.                                                  | `true`    | no       |
+| `tenant_id`              | `string`            | The tenant ID used by default to push logs.                                                      |           | no       |
 
  At most, one of the following can be provided:
- - [`bearer_token` argument](#endpoint-block).
- - [`bearer_token_file` argument](#endpoint-block).
- - [`basic_auth` block][basic_auth].
- - [`authorization` block][authorization].
- - [`oauth2` block][oauth2].
+
+* [`authorization`][authorization] block
+* [`basic_auth`][basic_auth] block
+* [`bearer_token_file`][endpoint] argument
+* [`bearer_token`][endpoint] argument
+* [`oauth2`][oauth2] block
 
 {{< docs/shared lookup="reference/components/http-client-proxy-config-description.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-If no `tenant_id` is provided, the component assumes that the Loki instance at
-`endpoint` is running in single-tenant mode and no X-Scope-OrgID header is
-sent.
+If no `tenant_id` is provided, the component assumes that the Loki instance at `endpoint` is running in single-tenant mode and no X-Scope-OrgID header is sent.
 
-When multiple `endpoint` blocks are provided, the `loki.write` component
-creates a client for each. Received log entries are fanned-out to these clients
-in succession. That means that if one client is bottlenecked, it may impact
-the rest.
+When multiple `endpoint` blocks are provided, the `loki.write` component creates a client for each.
+Received log entries are fanned-out to these clients in succession.
+That means that if one client is bottlenecked, it may impact the rest.
 
-Endpoints can be named for easier identification in debug metrics by using the
-`name` argument. If the `name` argument isn't provided, a name is generated
-based on a hash of the endpoint settings.
+Endpoints can be named for easier identification in debug metrics by using the `name` argument. If the `name` argument isn't provided, a name is generated based on a hash of the endpoint settings.
 
-The `retry_on_http_429` argument specifies whether `HTTP 429` status code
-responses should be treated as recoverable errors; other `HTTP 4xx` status code
-responses are never considered recoverable errors. When `retry_on_http_429` is
-enabled, the retry mechanism will be governed by the backoff configuration specified through `min_backoff_period`, `max_backoff_period ` and `max_backoff_retries` attributes.
+The `retry_on_http_429` argument specifies whether `HTTP 429` status code responses should be treated as recoverable errors.
+Other `HTTP 4xx` status code responses are never considered recoverable errors.
+When `retry_on_http_429` is enabled, the retry mechanism is governed by the backoff configuration specified through `min_backoff_period`, `max_backoff_period` and `max_backoff_retries` attributes.
 
-### basic_auth block
+### `authorization`
 
-{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### authorization block
+### `basic_auth`
 
-{{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+{{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### oauth2 block
+### `oauth2`
 
 {{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### tls_config block
+### `queue_config`
 
-{{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
+> **EXPERIMENTAL**: This is an [experimental][] feature.
+> Experimental features are subject to frequent breaking changes, and may be removed with no equivalent replacement.
+> The `stability.level` flag must be set to `experimental` to use the feature.
 
-### queue_config block (experimental)
+[experimental]: https://grafana.com/docs/release-life-cycle/
 
 The optional `queue_config` block configures, when WAL is enabled, how the underlying client queues batches of logs sent to Loki.
-Refer to [Write-Ahead block](#wal-block-experimental) for more information.
+Refer to [Write-Ahead block](#wal) for more information.
 
 The following arguments are supported:
 
-| Name            | Type       | Description                                                                                                                                                                     | Default | Required |
-|-----------------|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------|----------|
-| `capacity`      | `string`   | Controls the size of the underlying send queue buffer. This setting should be considered a worst-case scenario of memory consumption, in which all enqueued batches are full.   | `10MiB` | no       |
-| `drain_timeout` | `duration` | Configures the maximum time the client can take to drain the send queue upon shutdown. During that time, it will enqueue pending batches and drain the send queue sending each. | `"1m"`  | no       |
+| Name            | Type       | Description                                                                                                                                                                   | Default | Required |
+| --------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | -------- |
+| `capacity`      | `string`   | Controls the size of the underlying send queue buffer. This setting should be considered a worst-case scenario of memory consumption, in which all enqueued batches are full. | `10MiB` | no       |
+| `drain_timeout` | `duration` | Configures the maximum time the client can take to drain the send queue upon shutdown. During that time, it enqueues pending batches and drains the send queue sending each.  | `"1m"`  | no       |
+
+### `tls_config`
+
+{{< docs/shared lookup="reference/components/tls-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-### wal block (experimental)
+### `wal`
 
-The optional `wal` block configures the Write-Ahead Log (WAL) used in the Loki remote-write client. To enable the WAL,
-you must include the `wal` block in your configuration. When the WAL is enabled, the log entries sent to the `loki.write`
-component are first written to a WAL under the `dir` directory and then read into the remote-write client. This process
-provides durability guarantees when an entry reaches this component. The client knows when to read from the WAL using the
-following two mechanisms:
-- The WAL-writer side of the `loki.write` component notifies the reader side that new data is available.
-- The WAL-reader side periodically checks if there is new data, increasing the wait time exponentially between
-`min_read_frequency` and `max_read_frequency`.
+> **EXPERIMENTAL**: This is an [experimental][] feature.
+> Experimental features are subject to frequent breaking changes, and may be removed with no equivalent replacement.
+> The `stability.level` flag must be set to `experimental` to use the feature.
 
-The WAL is located inside a component-specific directory relative to the
-storage path {{< param "PRODUCT_NAME" >}} is configured to use. See the
-[`alloy run` documentation][run] for how to change the storage path.
+The optional `wal` block configures the Write-Ahead Log (WAL) used in the Loki remote-write client.
+To enable the WAL, you must include the `wal` block in your configuration.
+When the WAL is enabled, the log entries sent to the `loki.write` component are first written to a WAL under the `dir` directory and then read into the remote-write client.
+This process provides durability guarantees when an entry reaches this component. The client knows when to read from the WAL using the following two mechanisms:
+
+* The WAL-writer side of the `loki.write` component notifies the reader side that new data is available.
+* The WAL-reader side periodically checks if there is new data, increasing the wait time exponentially between `min_read_frequency` and `max_read_frequency`.
+
+The WAL is located inside a component-specific directory relative to the storage path {{< param "PRODUCT_NAME" >}} is configured to use.
+Refer to the [`run` documentation][run] for more information about how to change the storage path.
 
 The following arguments are supported:
 
-Name                 | Type       | Description                                                                                                        | Default   | Required
----------------------|------------|--------------------------------------------------------------------------------------------------------------------|-----------|---------
-`enabled`            | `bool`     | Whether to enable the WAL.                                                                                         | false     | no
-`max_segment_age`    | `duration` | Maximum time a WAL segment should be allowed to live. Segments older than this setting will be eventually deleted. | `"1h"`    | no
-`min_read_frequency` | `duration` | Minimum backoff time in the backup read mechanism.                                                                 | `"250ms"` | no
-`max_read_frequency` | `duration` | Maximum backoff time in the backup read mechanism.                                                                 | `"1s"`    | no
-`drain_timeout`      | `duration` | Maximum time the WAL drain procedure can take, before being forcefully stopped.                                    | `"30s"`   | no
+| Name                 | Type       | Description                                                                                                    | Default   | Required |
+| -------------------- | ---------- | -------------------------------------------------------------------------------------------------------------- | --------- | -------- |
+| `drain_timeout`      | `duration` | Maximum time the WAL drain procedure can take, before being forcefully stopped.                                | `"30s"`   | no       |
+| `enabled`            | `bool`     | Whether to enable the WAL.                                                                                     | false     | no       |
+| `max_read_frequency` | `duration` | Maximum backoff time in the backup read mechanism.                                                             | `"1s"`    | no       |
+| `max_segment_age`    | `duration` | Maximum time a WAL segment should be allowed to live. Segments older than this setting are eventually deleted. | `"1h"`    | no       |
+| `min_read_frequency` | `duration` | Minimum backoff time in the backup read mechanism.                                                             | `"250ms"` | no       |
 
 [run]: ../../../cli/run/
 
@@ -173,9 +177,9 @@ Name                 | Type       | Description
 
 The following fields are exported and can be referenced by other components:
 
-Name       | Type           | Description
------------|----------------|--------------------------------------------------------------
-`receiver` | `LogsReceiver` | A value that other components can use to send log entries to.
+| Name       | Type           | Description                                                   |
+| ---------- | -------------- | ------------------------------------------------------------- |
+| `receiver` | `LogsReceiver` | A value that other components can use to send log entries to. |
 
 ## Component health
 
@@ -183,17 +187,17 @@ Name       | Type           | Description
 
 ## Debug information
 
-`loki.write` does not expose any component-specific debug
-information.
+`loki.write` doesn't expose any component-specific debug information.
 
 ## Debug metrics
-* `loki_write_encoded_bytes_total` (counter): Number of bytes encoded and ready to send.
-* `loki_write_sent_bytes_total` (counter): Number of bytes sent.
+
+* `loki_write_batch_retries_total` (counter): Number of times batches have had to be retried.
 * `loki_write_dropped_bytes_total` (counter): Number of bytes dropped because failed to be sent to the ingester after all retries.
-* `loki_write_sent_entries_total` (counter): Number of log entries sent to the ingester.
 * `loki_write_dropped_entries_total` (counter): Number of log entries dropped because they failed to be sent to the ingester after all retries.
+* `loki_write_encoded_bytes_total` (counter): Number of bytes encoded and ready to send.
 * `loki_write_request_duration_seconds` (histogram): Duration of sent requests.
-* `loki_write_batch_retries_total` (counter): Number of times batches have had to be retried.
+* `loki_write_sent_bytes_total` (counter): Number of bytes sent.
+* `loki_write_sent_entries_total` (counter): Number of log entries sent to the ingester.
 * `loki_write_stream_lag_seconds` (gauge): Difference between current time and last batch timestamp for successful sends.
 
 ## Examples
@@ -227,11 +231,12 @@ loki.write "default" {
     }
 }
 ```
+
 ## Technical details
 
 `loki.write` uses [snappy](https://en.wikipedia.org/wiki/Snappy_(compression)) for compression.
 
-Any labels that start with `__` will be removed before sending to the endpoint.
+Any labels that start with `__` are removed before sending to the endpoint.
 
 <!-- START GENERATED COMPATIBLE COMPONENTS -->