Active instance(s) Category
The Nodinite BizTalk Server Monitoring Agent empowers you to monitor BizTalk Server Active Instances across all BizTalk Applications in your group, ensuring operational excellence and rapid issue resolution.
Overview of BizTalk Active Instances monitoring in Nodinite.
- Effortlessly list Active Instances in BizTalk as Nodinite resources ('Active Instance(s)')
- Nodinite mirrors the Application concept, providing a 1:1 mapping with each BizTalk Application.
- Active Instances are grouped by the Category name: Active instance(s).
Filter Active Instances by category for focused monitoring.
Info
All User operations within Nodinite are Log Audited, supporting your security and corporate governance compliance policies.
Understanding BizTalk Server Active Instances
Active Instances in BizTalk Server are running orchestration, messaging, or service instances that are currently being processed by the BizTalk engine. These instances represent real-time business processes in flight—messages being routed, orchestrations executing business logic, and services processing data.
Why Monitoring Active Instances is Critical
Active instances consume valuable system resources:
- Memory and Threads – Each active instance holds memory and thread resources in BizTalk host instances
- Dehydration Risk – Long-running instances may dehydrate to the MessageBox database, impacting performance
- Throttling Triggers – Excessive instances can trigger BizTalk's host throttling mechanism, slowing message processing
- System Stability – Accumulation of instances can lead to host instance crashes or out-of-memory conditions
Types of Active Instances
BizTalk Server Active Instances include:
- Orchestration Instances – Long-running business processes executing orchestration logic
- Messaging Instances – Messages being processed through send ports, receive locations, and pipelines
- Service Instances – Running service instances tied to BizTalk applications
Normal vs. Excessive Accumulation
Some active instances are normal during business hours as messages flow through your integration landscape. The goal of this monitoring is to detect excessive accumulation—when instances build up faster than they complete, indicating:
- Processing bottlenecks or performance degradation
- Backend systems responding slowly or timing out
- Incorrectly configured throttling settings
- Insufficient host instance resources
- Instances stuck in long-running states without progressing
Nodinite continuously evaluates both the count and age of Active Instances, triggering alerts when thresholds are breached or instances remain active too long, enabling proactive intervention before system health degrades.
What are the key features for Monitoring BizTalk Server Active Instances?
Nodinite's Active Instance monitoring combines automated evaluation with immediate remediation capabilities, giving you complete visibility and control over your BizTalk Server integration health:
- Remote Actions – Execute powerful management operations directly from Nodinite without logging into BizTalk Administration Console. Suspend, terminate, or bulk manage instances with a few clicks.
- State Evaluation – Intelligent monitoring continuously evaluates Active Instances against your configured thresholds, triggering Warnings or Errors when instance counts exceed acceptable levels or when instances remain active beyond expected processing times.
- Application-Specific Thresholds – Tailor monitoring sensitivity per BizTalk Application, accommodating different processing patterns and business requirements across your integration landscape.
- Real-Time Visibility – View detailed information about each active instance, including service type, state, host, and processing duration to quickly diagnose bottlenecks.
What to evaluate for BizTalk Active Instances?
The monitoring agent continuously queries the BizTalk MessageBox database to assess Active Instance health across all applications in your BizTalk Group. Nodinite evaluates instance counts against your defined thresholds and assigns one of the following states:
| State | Status | Description | Actions | |
|---|---|---|---|---|
| Unavailable | Resource not available | Evaluation of 'Active Instances' is not possible due to network or security issues | Review prerequisites | |
| Error | Error threshold is breached | More Active Instances exist than allowed by the Error threshold | Edit thresholds Manage Active Instances Suspend all | |
| Warning | Warning threshold is breached | More Active Instances exist than allowed by the Warning threshold | Edit thresholds Manage Active Instances Suspend all | |
| ✅ | OK | Within user-defined thresholds | Number of Active Instances is within user-defined thresholds | Edit thresholds Manage Active Instances Suspend all |
Tip
The Nodinite Administrator can reconfigure the evaluated state using the Expected State feature on the Resource within Nodinite. For example, you might set an integration with known high instance counts during batch processing windows to expect a Warning state as normal.
Actions
When Active Instances accumulate or remain in active state too long, immediate action is often required to prevent system degradation. Nodinite provides powerful Remote Actions that enable you to manage BizTalk instances directly from the monitoring interface—no need to switch to BizTalk Administration Console or connect via Remote Desktop.
These actions give operations teams the ability to respond to alerts instantly, reducing Mean Time To Resolution (MTTR) for integration incidents. All actions are audit logged for compliance and troubleshooting.
Available Actions for Active Instances
Unlock the following Remote Actions for the Active instance(s) Category:
List of available Remote Actions.
Edit thresholds
💡 Configure Warning and Error thresholds to match your operational requirements.
Threshold configuration is the foundation of effective Active Instance monitoring. Since different BizTalk Applications have vastly different processing patterns—some handle high-volume messaging with hundreds of concurrent instances, while others process occasional long-running orchestrations—Nodinite allows you to define thresholds both globally (default for all applications) and per-application (override for specific applications).
When to adjust thresholds:
- After deploying new integrations with different throughput characteristics
- When batch processing windows cause predictable instance spikes
- Following infrastructure changes (new servers, increased resources)
- To reduce alert noise from applications with naturally high instance counts
- When historical data reveals consistent patterns requiring baseline adjustments
Thresholds can be configured through the Actions menu or via Remote Configuration for bulk management.
Specific to BizTalk Application
Application-specific thresholds override the global default, allowing you to fine-tune monitoring sensitivity for each integration. This is particularly valuable in mixed environments where some applications process high volumes (e.g., EDI messaging systems) while others run infrequent, long-duration orchestrations (e.g., complex approval workflows).
To configure thresholds specific to a BizTalk Application, select the application from the list and click on the 'Edit thresholds' action.
The Edit thresholds action in the Actions menu.
Configure Warning and Error thresholds for Active Instances.
You also use the Remote Configuration to manage Active Instances. Each specific entry exist by the name of the BizTalk Application.
Example: Manage Active Instances using the Remote Configuration.
Manage Active Instances
When alerts indicate excessive Active Instances, the Manage Active Instances dialog provides a detailed operational view of all running instances within the selected BizTalk Application. This interface replaces the need to use BizTalk Administration Console's Group Hub page, offering faster access and integrated management capabilities.
What you can see:
- Service instance details (service name, service type, instance ID)
- Current instance state and processing host
- Start time and duration (identify long-running instances)
- Error information (for suspended instances)
From this view, you can take targeted actions on individual instances or select multiple instances for bulk operations. This is particularly useful when troubleshooting specific orchestrations or cleaning up instances related to a particular failed backend system.
The Manage Active Instances action in the Actions menu.
Detailed view of Active Instances with management options.
Available actions for managing individual Active Instances.
Suspend
Suspending an Active Instance pauses its processing without losing message data, allowing you to temporarily halt instances while investigating issues or waiting for dependent systems to recover. Suspended instances can later be resumed from BizTalk Administration Console once the underlying issue is resolved.
Common scenarios for suspending instances:
- Backend system is temporarily unavailable (database, web service, file share)
- Orchestration logic errors require code fixes before resuming processing
- Message contains invalid data requiring manual correction
- Preventing further processing during incident investigation
- Throttling message flow during system maintenance windows
For bulk suspension of all instances, use the Suspend all action instead.
Suspend action available in the instance management menu.
Confirmation dialog for suspending an Active Instance.
Terminate
Terminating an Active Instance permanently removes it from BizTalk Server, discarding any in-flight message data. This is a destructive operation that should only be used when instances cannot be successfully processed or when messages are no longer relevant.
When to terminate instances:
- Test messages sent to production environment by mistake
- Duplicate instances caused by application errors
- Instances stuck in infinite loops or unrecoverable error states
- Poison messages that repeatedly fail and cannot be corrected
- Cleaning up instances after decommissioning an integration
Warning
Termination is permanent and cannot be undone. Messages in terminated instances are lost. Consider suspending instances first if message data may be needed for troubleshooting or recovery.
Tip
For terminated instances related to business-critical data, ensure the source system can resend messages or that message content has been logged via Nodinite before terminating.
Terminate action available in the instance management menu.
Confirmation dialog for terminating an Active Instance.
Suspend all
The Suspend All action provides emergency bulk control when an entire BizTalk Application needs to be paused. This is typically used during critical incidents where continuing to process instances would worsen the situation or cause data integrity issues.
Emergency scenarios requiring Suspend All:
- Backend system failure – Database server crashed, suspend all instances attempting to write to that system
- Data quality issues – Source system sending corrupt data, suspend processing until corrected
- Deployment rollback – Critical bug discovered post-deployment, halt processing during emergency rollback
- Infrastructure maintenance – Unplanned maintenance on dependent systems (network storage, authentication servers)
- Security incident – Suspicious activity detected, freeze processing for forensic investigation
To suspend all Active Instances, select the 'Suspend all' menu item in the Actions button.
Warning
Suspending all instances stops message flow for the entire BizTalk Application. Coordinate with business stakeholders before using this action during business hours, as it will halt integration processing until instances are manually resumed.
For selective suspension of specific instances, use the Manage Active Instances action instead.
The Suspend All Action Button menu item.
A confirmation dialog ensures you intend to suspend all Active Instances, preventing accidental actions.
Example of the confirmation modal for suspending all Active Instances.
Next Step
Related Topics
Nodinite BizTalk Server Monitoring Agent
Administration
Monitoring Agents
Add or manage a Monitoring Agent Configuration