Mirth Connect Queued Messages Not Sending: Causes and Fix

Mirth Connect queued messages not sending is a status problem rather than a logged exception — the dashboard shows messages sitting in QUEUEDwith the count climbing, but no error is thrown because the destination simply isn't accepting them. It's one of the few Mirth issues you diagnose from the dashboard first and the log second.

Below is why a queue stalls, how to get it moving again, and how to stop it happening silently overnight. Our free Mirth Health Check can confirm whether it's a pause, a downstream outage, or a config issue in minutes — part of the Mirth Connect support work we do for US healthcare teams.

A destination connector queues messages whenever it can't send successfully, and Mirth is designed to hold them rather than drop them on a temporary failure. The queue only clears once the connector can connect and process again, so the real question is always why the destination stopped accepting messages, not why Mirth is queuing them in the first place. Each cause below leaves a slightly different signature in the log and dashboard, worth checking before changing any setting.

Destination Connector Manually Paused

Someone pausing a destination from the dashboard, often during maintenance, is the single most common cause and the easiest to miss. The queue grows exactly as designed, silently, until someone notices or a downstream system asks where its data went.

Downstream Endpoint Unreachable or Down

If the receiving system, database, or API is down, restarting, or unreachable, the destination connector will queue every message it can't deliver. The server log usually shows repeated connection failures at the connector's retry interval during this window.

Reconnect Interval Set Too Long

A destination configured with a long reconnect interval waits far longer between retries than the outage actually lasts, so the queue keeps growing even after the downstream system is back. This is a config gap disguised as a downstream problem.

Queue Thread Count Reduced to Zero

If the destination's thread count has been set to zero, intentionally or by a misconfigured change, messages queue indefinitely with nothing available to process them. This looks identical to a dashboard pause but lives in a different settings tab.

Before changing any setting, check the queue's actual state on the dashboard — paused, running with connection errors, or running but with the downstream simply unreachable — because each of those needs a different fix, and jumping straight to a restart hides which one you were actually dealing with. The fixes below match the four causes above in the same order, so start with whichever matches what the dashboard is showing right now.

Resume the Paused Queue From the Dashboard

If the destination shows as paused, resuming it from the channel's connector controls is enough to start draining the backlog immediately. Confirm who paused it and why before assuming it's safe to resume without checking maintenance notes.

Verify Connectivity to the Downstream Endpoint

Test the actual connection the destination uses — a port check, an API health endpoint, or a database ping — separately from Mirth to confirm whether the endpoint itself is back before expecting the queue to clear on its own.

Adjust the Reconnect Interval and Retry Count

If the queue only cleared long after the downstream system recovered, shorten the reconnect interval so future outages clear faster once the endpoint returns. Balance this against not hammering a fragile downstream system with retries that are too frequent.

Restore the Destination Thread Count

If the thread count was set to zero, either by mistake or during a change that was never reverted, restore it to its normal value and redeploy the channel. The queue drains as soon as threads are available.

A queue that grows silently overnight is a monitoring gap more than a genuine Mirth defect — the software behaved exactly as designed by holding messages instead of dropping them during an outage. The fix is making sure a human finds out about a stalled queue well before it becomes a multi-day backlog that a downstream team notices before you do.

Alert on Queue Size Thresholds

Set an alert, either through Mirth's built-in alerting or an external monitor, that fires when a destination queue crosses a defined size. A threshold based on your normal traffic pattern catches a stall long before it becomes a multi-day backlog.

Monitor Downstream Endpoint Uptime

Health-checking the systems your destinations depend on, independent of Mirth, gives you advance warning that a queue is about to start growing rather than finding out from the queue itself hours later.

Set Retry Limits With Exponential Backoff

Where the connector supports it, use a backoff pattern that retries quickly at first and then spaces out attempts, rather than a fixed interval that either hammers a struggling endpoint or waits too long once it recovers.

Document Manual Pauses So They Aren't Forgotten

Any time a destination is paused for planned maintenance, log it somewhere visible with an expected resume time. A queue paused for a two-hour maintenance window and forgotten is indistinguishable from a real outage two days later.

If you've resumed the queue and confirmed downstream connectivity and it still isn't draining, the cause is usually a reconnect setting or thread configuration that isn't obvious from the dashboard alone. Our free Mirth Connect health checkconfirms exactly what's stalling the queue as part of the standard diagnostic.

Book a Free Health Check →

Have an error accompanying the stall? Send us the log, or check pricing for ongoing support plans.