Docs reviews (#8359)

Author: mauroservienti

nservicebus/hosting/nservicebus-host/nservicebus-32-bit-x86-host-process.md

@@ -4,18 +4,18 @@ summary: If 32-bit code must be invoked and loaded, use NServiceBus.Host32.exe
 component: Host
 redirects:
  - nservicebus/nservicebus-32-bit-x86-host-process
-reviewed: 2024-10-16
+reviewed: 2026-06-22
 ---
 
-NServiceBus is an "Any CPU" framework. It doesn't have 32-bit or 64-bit specific code. This enables transitioning between 32- and 64-bit operating systems. Unfortunately, not all assemblies can be compiled using the default Any CPU architecture. In many, this is related to legacy systems that have 32-bit specific code for platform interoperability with native C libraries, etc.
+NServiceBus is an "Any CPU" framework. It doesn't have 32-bit- or 64-bit-specific code. This enables transitioning between 32- and 64-bit operating systems. Unfortunately, not all assemblies can be compiled using the default Any CPU architecture. For example, this might be related to legacy systems that have 32-bit-specific code for platform interoperability with native C libraries.
 
-With the default NServiceBus.Host, the application always loads in 64-bit (x64) mode if running on a 64-bit OS, or in 32-bit (x86) mode for a 32-bit OS. Again, this is typically not a problem.
+With the default NServiceBus.Host, the application always loads in 64-bit (x64) mode on a 64-bit OS, or in 32-bit (x86) mode on a 32-bit OS. Again, this is typically not a problem.
 
-If assemblies or other libraries containing 32-bit code must be invoked and loaded into a 64-bit process a `BadImageFormatException` will be thrown.
+If assemblies or other libraries containing 32-bit code must be invoked and loaded into a 64-bit process, a `BadImageFormatException` will be thrown.
 
-There are two specific versions of the NServiceBus Host: the default *Any CPU* version and `NServiceBus.Host32.exe`targeting 32-bit.
+There are two specific versions of the NServiceBus Host: the default *Any CPU* version and `NServiceBus.Host32.exe` targeting 32-bit.
 
-The second one allows users running a 64-bit OS to run a 32-bit NServiceBus host process, allowing execution of 32-bit binaries/code without resorting to workarounds such as `corflags.exe` to patch an assembly, which instruct the .NET Framework to run in 32-bit mode.
+The second one allows users running a 64-bit OS to run a 32-bit NServiceBus host process, allowing execution of 32-bit binaries/code without resorting to workarounds such as `corflags.exe` to patch an assembly, which instructs the .NET Framework to run in 32-bit mode.
 
 Links to the NuGet packages:
 

nservicebus/recoverability/subscribing-to-error-notifications.md

@@ -1,7 +1,7 @@
 ---
 title: Error notifications
 summary: Subscribing to error notifications
-reviewed: 2024-10-24
+reviewed: 2026-06-22
 component: Core
 versions: '[5.0,)'
 redirects:
@@ -16,15 +16,14 @@ Error notifications are available for several events:
 
  * When an [immediate retry](/nservicebus/recoverability/#immediate-retries) occurs.
  * When a [delayed retry](/nservicebus/recoverability/#delayed-retries) occurs.
- * When a message fails, all retries fail, and the message is forwarded to the error queue.
+ * When a message, after exhausting all retries, is forwarded to the error queue.
 
-The following example shows how to be notified every time a message is handled by [recoverability](/nservicebus/recoverability/). While this code writes to the console, any other action could be taken, for example, sending an email or writing to a monitoring system.
+The following example shows how to be notified whenever a message is handled by [recoverability](/nservicebus/recoverability/). While this code writes to the console, any other action could be taken, for example, sending an email or writing to a monitoring system.
 
 snippet: SubscribeToErrorsNotifications
 
 include: notificationThread
 
-
 ## Message Body
 
 include: error-notifications-message-body

persistence/cosmosdb/saga-concurrency.md

@@ -2,14 +2,14 @@
 title: CosmosDB Persistence Saga Concurrency
 summary: Explains how concurrency works with sagas in the CosmosDB persister
 component: CosmosDB
-reviewed: 2024-10-15
+reviewed: 2026-06-22
 related:
  - nservicebus/sagas/concurrency
 ---
 
 ## Default behavior
 
-When simultaneously handling messages, conflicts may occur. See below for examples of the exceptions which are thrown. _[Saga concurrency](/nservicebus/sagas/concurrency.md)_ explains how these conflicts are handled, and contains guidance for high-load scenarios.
+When handling messages simultaneously, conflicts may occur. See below for examples of the exceptions that are thrown. _[Saga concurrency](/nservicebus/sagas/concurrency.md)_ explains how these conflicts are handled, and contains guidance for high-load scenarios.
 
 include: saga-concurrency
 
@@ -31,4 +31,4 @@ Example exception:
 The 'OrderSagaData' saga with id '7ac4d199-6560-4d1a-b83a-b3dad94b0802' was updated by another process or no longer exists.
 ```
 
-partial: pessimistic-locking
+partial: pessimistic-locking

persistence/cosmosdb/saga-concurrency_pessimistic-locking_CosmosDB_[1,].partial.md

@@ -12,7 +12,7 @@ CosmosDB does not support pessimistic locking natively. The behavior is based on
 > It is recommended to choose pessimistic concurrency over optimistic concurrency whenever a saga is experiencing a high number of optimistic concurrency control errors.
 
 > [!NOTE]
-> When using pessimistic locking with provisioned throughput it is important to understand the additional patch operation attempts that are issued during the saga loading attempt will lead to higher RU usage. It is important to set the lease lock acquisition minimum and maximum refresh delay according in alignment with the saga contention scenarios to avoid using too much unnecessary RUs.
+> When using pessimistic locking with provisioned throughput, it is important to understand that the additional patch operation attempts that are issued during the saga loading attempt will lead to higher RU usage. It is important to set the lease lock acquisition minimum and maximum refresh delay in alignment with the saga contention scenarios to avoid using too many unnecessary RUs.
 
 ### Pessimistic concurrency control settings
 
@@ -32,6 +32,6 @@ snippet: PessimisticLeaseLockAcquisitionTimeout
 
 ### Pessimistic lease lock acquisition minimum and maximum refresh delay
 
-To prevent request synchronization, the persister randomizes the interval between lock acquisition requests. By default, the interval has a value between 500 and 1000 milliseconds. These values can be adjusted using the following API:
+To prevent request synchronization, the persister randomizes the interval between lock acquisition requests. By default, the interval is between 500 and 1000 milliseconds. These values can be adjusted using the following API:
 
-snippet: PessimisticLeaseLockAcquisitionMinMaxRefreshDelay
+snippet: PessimisticLeaseLockAcquisitionMinMaxRefreshDelay

servicepulse/event-types.md

@@ -1,54 +1,49 @@
 ---
 title: ServicePulse events
 summary: Introduction to ServicePulse monitoring events
-reviewed: 2024-10-16
+reviewed: 2026-06-22
 component: ServicePulse
 related:
 - monitoring/custom-checks/in-servicepulse
 ---
 
-ServicePulse gives an overview of a system's health, based on endpoints heartbeats and custom checks, and a detailed view of failed messages.
+ServicePulse provides an overview of a system's health based on endpoints' heartbeats and custom checks, as well as a detailed view of failed messages.
 
 > [!NOTE]
 > The same information can be consumed not only via the ServicePulse web interface, but also by subscribing to [custom notifications and alerts from ServiceControl](/servicecontrol/contracts.md).
 
-
 ### Heartbeats
 
-
 #### HeartbeatStopped
 
-The `HeartbeatStopped` event is published each time the monitoring infrastructure does not receive a heartbeat from an endpoint within the expected amount of time.
-
+The `HeartbeatStopped` event is published whenever the monitoring infrastructure fails to receive a heartbeat from an endpoint within the expected time.
 
 #### HeartbeatRestored
 
-The `HeartbeatRestored` event is published to notify when a previously stopped heartbeat has been restored and the related endpoint is running as expected.
+The `HeartbeatRestored` event is published to notify when a previously stopped heartbeat has been restored, and the related endpoint is running as expected.
 
 More details on endpoints and heartbeats in [ServicePulse](/monitoring/heartbeats/in-servicepulse.md).
 
-
 ### MessageFailed
 
-The `MessageFailed` event is published to notify that a message has failed all the [immediate retry](/nservicebus/recoverability/#immediate-retries) steps and all the [delayed retry](/nservicebus/recoverability/#delayed-retries) steps and has reached the configured error queue. The event itself carries all the details of the failure and has a `MessageStatus` enumeration that details the type of failure:
+The `MessageFailed` event is published to indicate that a message has failed all the [immediate retry](/nservicebus/recoverability/#immediate-retries) and [delayed retry](/nservicebus/recoverability/#delayed-retries) steps and has reached the configured error queue. The event itself carries all the details of the failure and has a `MessageStatus` enumeration that details the type of failure:
 
  * `Failed`: The message has failed and has arrived for the first time in the error queue;
  * `RepeatedFailure`: The message has failed multiple times;
  * `ArchivedFailure`: The message has been deleted;
 
 More details on [failed message monitoring in ServicePulse](intro-failed-messages.md).
 
-
 ### Custom check / Periodic check
 
-Custom checks allow an endpoint to notify ServicePulse if a business related condition is not met. The endpoint heartbeat signals that the endpoint is running and that a custom check can add more information, for example, that the endpoint is running and can access the external resources required to operate correctly.
+Custom checks allow an endpoint to notify ServicePulse if a business-related condition is not met. The endpoint heartbeat signals that the endpoint is running and that a custom check can add more information, for example, that the endpoint is running and can access the external resources required to operate correctly.
 
 ## Dashboard screen
 
 The dashboard shows the last 10 events that were reported by ServiceControl.
 
 ![dashboard](images/events-dashboard.png 'width=500')
 
-View all events by clicking on the 'Events' link in the menu or the 'View all events' link on the dashboard. These links redirect to the dedicated events page which shows all events captured within ServiceControl.
+View all events by clicking on the 'Events' link in the menu or the 'View all events' link on the dashboard. These links redirect to the dedicated events page, which shows all events captured within ServiceControl.
 
 ![event page](images/events-page.png 'width=500')