- 6 minutes to read

Host Instance category

Understanding Host Instances Monitoring

Host Instances are the actual worker processes (BTSNTSvc.exe) that execute all BizTalk Server operations. Every Receive Location, Send Port, and Orchestration runs inside a Host Instance. If a Host Instance is stopped, the entire integration platform stops processing—no messages received, no orchestrations executed, no messages delivered. This is the single most critical component to monitor in BizTalk Server.

Why Host Instances monitoring is absolutely critical:

Complete platform failure – A stopped Host Instance means zero processing for all artifacts assigned to that host. If your "ReceiveHost" instance stops, all Receive Locations stop accepting messages. If "ProcessingHost" stops, all orchestrations freeze mid-execution. If "SendHost" stops, zero messages are delivered.
Silent catastrophic failures – BizTalk doesn't automatically alert when someone stops a Host Instance via BizTalk Admin Console or Services MMC. The entire platform can be down for hours before anyone notices (typically when partners start calling).
Suspended instance accumulation – Stopped Host Instances cause messages to pile up in the MessageBox. When the instance restarts, thousands of dehydrated orchestrations and queued messages create rehydration storms that crash the server.
SLA violations at scale – Unlike a single stopped Send Port (which affects one integration), a stopped Host Instance affects every integration assigned to that host. Orders, invoices, notifications, API calls—all fail simultaneously.
Financial impact multiplied – One stopped Host Instance can halt hundreds of integrations. Every hour of downtime = lost orders, failed compliance filings, partner SLA penalties, and emergency escalation costs.
Tracking data loss – Stopped Tracking Host means BizTalk stops writing tracking data to DTA database. Message bodies, orchestration debug traces, and BAM events are lost forever (cannot be recovered after restart).
Cluster failover issues – In clustered environments, Host Instances must be configured correctly or automatic failover won't work. A misconfigured cluster means production goes down during hardware failure.

Common scenarios requiring Host Instance monitoring:

Accidental stops – Administrator stops instance for maintenance and forgets to restart; entire host's workload ceases
Service crashes – Memory leaks, unhandled exceptions, or resource exhaustion cause BTSNTSvc.exe to crash; without monitoring, instance stays down until manual intervention
Throttling issues – Host Instance enters throttling state due to MessageBox database latency, high memory usage, or thread starvation; performance degrades to near-zero throughput
Tracking host missing – No dedicated tracking host instance means tracking data isn't persisted; compliance and debugging impossible
Host instance distribution gaps – Some BizTalk servers missing required host instances; workload imbalance causes some servers to be idle while others are overloaded
Cluster configuration errors – Host marked for clustering but Windows cluster resource not configured; failover doesn't occur during outages
Resource exhaustion – Host Instance consumes 100% CPU or memory but doesn't crash; processing slows to crawl without obvious errors

Host Instance types and their critical roles:

Receive Hosts – Execute Receive Locations and adapters; if stopped, zero inbound messages accepted (orders, files, API calls rejected)
Processing Hosts – Execute orchestrations; if stopped, all business logic workflows freeze mid-execution
Send Hosts – Execute Send Ports and adapters; if stopped, zero outbound messages delivered (invoices, notifications, API responses never sent)
Tracking Hosts – Write tracking data to DTA database; if stopped, all audit trails and debugging data lost
Isolated Hosts – Execute in-process adapters (HTTP, SOAP); if stopped, web service endpoints return errors

Nodinite BizTalk Server Monitoring Agent monitors BizTalk host instances across all servers in your BizTalk group. The monitoring agent automatically detects and manages new or removed hosts and host instances, ensuring your environment stays up to date.

Nodinite automatically lists all Host instances as resources, where the name is the Host-name together with the configured server name, for example, 'SendHost32@SEBTPRD01'.
Host instances belong to the BizTalk Group Name as their Application (not a specific BizTalk application).
Host instances are further grouped by the following Category: Host Instance.

Note
Why do Host Instances use the BizTalk Group Name as Application Name?

Host Instances are system-wide resources that serve all BizTalk applications in the environment. They use the BizTalk Group Name (e.g., "BizTalk Group [Server\Instance]") as their Application Name to:

Provide uniqueness when monitoring multiple BizTalk environments (Dev, Test, Prod)

Distinguish system resources from application-specific resources (Send Ports, Orchestrations, etc.)

Enable consistent filtering across all system-wide categories (Group, Host Instances, Health Check, Tracking)

See the Group page for a complete explanation of Application Name usage across BizTalk resource types.

This image shows a Monitor View filtered by the 'Host Instance' category.

What are the key features for Monitoring BizTalk Server Host instances?

Cluster support – Verifies that your hosts are correctly set for a clustered environment
Verify Tracking Host configuration – Alerts if there is not at least one dedicated Tracking host
Host instances exist for host – Alerts if not all host instances exist on each BizTalk Server node
Running host instances – Alerts if a host instance is stopped (and not configured as disabled and/or part of a cluster configuration)
Remote Actions – Supports the execution of remote actions
State Evaluation – Monitors and evaluates the run-time state
Metrics – Provides a Widget with BizTalk group information for use on the Dashboard

What is evaluated for BizTalk host instances?

The table below describes the evaluated states for any host instance:

State	Status	Description	Actions
Unavailable	Resource not available	Evaluation of the 'BizTalk Host Instances' is not possible due to network or security-related problems	Review prerequisites
Error	Stopped and not disabled	A Stopped host instance renders as state 'Error' (if not configured as disabled and/or part of a Windows fail-over cluster resource group)	Start
Error	Invalid tracking host configuration	There must be at least one host/host instance configured for Host Tracking per node in the BizTalk group	Details A BizTalk administrator must manually create dedicated tracking hosts to resolve this matter
Warning	Is throttling	Throttling is above configured thresholds. This behavior is built-in by BizTalk Server design, but may indicate exhausted resources—verify overall performance	Metrics chart: Throttling Metrics
OK	Enabled and running	Host instance is operational, and no other problems are detected	Stop

Tip
You can reconfigure the evaluated state using the Expected State feature on every Resource within Nodinite.

What Remote Actions are available for BizTalk Server?

You can call actions on resources using the Nodinite Web Client tool or programmatically via the Web API. To execute remote actions, some Prerequisites must be satisfied. The user must log on to Nodinite using a Windows Credential and be assigned a Monitor Views with BizTalk Resources where Remote Actions are allowed. See Add or manage Monitor View for more details.

Start
Stop
Restart
Details – Get the details

This image shows the available actions from the Action button menu for a BizTalk host instance.

Metrics chart: What Metrics/Statistics are available for BizTalk Server?

Metrics chart: Host Instance Throttling

You can view individual and group (all instances combined) Throttling Metrics using the Metrics graphs, either as a Remote Action or as a Widget on the Dashboard.

This image shows the throttling chart for BizTalk Host Instances.