Effective Mirth Connect monitoring focuses on channel status and queue size, server resource trends, error rate trends over time, and throughput against expected volume — not every metric available. Configure Mirth's built-in alerts to reach channels your team actually monitors, set thresholds based on real operating ranges instead of defaults, test that alerts actually fire, and document what each one means. Pair Mirth's application-level alerting with external infrastructure monitoring, centralized log aggregation, and periodic review, since Mirth's own alerting can't see problems occurring outside the application itself.
Quick answer
Mirth Connect alerting and monitoring setup is what separates teams who find out about a production issue from a dashboard alert versus teams who find out from an angry phone call after a downstream system has already been affected for hours. Mirth includes built-in alerting capability, but many deployments never configure it beyond the defaults, leaving genuine gaps.
Below is what deserves monitoring in a Mirth deployment, how to configure Mirth's built-in alerts properly, and where external tools fill the gaps Mirth's own monitoring doesn't cover. Our free Mirth Health Check can review your current monitoring setup — part of the Mirth Connect support work we do for US healthcare teams.
What Actually Deserves Monitoring in a Mirth Deployment?
Not every metric deserves equal attention, and effective monitoring focuses on the handful of signals that actually indicate a real problem rather than drowning your team in noise from metrics that rarely matter much at all.
Channel Status and Destination Queue Size
A channel that's stopped, paused, or showing a rapidly growing destination queue is one of the clearest signs something needs attention, and it's usually the first thing worth checking when investigating a reported issue. See our queued messages not sending guide for what a stalled queue looks like.
Server Resource Usage Under Real Load
CPU, memory, and disk usage trends over time reveal capacity problems building gradually, well before they cause an outright crash, giving you time to address resource constraints proactively rather than reactively.
Error Rate Trends Across Channels
Tracking error counts over time, not just in the moment, reveals whether a specific channel's reliability is degrading gradually, which a single point-in-time check would never catch on its own.
Message Throughput Against Expected Volume
Comparing actual message throughput against your normal expected volume catches both unexpected spikes that might strain resources and unexpected drops that might indicate a source system has stopped sending data entirely.
Setting Up Mirth's Built-In Alerts Properly
Mirth's native alerting capability covers real ground once actually configured, but it requires deliberate setup rather than working meaningfully out of the box with no configuration applied at all.
Configure Alert Channels for Your Actual Team
Set up alert delivery to channels your team genuinely monitors, whether email, a messaging platform integration, or another notification method, rather than leaving alerts going to an address nobody actually checks regularly.
Set Meaningful Thresholds, Not Just Defaults
Adjust alert thresholds to match your actual normal operating ranges rather than leaving default values that may be too sensitive or too lax for your specific message volume and typical channel behavior.
Test That Configured Alerts Actually Fire
Deliberately trigger a test condition to confirm alerts actually reach the intended recipients before relying on them in production, since a misconfigured alert that silently never fires is worse than having no alert at all.
Document What Each Alert Means and How to Respond
Pair each configured alert with a brief note on what it means and the first troubleshooting step to take, so whoever receives the alert can act on it immediately without needing to track someone else down first.
Extending Monitoring Beyond Mirth's Own Defaults
Mirth's built-in alerting covers channel-level events well, but a complete monitoring picture often requires tools that see beyond what Mirth itself can report on its own entirely.
Integrate External Monitoring Tools for Infrastructure
Pair Mirth's application-level alerts with infrastructure monitoring tools tracking server health, network connectivity, and database performance, since Mirth's own alerting can't see problems occurring outside the application itself at all.
Aggregate Logs Across Multiple Servers Centrally
For deployments running multiple Mirth servers, a centralized log aggregation tool makes searching across all of them simultaneously far faster than logging into each server individually during an active incident. See our log file locations guide for what to aggregate.
Build Custom Health Check Endpoints Where Needed
For critical channels, consider building a lightweight health check that external monitoring tools can poll regularly, giving you an independent verification layer beyond what Mirth's own internal status reporting provides.
Create Dashboards Stakeholders Outside IT Can Understand
Build a simplified status view for non-technical stakeholders who need visibility into system health without needing to interpret raw Mirth Administrator screens, which weren't designed for a general audience in the first place.
When to call for help
If you're finding out about issues too late, the gap is usually thresholds left on defaults or alerts routed somewhere nobody checks, not a fundamental tooling problem. Our free Mirth Connect health check reviews your monitoring setup as part of the standard diagnostic.
Something specific prompt this? Send us the log, or check pricing for ongoing support plans.
Finding out about issues too late? Free Mirth health check — a written 12-point audit report in 48 hours, no cost.