Mirth Connect Channel Not Processing Messages: Causes and Fixes

Open the channel in the Dashboard and read the message counts by status. The status that's accumulating tells you which stage is failing:

• RECEIVED but not moving — the source accepted the message but processing stalled (often a filter or transformer issue, or the processing thread is blocked).
• FILTERED— the message was intentionally filtered out by your source filter. If that's unexpected, your filter logic is too aggressive.
• QUEUED on the destination— the destination connector can't deliver. This is the most common "not processing" case.
• ERROR — an exception was thrown; open the message and read the error.
• PENDING / sticking at one stage — a thread or resource is blocked.

1. The destination system is unreachable. Queued messages with connection errors almost always mean the downstream host, port, or service is down or blocked. Test connectivity from the Mirth server itself (not your laptop) to the destination host and port. Fix the network path, firewall rule, or restart the downstream listener, then the queue drains on its own.

2. Destination queue is enabled and a poison message is at the head. With queuing on, Mirth retries the first message indefinitely; if message #1 always errors, everything behind it waits. Find the erroring message in the queue, fix or remove it (you can mark it for processing or reprocess after a fix), and the queue resumes.

3. A filter is silently dropping messages. If counts jump to FILTERED, your source or destination filter is returning false for messages you expected to pass. Review the filter rules and the actual message content — a changed field or empty segment can flip a filter.

4. A transformer exception. A script error in a transformer can move messages to ERROR or stop processing. Open the errored message, read the stack trace, and check the line referenced. See our guide to JavaScript and Groovy transformer errors.

5. The channel is paused or the connector is disabled.Confirm both the channel and each connector are actually started, not just deployed. A channel can be "deployed" with a stopped destination.

6. Database or storage problem.If Mirth can't write to its own message-storage database, processing halts. Check the Mirth logs for database connection or disk errors. See Mirth Connect database configuration.

7. Thread pool / max processing threads exhausted. Under load, if all processing threads are blocked on a slow destination, new messages wait. Look for one slow destination holding everything up.

1. Read the Dashboard status counts to locate the failing stage.
2. Open a stuck/errored message and read the exact error.
3. Test the destination's reachability from the Mirth host.
4. Clear or fix the poison message at the head of the queue.
5. Restart the affected connector (not always the whole channel).
6. Confirm the queue drains and counts return to SENT.
7. Add an alert so this condition notifies you next time.

Enable alerting on error and queue-depth thresholds, set sensible queue retry limits with a dead-letter path instead of infinite retries, and monitor destination reachability. Proactive monitoring catches a backing-up queue before a clinician notices missing data — that's exactly what managed support covers.