Particular · ngallegos · Jan 6, 2026 · Jan 5, 2026
diff --git a/nservicebus/compliance/fips.md b/nservicebus/compliance/fips.md
@@ -38,6 +38,6 @@ The following packages use MD5 and cannot be used with FIPS enforcement enabled:
 
 ## Disable enforcement of FIPS
 
-ServiceControl, ServicePulse, and ServiceInsight also use MD5 internally and will require disabling FIPS enforcement to run properly. As these tools do not execute user code and can be audited as 100% open source, it is sometimes possible to obtain a waiver to run these tools with a configuration flag that instructs the .NET Framework to skip enforcement of FIPS even when configured to do so at the server level with group policy.
+ServiceControl and ServicePulse also use MD5 internally and will require disabling FIPS enforcement to run properly. As these tools do not execute user code and can be audited as 100% open source, it is sometimes possible to obtain a waiver to run these tools with a configuration flag that instructs the .NET Framework to skip enforcement of FIPS even when configured to do so at the server level with group policy.
 
 FIPS enforcement can be disabled by setting the runtime setting `enforceFIPSPolicy` to `false` in the application's app.config or web.config. See the [MSDN article on how to change this setting](https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/enforcefipspolicy-element).
diff --git a/nservicebus/hosting/override-hostid.md b/nservicebus/hosting/override-hostid.md
@@ -12,7 +12,7 @@ reviewed: 2024-10-14
 
 In NServiceBus, all messages sent to the audit queue include two extra headers: `$.diagnostics.hostid` and `$.diagnostics.hostdisplayname`. These extra headers uniquely identify the running host for the endpoint, i.e. the operating system host (not to be confused with `NServiceBus.Host`). 
 
-The host ID is used by ServiceControl to map a running endpoint to the host where they are deployed. This information is then displayed in ServicePulse and ServiceInsight so it's possible to identify in which host the endpoint is running.
+The host ID is used by ServiceControl to map a running endpoint to the host where they are deployed. This information is then displayed in ServicePulse so it's possible to identify in which host the endpoint is running.
 
 The default values in most scenarios is the machine name for `$.diagnostics.hostdisplayname` and a hash of the running executable's  path concatenated with the machine name for `$.diagnostics.hostid`.
 
@@ -26,6 +26,6 @@ snippet: HostIdFixer
 
 ## Stable host identifiers when using Docker
 
-Docker containers hosted in Kubernetes pose unique challenges to creating a stable host identifier, as a [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) will not have a stable, unique identifier. This results in the endpoint having a new, random identity in ServicePulse and ServiceInsight every time the Pod containing the endpoint is (re)scheduled on a different node.
+Docker containers hosted in Kubernetes pose unique challenges to creating a stable host identifier, as a [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) will not have a stable, unique identifier. This results in the endpoint having a new, random identity in ServicePulse every time the Pod containing the endpoint is (re)scheduled on a different node.
 
 Instead of a Deployment, an endpoint can be deployed to Kubernetes using a [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/), which provides stable, unique network identifiers, allowing the host identifier to be specified as shown above.
diff --git a/nservicebus/licensing/index.md b/nservicebus/licensing/index.md
@@ -12,7 +12,6 @@ related:
  - nservicebus/upgrades/release-policy
  - nservicebus/upgrades/support-policy
  - servicecontrol/license
- - serviceinsight/license
 ---
 
 ## License details

diff --git a/nservicebus/messaging/headers.md b/nservicebus/messaging/headers.md
@@ -273,7 +273,7 @@ snippet: HeaderWriterDefer
 
 ## Diagnostic and informational headers
 
-Headers used to give visibility into the "where," "when," and "by whom" of a message. They are used by [ServiceControl](/servicecontrol/), [ServiceInsight](/serviceinsight/) and [ServicePulse](/servicepulse/).
+Headers used to give visibility into the "where," "when," and "by whom" of a message. They are used by [ServiceControl](/servicecontrol/) and [ServicePulse](/servicepulse/).
 
 ### $.diagnostics
 
