diff --git a/documentation/releaseNotes/releaseNotes.md b/documentation/releaseNotes/releaseNotes.md
index 904bb7c99ac..0d8789b6f0d 100644
--- a/documentation/releaseNotes/releaseNotes.md
+++ b/documentation/releaseNotes/releaseNotes.md
@@ -1,9 +1,4 @@
 Today we are releasing the next official preview of the `dotnet-monitor` tool. This release includes:
 
-- ⚠️ A breaking change to ApiKey authentication. The `ApiAuthentication` configuration settings used in preview 6 and below will not work with preview 7 and later. We have dropped the custom authentication scheme `MonitorApiKey` and the corresponding payload format. The new ApiKey format uses the standard [`Bearer` authentication scheme](https://datatracker.ietf.org/doc/html/rfc6750.html#section-2.1) with a [JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519) payload. Use the command `dotnet monitor generatekey` to make new ApiKey credentials and the corresponding configuration. See [API Key Authentication](https://github.com/dotnet/dotnet-monitor/blob/main/documentation/authentication.md#api-key-authentication) for full details. (#247)
-- Improved detail provided in [`schema.json`](https://github.com/dotnet/dotnet-monitor/blob/main/documentation/schema.json) to more readily document configuration options. (#704)
-- Add command line option to `collect`, `--no-http-egress`, to disable HTTP egress, allowing administrator control on how data may be egressed from `dotnet monitor`. See [Disabling HTTP Egress](https://github.com/dotnet/dotnet-monitor/blob/main/documentation/egress.md#disabling-http-egress) for details. (#202)
-- The `generatekey` command has one new command line parameter, `--output`. With this parameter, the output format of the Authentication configuration may be specified to be one of: `Json`, `Text`, `Cmd`, `PowerShell` or `Shell`. See [Generating an API Key](https://github.com/dotnet/dotnet-monitor/blob/main/documentation/authentication.md#generating-an-api-key) for details. (#589)
-- ⚠️ The `generatekey` command line parameters `--hash-algorithm` and `--key-length` have been removed. (#247)
 
 \*⚠️ **_indicates a breaking change_**
diff --git a/documentation/releaseNotes/releaseNotes.v5.0.0-preview.6.21370.3.md b/documentation/releaseNotes/releaseNotes.v5.0.0-preview.6.21370.3.md
new file mode 100644
index 00000000000..c7956de3283
--- /dev/null
+++ b/documentation/releaseNotes/releaseNotes.v5.0.0-preview.6.21370.3.md
@@ -0,0 +1,9 @@
+Today we are releasing the next official preview of the `dotnet-monitor` tool. This release includes:
+- `MonitorApiKey` now supports a configurable key length and hash algorithm. Both the key length (`--key-length`) and hash algorithm (`--hash-algorithm`) can also be supplied to the `generatekey` command via command line parameters.   (#361)
+- The `/logs` endpoint now supports egressing logs with the [`application/json-seq`](https://datatracker.ietf.org/doc/html/rfc7464) Content-Type. (#468)
+- ⚠️ Process selection uses query string instead of path segments. For example, a call to collect a gcdump of process id 21632 would now look like `GET /gcdump?pid=21632`. In addition to`pid` all other process selectors (`uid` and `name`) can also be specified via query string. This change impacts the `/process`, `/dump`, `/gcdump`, `/trace`, and `/logs` endpoint. (#496)
+- ⚠️ Change in configuration for egress providers to allow for easier discoverability and greater extensibility. Each provider has a top-level configuration node under the `Egress` section. (#515)
+- New `/info` API endpoint for diagnostics that provides the `dotnet monitor` version number, the runtime version, and the diagnostic port settings used to connect to a target process. (#540)
+- ⚠️ New operational-style API by endpoints that produce a diagnostic artifact when egressed (`/dump`, `/gcdump`, `/trace`, and `/logs`). Prior to this change, long-running operations synchronously waited until the diagnostic artifact had been handled by an egress provider (e.g., a call to `/dump` would not return a HTTP response until the dump was written to Azure blob storage). The new API, will immediately return a 202 response with an operation id. Clients can then use this operation id to query the newly introduced `/operations` API to query `dotnet monitor` about the status of the operation. (#425)
+
+\*⚠️ **_indicates a breaking change_**