Mirth Connect writes several distinct logs, not one combined file: mirth.log covers channel-level activity and script errors, wrapper.log covers service startup and JVM-level failures, channels can have their own dedicated log when enabled, and the Administrator dashboard shows live status that isn't persisted. Read logs effectively by searching for "ERROR" and "Caused by" first, matching timestamps to the incident window, temporarily raising verbosity for intermittent issues, and using grep or a log viewer for large files. Prevent logs from becoming a bottleneck with rotation, a retention policy, and turning debug logging back off after diagnosis.
Quick answer
Mirth Connect log file locations trip people up constantly during troubleshooting, since the platform writes to more than one file and each covers a different layer — mirth.log for application and channel activity, wrapper.logfor the service and JVM itself. Knowing which file actually contains the error you're chasing, and how to search it efficiently, turns a slow scroll through thousands of lines into a search that takes seconds.
Below is where each log lives, what it actually records, and how to read them without wading through noise. Our free Mirth Health Check can review your logs directly for you — part of the Mirth Connect support work we do for US healthcare teams.
What Log Files Does Mirth Connect Actually Produce?
Mirth writes several distinct logs rather than a single combined file, and each one is scoped to a different part of the system, which is exactly why searching the wrong file for a given problem wastes time before you even start troubleshooting the real issue underneath it.
mirth.log — General Application and Channel Errors
This is the primary log for channel-level activity, transformer and filter script errors, and most exceptions thrown while processing messages. It's almost always the first file to check for a specific message-processing failure.
wrapper.log — Service Startup and JVM-Level Failures
This log covers the service wrapper itself — startup, shutdown, and JVM-level failures like out-of-memory errors or a server that won't start at all. It's the file to check when Mirth won't even come up.
Channel-Specific Logs When Enabled Per Channel
Individual channels can be configured to write their own dedicated log file, separate from the shared mirth.log, which is useful for isolating a single noisy or high-volume channel without wading through unrelated entries.
Dashboard Status vs. Persisted Log Files
The Administrator dashboard shows live connector status and recent events, but this isn't the same as a persisted log file — dashboard information disappears on restart, while the actual log files on disk retain history.
How to Read Mirth's Logs Effectively
Reading a large log file line by line is slow and unreliable, so the goal is narrowing down to the relevant section quickly using the tools already available rather than scrolling manually through thousands of entries by hand.
Search for "ERROR" and "Caused by" First
Searching directly for the literal strings ERROR and Caused by:finds the actual failure and its root exception far faster than scanning surrounding informational log lines that don't matter for diagnosis.
Match Timestamps to When the Issue Occurred
Narrow your search to the specific time window when the problem was reported, since a large production log can span days or weeks and matching timestamps quickly rules out everything unrelated to the incident.
Increase Log Verbosity Temporarily for Deeper Detail
If the default log level isn't capturing enough detail to diagnose an intermittent issue, temporarily raise it to debug level, reproduce the problem, then return it to its normal level to avoid excessive log growth.
Use grep or a Log Viewer for Large Log Files
Command-line tools like grep or a dedicated log viewer handle multi-gigabyte files far better than a text editor, letting you filter by keyword, timestamp, or log level without loading the entire file into memory.
How to Prevent Logs From Becoming a Bottleneck
Logs that grow unchecked eventually slow down the very troubleshooting they're meant to support, and can consume enough disk space to cause other, entirely separate problems from whatever you were originally investigating.
Configure Log Rotation in log4j2.properties
Set up rotation rules so log files roll over at a defined size or interval rather than growing indefinitely, keeping any single file small enough to search and open without performance problems.
Set a Retention Policy for Old Log Files
Decide how long rotated log files should be kept before deletion, balancing the need for historical troubleshooting data against the disk space those accumulated files consume over months of operation.
Avoid Leaving Debug-Level Logging On in Production
Debug-level logging generates far more volume than normal operation needs, so return it to its standard level once a specific issue is diagnosed rather than leaving it enabled indefinitely by accident.
Archive Logs Before Major Upgrades
Copy current logs to a separate location before a version upgrade or major configuration change, so you retain a clean reference point for comparing behavior before and after the change if something goes wrong.
When to call for help
If you've found the error in the right log but the root cause still isn't clear, it's often because the relevant context is spread across mirth.log and wrapper.log at slightly different timestamps. Our free Mirth Connect health check reviews your logs directly as part of the standard diagnostic.
Have the exact error text? Send us the log, or check pricing for ongoing support plans.
Chasing a specific error through the logs right now? Free Mirth health check — a written 12-point audit report in 48 hours, no cost.