@@ -296,7 +296,7 @@ The timestamp when the message should be delivered. Used for more accurate calcu
 The endpoint name the message was sent from.
 
 > [!NOTE]
-> Used for linking messages in ServiceInsight and ServicePulse. See [NServiceBus.ConversationId](#messaging-interaction-headers-nservicebus-conversationid)
+> Used for linking messages in ServicePulse. See [NServiceBus.ConversationId](#messaging-interaction-headers-nservicebus-conversationid)
 
 ### NServiceBus.OriginatingMachine
 
@@ -327,7 +327,7 @@ The timestamp when the processing of a message ended.
 Name of the endpoint where the message was processed.
 
 > [!NOTE]
-> Used for linking messages in ServiceInsight and ServicePulse. See [NServiceBus.ConversationId](#messaging-interaction-headers-nservicebus-conversationid)
+> Used for linking messages in ServicePulse. See [NServiceBus.ConversationId](#messaging-interaction-headers-nservicebus-conversationid)
 
 ### NServiceBus.ProcessingMachine
 

diff --git a/nservicebus/operations/auditing.md b/nservicebus/operations/auditing.md
@@ -19,7 +19,7 @@ The distributed nature of parallel, message-driven systems makes them more diffi
 It is recommended to specify a central auditing queue for all related endpoints (i.e., endpoints that belong to the same system). This gives an overview of the entire system in one place and can help see how messages correlate. The audit queue can be considered a central record of everything that happened in the system.
 
 > [!IMPORTANT]
-> When auditing NServiceBus messages, it is important to have the capability to process messages sent to the audit queue: The Particular Service Platform, specifically [ServiceControl](/servicecontrol), processes messages from these auditing queues to provide diagnostic and visualization features. For more information, see the [ServiceInsight](/serviceinsight/) and [ServicePulse](/servicepulse/) documentation.
+> When auditing NServiceBus messages, it is important to have the capability to process messages sent to the audit queue: The Particular Service Platform, specifically [ServiceControl](/servicecontrol), processes messages from these auditing queues to provide diagnostic and visualization features. For more information, see the [ServicePulse](/servicepulse/) documentation.
 
 ## How it works
 

diff --git a/nservicebus/recoverability/configure-error-handling.md b/nservicebus/recoverability/configure-error-handling.md
@@ -2,7 +2,7 @@
 title: Configure error handling
 summary: Configure handling of failed messages
 component: Core
-reviewed: 2025-04-28
+reviewed: 2026-01-05
 redirects:
 - nservicebus/configure-error-queue
 related:
@@ -44,9 +44,9 @@ snippet: ErrorHeadersCustomizations
 
 Administrators should monitor the error queue in order to detect when problems occur. The message in the error queue contains relevant information such as the endpoint that initially processed the message and exception details. This allows an administrator to investigate the problem.
 
-Monitoring and handling of failed messages with [ServicePulse](/servicepulse/) provides access to full exception details, including the stack-trace. [ServiceInsight](/serviceinsight/) and ServicePulse offer advanced debugging capabilities, providing additional information like exception details as well as visualizing the flow of messages. They also provide `retry` functionality, which sends a failed message from the error queue back to the originating endpoint for re-processing. For more details on how to retry a message using ServicePulse, see [Introduction to Failed Messages Monitoring in ServicePulse](/servicepulse/intro-failed-messages.md). To retry a message using ServiceInsight, see [Managing Errors and Retries in ServiceInsight](/serviceinsight/managing-errors-and-retries.md).
+Monitoring and handling of failed messages with [ServicePulse](/servicepulse/) provides access to full exception details, including the stack-trace. ServicePulse offers advanced debugging capabilities, providing additional information like exception details as well as visualizing the flow of messages. They also provide `retry` functionality, which sends a failed message from the error queue back to the originating endpoint for re-processing. For more details on how to retry a message using ServicePulse, see [Failed Message Monitoring in ServicePulse](/servicepulse/intro-failed-messages.md). To retry a message using ServicePulse, see [Retrying Failed Messages in ServicePulse](/servicepulse/intro-failed-message-retries.md).
 
-If ServicePulse and ServiceInsight are not available in the environment, the message retry functionality can be performed using the native management tools appropriate for the selected transport:
+If ServicePulse is not available in the environment, the message retry functionality can be performed using the native management tools appropriate for the selected transport:
 
  * [MSMQ Scripting](/transports/msmq/operations-scripting.md)
  * [RabbitMQ Scripting](/transports/rabbitmq/operations-scripting.md)

diff --git a/nservicebus/sagas/saga-audit.md b/nservicebus/sagas/saga-audit.md
@@ -1,9 +1,9 @@
 ---
 title: SagaAudit Plugin
-summary: For visualizing and debugging sagas with ServiceInsight
+summary: For visualizing and debugging sagas with ServicePulse
 component: SagaAudit
 versions: 'SagaAudit:*'
-reviewed: 2025-12-19
+reviewed: 2026-01-05
 redirects:
  - servicecontrol/plugins/saga-audit
 ---
@@ -16,11 +16,11 @@ redirects:
 > [!WARNING]
 > This plugin will result in an increase in the load placed on ServiceControl and the endpoint it is installed in. Make sure the environment is prepared for the increased load. Consider [scaling out audit processing](/servicecontrol/servicecontrol-instances/remotes.md) if necessary.
 
-The SagaAudit plugin enables the Saga View feature in [ServicePulse](/servicepulse/message-details.md#messages-with-audited-conversation-data-saga-diagram) and [ServiceInsight](/serviceinsight/#the-saga-view).
+The SagaAudit plugin enables the Saga View feature in [ServicePulse](/servicepulse/message-details.md#messages-with-audited-conversation-data-saga-diagram).
 
 ![Saga Diagram View in ServicePulse](/servicepulse/images/saga-diagram-overview.png 'width=800')
 
-It is built specifically to help developers verify saga logic during development. It does this by capturing saga message behavior and changes in saga data/state as the saga is being processed. It then sends this information to a ServiceControl instance set up in the development environment. The information is available in the *Saga* view in ServiceInsight and ServicePulse.
+It is built specifically to help developers verify saga logic during development. It does this by capturing saga message behavior and changes in saga data/state as the saga is being processed. It then sends this information to a ServiceControl instance set up in the development environment. The information is available in the *Saga* view in ServicePulse.
 
 
 > [!NOTE]

diff --git a/nservicebus/upgrades/support-policy.md b/nservicebus/upgrades/support-policy.md
@@ -1,7 +1,7 @@
 ---
 title: Support Policy
 summary: Versions of NServiceBus and component packages that are currently supported
-reviewed: 2023-06-25
+reviewed: 2026-01-05
 related:
  - nservicebus/licensing
  - nservicebus/upgrades/release-policy
@@ -71,13 +71,12 @@ Therefore the recommended approach is to upgrade *one* major version at a time,
 
 ## FAQ
 
-**Does this policy apply to the [ServiceControl](/servicecontrol/), [ServiceInsight](/serviceinsight/), [ServicePulse](/servicepulse/) applications, or [Tools](/nservicebus/tools/)?**
+**Does this policy apply to the [ServiceControl](/servicecontrol/), [ServicePulse](/servicepulse/) applications, or [Tools](/nservicebus/tools/)?**
 
-No, the policy applies only to the supported NServiceBus packages listed on the [NServiceBus Packages Supported Versions](supported-versions.md) page. ServiceControl, ServicePulse and ServiceInsight are governed by their own support policy, linked below.
+No, the policy applies only to the supported NServiceBus packages listed on the [NServiceBus Packages Supported Versions](supported-versions.md) page. ServiceControl and ServicePulse are governed by their own support policy, linked below.
 
 - [ServiceControl support policy](/servicecontrol/upgrades/support-policy.md)
 - [ServicePulse support policy](/servicepulse/support-policy.md)
-- [ServiceInsight support policy](/serviceinsight/support-policy.md)
 
 **Which version of NServiceBus should be used to start a new project?**