- 4 minutes to read

What are Suspended Instances in Microsoft BizTalk Server?

Get alerts and manage suspended instances in BizTalk, grouped by application name, with Nodinite's intuitive monitoring and self-service features.

✅ Empower yourself with Nodinite – You don't need to be a BizTalk Server Administrator to resolve issues with suspended instances. Nodinite makes it easy and secure.
✅ Avoid the blame game – All sensitive operations are recorded in the Audit Log.
✅ Solve problems swiftly – Nodinite features Remote Actions to help you manage suspended instances efficiently.
✅ Statistics help you improve – Nodinite provides built-in reports to help you optimize your business with actionable insights.

Understanding Suspended Instances

As a BizTalk professional, you must proactively manage suspended instances. When BizTalk encounters an error it cannot automatically recover from—such as a routing failure (no matching subscriber), schema validation error, map exception, or transmission failure—the instance suspends to prevent data loss.

Why this matters to your business:

Lost revenue – Suspended orders, invoices, or payments represent incomplete business transactions
SLA violations – Partners and customers expect timely processing; suspended instances cause delays
Performance degradation – Thousands of suspended instances consume database space and slow the MessageBox
Compliance risk – Unprocessed regulatory filings or audit messages create legal exposure
Hidden problems – Suspended instances are symptoms of deeper issues (wrong configuration, partner system down, invalid data)

BizTalk creates suspended instances to give you time to investigate and repair the problem without losing the message. The instance preserves the original payload and all context properties, enabling you to fix the root cause, correct the data, and resubmit or resume the transaction.

There are two types of suspended instances:

Suspended instance(s) (resumable)
Suspended instance(s) (not resumable)

Suspended instances for the selected BizTalk Server Application.

Warning
If you do not address your suspended instances, you will experience bad performance and may eventually run out of disk space. Business transaction flows will be interrupted, which is likely bad for your business.

Important
Suspended messages may include sensitive content. Any BizTalk Server Administrator can read (and potentially share) this information without traces when using the BizTalk Server MMC. With Nodinite, you can separate access using Role-based security. For your protection, all sensitive operations are log-audited.

1. Suspended instance(s) (resumable)

Resumable suspended instances occur when BizTalk encounters a recoverable error during message processing. Each instance contains the actual payload (messages) and context properties. You can resume the instance (which creates a new active instance and automatically terminates the old one) or terminate it to discard the message.

Common causes of resumable suspensions:

Transmission failures – Partner endpoint unreachable, network timeout, HTTP 500 errors
Transient errors – Database deadlock, temporary service unavailable, authentication timeout
Retry exhaustion – Send port exhausted all retry attempts after repeated failures
Orchestration exceptions – Unhandled exception in orchestration code, suspended by exception handler
Adapter errors – FTP connection failed, SFTP authentication denied, file share access denied

Resumable instances represent fixable problems. After resolving the root cause (partner system restored, credentials updated, network repaired), you can resume the instances to complete the business transaction.

2. Suspended instance(s) (not resumable)

Not resumable suspended instances occur when BizTalk encounters a non-recoverable error that cannot be fixed by simply reprocessing. These instances exist solely for diagnostic purposes—to help you investigate the root cause. The only option is to terminate them after you've extracted the necessary troubleshooting information.

Common causes of not resumable suspensions:

Routing failures – No subscriber found (no send port or orchestration subscribed to the message)
Schema validation errors – Message body doesn't match expected XML schema structure
Map failures – XSLT transformation error, invalid source data, missing required nodes
Orchestration exceptions – Message type mismatch, correlation violation, persistence failure
Pipeline failures – Disassembler error, property demotion failure, component exception

Not resumable instances represent configuration or data quality problems. You must fix the underlying issue (add subscription, correct schema, repair map, fix source system) before the message can be successfully processed. Often you'll need to resubmit a corrected version of the original message rather than resuming the suspended instance.

Managing suspended instances

With the Nodinite BizTalk Server Monitoring Agent, suspended instances are grouped by BizTalk application name as Resources. They are organized into the following two Categories:

If your Monitor View allows the Remote Actions feature, you can perform the following operations to manage suspended instances (options differ for resumable and not resumable):