Dehydrated Orchestration Instance(s) Category
The Nodinite BizTalk Server Monitoring Agent empowers you to monitor BizTalk Server Dehydrated Orchestration Instances across all BizTalk Applications with Orchestrations in your group.
- Effortlessly list Dehydrated Orchestration Instances in BizTalk as Nodinite Resources (Resource name: 'Dehydrated Orchestration Instance(s)').
- Nodinite mirrors the Application concept, providing a 1:1 mapping with each BizTalk Application.
- Dehydrated Orchestration Instances are grouped by the Category Dehydrated Orchestration Instance(s).
- This category appears only for BizTalk Applications with Orchestrations.
List of BizTalk Applications and their Dehydrated Orchestration Instance(s) in Monitoring.
- This category appears only for BizTalk Applications with Orchestrations.
Tip
All User operations within Nodinite are Log Audited, supporting your security and corporate governance compliance policies.
Understanding BizTalk Server Dehydration
Dehydration is BizTalk Server's mechanism for optimizing memory usage during long-running orchestrations. When an orchestration waits for an external event—such as a delayed message, a correlation timeout, or a specific time delay—BizTalk dehydrates the instance by serializing its state to the MessageBox database and removing it from memory. When the awaited event occurs, BizTalk rehydrates the instance back into memory to continue processing.
Why Monitoring Dehydrated Instances is Critical
While dehydration is a normal and beneficial BizTalk feature, excessive or prolonged dehydration signals potential issues:
- Database Pressure – Each dehydrated instance stores state data in the MessageBox, consuming database storage and I/O resources
- Stuck Workflows – Orchestrations waiting indefinitely for messages that may never arrive, indicating correlation mismatches or upstream failures
- Rehydration Overhead – Mass rehydration of thousands of instances can cause performance spikes and thread exhaustion
- Business Process Delays – Long-running approval workflows or batch processes stuck waiting, delaying business outcomes
- Correlation Issues – Dehydrated instances waiting for correlated messages that were sent to wrong contexts or failed routing
Normal vs. Problematic Dehydration
Dehydration is expected and healthy for orchestrations designed with:
- Delay shapes – Orchestrations waiting hours or days before next action (e.g., SLA escalations, scheduled batch processing)
- Long-running correlations – Order processing workflows waiting for customer approvals or external partner responses
- Listen shapes with timeouts – Orchestrations waiting for alternate message paths with multi-day timeouts
Dehydration becomes problematic when:
- Instance counts grow unbounded, indicating messages never arriving to complete workflows
- Instances remain dehydrated for weeks or months beyond expected business timelines
- Dehydrated instances accumulate faster than they rehydrate and complete
- Database size grows excessively due to orphaned orchestration state data
- Rehydration storms cause host instance performance degradation
Nodinite evaluates both count-based and time-based thresholds, alerting when dehydrated instances exceed acceptable levels or remain waiting beyond expected durations. This dual evaluation enables detection of both mass dehydration events (correlation failures) and individual stuck instances (timeout misconfiguration).
Key Features for Monitoring BizTalk Server Dehydrated Orchestration Instances
Nodinite's Dehydrated Instance monitoring provides dual-threshold evaluation combined with direct management capabilities, giving you complete visibility into long-running orchestration health:
- Remote Actions – Manage dehydrated instances without BizTalk Administration Console access. Suspend, terminate, or bulk manage stuck orchestrations directly from monitoring alerts.
- Dual-Threshold Evaluation – Intelligent monitoring using both count-based (how many instances are dehydrated) and time-based (how long instances have been waiting) thresholds to detect different failure patterns.
- Application-Specific Configuration – Tailor threshold settings per BizTalk Application to accommodate different orchestration patterns—short-lived vs. long-running workflows.
- Orchestration-Focused Monitoring – Specifically targets orchestration instances with serialized state in the MessageBox, excluding simple messaging instances.
- Detailed Instance Information – View each dehydrated instance with service name, host, dehydration timestamp, and correlation details for rapid troubleshooting.
What is evaluated for BizTalk Dehydrated Orchestration Instances?
The monitoring agent continuously queries the BizTalk MessageBox database to assess dehydrated orchestration health across all applications with orchestrations. Nodinite evaluates instances against both count and time thresholds, providing multi-dimensional health assessment:
| State | Status | Description | Actions | |
|---|---|---|---|---|
| Unavailable | Resource not available | Evaluation of 'BizTalk Dehydrated Orchestration Instances' is not possible due to network or security issues | Review prerequisites | |
| Error | Error threshold is breached | More Dehydrated Orchestration Instances exist than allowed by the Error threshold | Edit thresholds Manage Dehydrated Instances Suspend all | |
| Warning | Warning threshold is breached | More Dehydrated Orchestration Instances exist than allowed by the Warning threshold | Edit thresholds Manage Dehydrated Instances Suspend all | |
| OK | Within user-defined thresholds | Number of Dehydrated Orchestration Instances is within user-defined thresholds | Edit thresholds Manage Dehydrated Instances Suspend all |
Tip
The evaluated state can be reconfigured using the Expected State feature on every Resource within Nodinite. For example, orchestrations with intentionally long delays (e.g., 30-day invoice payment workflows) can expect Warning states as normal during dehydration periods.
Remote Actions
When dehydrated orchestrations accumulate beyond thresholds or remain waiting longer than expected, immediate intervention prevents database bloat and identifies correlation failures. Nodinite provides powerful Remote Actions that enable operations teams to manage orchestrations directly from the monitoring interface—no RDP sessions to BizTalk servers or Group Hub page navigation required.
These actions accelerate incident response and enable proactive cleanup of orphaned orchestrations before they impact system performance. All actions are audit logged for compliance tracking.
Available Actions for Dehydrated Instances
Unlock the following Remote Actions for the Dehydrated Orchestration Instance(s) Category:
List of available Remote Actions.
Manage Dehydrated Orchestration Instances
When alerts indicate excessive dehydrated instances or instances waiting beyond expected timeframes, the Manage Dehydrated Orchestration Instances dialog provides comprehensive visibility into all waiting orchestrations within the selected BizTalk Application. This interface eliminates the need to navigate BizTalk Administration Console's Group Hub page, providing faster diagnostics and integrated remediation.
What you can see:
- Orchestration service details – Service name, service type, instance ID, correlation ID
- Dehydration timestamp – When instance was dehydrated (critical for time-based alerting)
- Processing host – Which host instance owns the orchestration
- Correlation state – Subscription details showing what message the instance is waiting for
- Orchestration state – Internal state information for advanced troubleshooting
When to use this view:
- Correlation troubleshooting – Identify which messages orchestrations are waiting for that never arrived
- Timeout investigation – Find instances dehydrated longer than business process timelines
- Pattern analysis – Identify common orchestration types stuck waiting (indicates systemic issues)
- Cleanup operations – Bulk terminate orphaned instances from cancelled business transactions
- Performance forensics – Investigate what caused mass dehydration events
To access the management interface, click the Action button and select the Manage Dehydrated Orchestration Instances menu item:
Action button menu with the 'Manage Dehydrated Orchestration Instances' menu item.
The modal displays comprehensive details for all dehydrated instances:
List of Dehydrated Orchestration Instances with service details and timestamps.
From this view, apply targeted actions to single or multiple instances using the Actions and With selected buttons:
Actions available for selected Dehydrated Orchestration Instances.
Available actions:
Actions available for selected Dehydrated Orchestration Instances.
Suspend
Suspending a dehydrated orchestration changes its state from "Dehydrated" to "Suspended (resumable)", preventing automatic rehydration when the awaited message or timeout arrives. This is useful for preventing orchestrations from continuing when you know the expected messages will never arrive or when correlation issues need investigation.
Common scenarios for suspending dehydrated orchestrations:
- Correlation failures – Messages sent with wrong context or routing properties, preventing correlation—suspend instances waiting for messages that will never match
- Cancelled business transactions – Customer orders cancelled, refund requests withdrawn, approvals no longer needed—suspend waiting orchestrations to prevent eventual timeout errors
- Testing/debugging correlation issues – Suspend instances to analyze subscription details and correlation properties before terminating
- Postponing cleanup – Temporarily suspend instances pending business confirmation before permanent termination
- Upstream system failures – Partner system decommissioned or URL changed, messages no longer being sent—suspend orchestrations awaiting those messages
- Preventing rehydration storms – During performance issues, suspend mass dehydrated instances to prevent simultaneous rehydration
Note
Suspending a dehydrated instance does not delete it—the orchestration state remains in the MessageBox. Suspended instances consume database storage and must be manually resumed or terminated later. For permanent cleanup, use Terminate instead.
For bulk suspension of all dehydrated instances (e.g., after catastrophic correlation failure), use the Suspend all action.
Suspend action available in the instance management menu.
Click the Suspend menu item in the Actions button for single instances, or check multiple rows and use the 'With selected' dropdown:
Confirmation dialog for suspending dehydrated orchestration instances.
Terminate
Terminating a dehydrated orchestration permanently removes the instance and its serialized state from the MessageBox database. This is a destructive operation that ends the business process represented by the orchestration—use only when you are certain the workflow should not complete.
When to terminate dehydrated orchestrations:
- Orphaned instances – Business transactions cancelled, approvals withdrawn, orders voided—orchestrations waiting for events that business logic dictates will never occur
- Correlation design errors – Test orchestrations deployed to production with incorrect correlation configuration
- Obsolete workflows – Orchestrations from decommissioned business processes waiting indefinitely
- Database cleanup – Instances dehydrated for months/years beyond business retention policies
- Migration scenarios – Clearing out old instances before BizTalk version upgrades or application redeployment
- Stuck timeout scenarios – Orchestrations with multi-year timeout delays configured incorrectly (e.g., 999-day delay shapes)
Warning
Termination is permanent and unrecoverable. The orchestration will never complete its business process. Any compensation logic, exception handlers, or downstream actions in the workflow will never execute. Ensure the business impact is acceptable before terminating.
Caution
For orchestrations managing critical business data (orders, payments, approvals), verify that:
- Business stakeholders have confirmed transaction cancellation
- Orchestration state/variables have been logged or exported if needed for audit
- Downstream systems won't be waiting for messages this orchestration would have sent
- Compensation or rollback actions have been manually executed if necessary
Alternative to termination: If you're unsure whether the orchestration should complete, suspend it first for investigation. Suspended instances can be manually resumed later or analyzed for correlation troubleshooting.
Terminate action available in the instance management menu.
Click the Terminate menu item in the Actions button for single instances, or check multiple rows and use the 'With selected' dropdown:
Confirmation dialog for terminating dehydrated orchestration instances.
Edit thresholds
Dehydrated orchestration monitoring uses dual-threshold evaluation—both count-based and time-based—to detect different failure patterns. This comprehensive approach enables detection of mass dehydration events (count spikes indicating correlation failures) and individual stuck instances (time-based indicating workflow timeouts).
When to adjust thresholds:
Count thresholds:
- After deploying long-running approval workflows with predictable dehydration patterns
- When batch processing creates expected spikes in dehydrated instances (e.g., nightly EDI processing)
- Following orchestration design changes that alter typical in-flight instance counts
- To accommodate seasonal business fluctuations (holiday order volumes, month-end financial processing)
Time thresholds:
- For orchestrations with intentional long delays (30-day invoice payment holds, 7-day approval escalations)
- When business process SLAs dictate acceptable wait times (adjust time thresholds to match SLA + buffer)
- After discovering orchestrations designed with multi-day Listen shape timeouts
- To reduce alert noise from expected long-running correlation workflows
Application-specific vs. global:
- Set global defaults for typical messaging-heavy applications
- Configure per-application overrides for orchestrations with unique patterns (long-running BPM workflows vs. short correlation scenarios)
Thresholds can be managed through the Actions menu or via [Remote Configuration][] for bulk adjustments across multiple applications.
To manage the Dehydrated Orchestration Instance(s) threshold for the selected BizTalk Server Application, press the Action button and select the Edit thresholds menu item:
Action button menu with the Edit thresholds option.
The modal allows you to configure both time-based and count-based alert thresholds:
Dual-threshold configuration for comprehensive dehydrated instance monitoring.
Time-based evaluation
Time-based evaluation detects orchestrations stuck in dehydration longer than expected, indicating potential correlation mismatches, timeout misconfiguration, or orphaned workflows. Nodinite continuously tracks how long each instance has been dehydrated, triggering alerts when durations exceed configured thresholds.
Time-based evaluation is always active. If your orchestrations intentionally dehydrate for extended periods (legitimate business process delays), set thresholds long enough to avoid false alerts, or use the Expected State feature to accept Warning states as normal.
Example time threshold configurations:
- Short-correlation workflows (order confirmations, API responses): Warning 15 minutes, Error 1 hour
- Approval orchestrations (manager approval with 2-day SLA): Warning 3 days, Error 7 days
- Scheduled batch processing (nightly file pickup with Delay shapes): Warning 25 hours, Error 48 hours
- Long-running BPM (invoice payment with 30-day terms): Warning 35 days, Error 60 days
- Multi-stage approvals (procurement with 5-day escalation): Warning 6 days, Error 10 days
Tip
Set Warning thresholds slightly above normal business process timelines to detect anomalies early. Set Error thresholds to indicate "workflow definitely stuck and needs investigation."
| State | Name | Data Type | Description |
|---|---|---|---|
| Warning TimeSpan | Timespan 00:13:37 (13 minutes 37 seconds) | If any dehydrated instance has been waiting longer than this timespan, a Warning alert is raised. Format: days.hours:minutes:seconds (e.g., 7.12:30:59 = 7 days, 12 hours, 30 minutes, 59 seconds) | |
| Error TimeSpan | Timespan 01:10:00 (1 hour 10 minutes) | If any dehydrated instance has been waiting longer than this timespan, an Error alert is raised. Format: days.hours:minutes:seconds (e.g., 30.00:00:00 = 30 days) |
Count-based evaluation
Count-based evaluation detects mass accumulation of dehydrated instances, indicating systemic issues such as correlation failures, routing problems, or upstream system outages. Sudden spikes in dehydrated instance counts often signal that orchestrations are not receiving expected messages.
How to set count thresholds:
- Establish baseline – Monitor normal dehydrated instance counts during typical business operations (daily, weekly, monthly patterns)
- Add headroom – Set Warning threshold 20-30% above normal peak counts to allow for business fluctuations
- Define critical level – Set Error threshold at the point where database or rehydration performance becomes concerning
- Consider batch patterns – For nightly batch processing, thresholds should accommodate temporary spikes during processing windows
Example count threshold configurations:
- Low-volume orchestrations (manual approvals, infrequent workflows): Warning 50, Error 100
- Medium-volume orchestrations (hourly batch processing, moderate correlation): Warning 500, Error 1000
- High-volume orchestrations (EDI workflows, high-throughput integrations): Warning 2000, Error 5000
- Long-running BPM workflows (30-day processes with 1000s of concurrent instances): Warning 10000, Error 20000
Warning
Count thresholds that are too low create alert fatigue from false positives. Thresholds too high allow severe correlation failures to go undetected. Review and adjust based on historical patterns.
Tip
After setting thresholds, monitor for 1-2 weeks and adjust based on actual alert patterns. Use Nodinite historical data to identify typical peaks and valleys.
| State | Name | Data Type | Description |
|---|---|---|---|
| Warning Count | integer | If the total number of dehydrated instances exceeds this value, a Warning alert is raised. Set slightly above normal peak counts to detect early accumulation. | |
| Error Count | integer | If the total number of dehydrated instances exceeds this value, an Error alert is raised. Set at critical levels where database or performance issues become likely. |
Suspend all
The Suspend All action provides emergency bulk control when mass correlation failures or systemic issues cause excessive dehydrated instance accumulation. This action changes all dehydrated instances for the selected BizTalk Application from "Dehydrated" to "Suspended (resumable)", preventing automatic rehydration and halting workflow progression.
Emergency scenarios requiring Suspend All for dehydrated orchestrations:
- Mass correlation failure – Routing property changes or context property errors causing hundreds/thousands of orchestrations to wait for messages that will never correlate
- Upstream system decommissioned – Partner web service URL changed or retired, orchestrations waiting indefinitely for responses that will never arrive
- Rehydration storm prevention – Thousands of instances waiting for same correlation token—if sent, mass simultaneous rehydration would crash host instances
- MessageBox performance crisis – Database under extreme load, prevent additional rehydration overhead while investigating
- Orchestration deployment bug – Critical correlation logic error discovered post-deployment, suspend all in-flight instances pending emergency fix
- Test data in production – Accidentally deployed test orchestrations to production environment, suspend all before cleanup
- Business process cancellation – Entire category of business transactions cancelled (product line discontinued, service terminated), suspend all related workflows
Caution
Suspending all dehydrated orchestrations halts all in-flight business processes for that BizTalk Application. This action affects every waiting orchestration—approval workflows, payment processing, order fulfillment, partner integration, etc.
Before using Suspend All:
- Confirm business impact – Understand which business processes will be frozen
- Coordinate with stakeholders – Notify business owners that workflows are being paused
- Plan recovery strategy – Decide whether instances will be terminated (business cancelled) or eventually resumed (after correlation fix)
- Document incident – Record why mass suspension was necessary for post-incident review
- Prepare communication – Business users may ask why approvals/processes are not completing
After Suspend All:
- Suspended instances remain in the MessageBox consuming database storage
- Instances will not automatically resume—manual intervention required
- Options: Terminate permanently, or resume from BizTalk Administration Console after fixing root cause
- Consider using Manage Dehydrated Instances for selective termination of specific orchestration types
To suspend all dehydrated instances, click the 'Suspend all' menu item in the Actions button.
The Suspend All Action Button menu item.
A confirmation dialog ensures you intend to suspend all dehydrated instances, preventing accidental bulk operations:
Confirmation modal for suspending all dehydrated orchestration instances.
Next Step
Related Topics
Administration
Monitoring Agents
Add or manage a Monitoring Agent Configuration