Watch every engine.One free plugin.
Install the OpenShare Gateway plugin on any Mirth Connect or OIE server and its health appears in the browser: channel state, queues, errors, silence, heap and disk. Alert rules catch the failures that matter, and OpenShare emails you when a server goes quiet. No separate agent, no monitoring subscription, free on the servers you need to get started.
Monitor Mirth Connect where it actually fails.
A channel that stops makes no noise. Messages wait in a queue and nobody downstream knows why. The plugin reports the six signals where engine incidents show up, from inside every engine it is installed on.
Channel state
Started, stopped or paused, for every deployed channel, with each change recorded as it happens.
State change ruleQueues
Queued messages per channel, charted over time, so a backlog shows while the destination is slow and not yet down.
Threshold or rate of changeErrors
Error counts and error rate per channel, measured against the channel’s own recent baseline as well as a fixed line.
Rate of changeSilence
Received counts per channel. A feed that always flows and goes quiet is a failure upstream that nothing on your server will report.
Absence ruleJVM heap and threads
Memory pressure and thread counts per server, as a trend you see before it becomes a stalled engine.
ThresholdDisk and load
Disk use on the engine host and processor load, next to every other server in the fleet.
ThresholdEvery server in one view, even the offline ones.
Mirth monitoring that works one server at a time stops being monitoring around the third server. The fleet page shows every engine with cloud sync turned on, whatever fork or version it runs.
Health at a glance, problems on top.
Summary chips count your servers, how many are online and offline, and the active alerts across all of them, and the offline and alert chips turn amber or red when they are not zero. Each server card shows its version, uptime, heap, disk and load gauges, started channels, and a pulsing badge when it has an active alert. A server that stops reporting turns grey instead of disappearing.
Live channel counts, in the browser.
Received, filtered, queued and sent counts update live for every channel, with the server log underneath. It is the dashboard the Java client gave you, in any browser tab, through the same plugin and the OpenShare Console.
History you can ask questions of.
Open any server for its health cards and a metric explorer. Chart any server or channel metric over the last hour, day, week or 30 days, or a custom range, overlay several at once, and save the views you keep coming back to.
The alert events timeline on the same page keeps every event for that server with a snapshot of the rule as it was when it fired, so you can see why it fired even after the rule changes. One click jumps the chart to that metric at that moment. History lives in the plugin’s own database on each server and syncs up for the fleet view.
Alert rules for the failures that actually happen.
Mirth’s built-in alerts fire on channel errors only, so a stopped channel, a growing queue or a silent feed raises nothing. OpenShare adds the four rule types an engine needs, evaluated on the server every 30 seconds.
- State change
- A channel is in a target state, such as Stopped.
- Threshold
- A metric crosses a fixed line: queue above 100, heap above 85%.
- Rate of change
- A metric climbs fast against its own recent baseline, such as an error spike.
- Absence
- No data arrives in the window: no messages in 30 minutes on a feed that never sleeps.
Built to keep the pager quiet.
- Scope. A rule covers the whole server, chosen channels, or a channel group. Group membership resolves on every cycle, so a channel added to “all ADT feeds” next quarter is covered without editing the rule.
- Severity. Info, Warning or Critical on every rule, color-coded all the way to the email.
- Fire once, resolve once. A rule notifies when it starts firing and again when it resolves. The per-rule cooldown, 15 minutes by default, stops a flapping condition from notifying every time it crosses the line.
- Silence. Mute a rule for a maintenance window. It keeps evaluating and recording, and the server holds back its notifications.
Which rules deserve a page at 2 a.m., and which belong in a weekly review, is a design question. Saga IT’s guide to Mirth Connect alerting works through it.
A dead engine can’t send its own alert. OpenShare notices.
Alerts that run inside the engine, Mirth’s built-in ones included, stop when the JVM stops, the disk fills or the VM goes away. OpenShare watches from outside. The plugin reports in continuously, and when a server stops reporting, the platform emails you and the fleet page marks it offline. No rule on the dead engine has to fire.
Every rule picks how it reaches you.
- OpenShare Cloud email. The platform sends the rule’s email to the server’s owner and organization members who have monitoring alert emails on, so it arrives even when the server can send nothing.
- Local email. The server sends through your own mail settings, fast and fully in your hands while the engine is up.
- Webhooks. Signed HTTPS posts into PagerDuty, Slack, a ticketing system or your own automation, or a message to the broker your operations tooling already watches. They fire whichever email source a rule uses.
- One email source per rule. A single alert never arrives as both a local and a cloud email.
- Summary reports. An optional daily, weekly or monthly health summary of your servers, by email, in your own time zone.
How OpenShare compares with the usual Mirth monitoring options.
Every option below works. They differ in which engines they cover, whether they see across servers, and what they can alert on.
| Option | Engines | Across servers | Alerts on | Cost |
|---|---|---|---|---|
| Built-in Mirth Alerts | Every Mirth-family engine | No, set up on each server | Channel errors only, sent from inside the engine | Free |
| Administrator dashboard | Every Mirth-family engine | One server at a time | None. A live view while someone has it open | Free |
| Polling scripts or a metrics stack (Zabbix, Prometheus, PRTG) | Every Mirth-family engine | Yes, once you build it | Whatever you script and maintain | Your time, plus the stack to run |
| Mirth Command Center | Licensed Mirth Connect 4.6 and later, for US customers | Yes, across registered servers | Error, queue and inactivity thresholds, by email | Part of a commercial Mirth license |
| OpenShare Monitoring | Mirth Connect, OIE, BridgeLink | Yes, one fleet page | Channel state, thresholds, rate of change and silence, plus offline servers caught from outside the engine | Free on the servers you need to get started |
Already licensed for Mirth Connect 4.6 or later on every server? Command Center is part of what you pay for, so start there. OpenShare covers what it cannot reach: OIE, the open-source Mirth Connect releases, and fleets that mix them, on the same plugin that brings the browser Console and remote access without a VPN.
Live this afternoon, on the engine you already run.
Register the server
Name it and download a plugin that already knows which server it is. Its single-use credentials are baked in, so there is nothing to paste. Tick cloud sync so it reports to the fleet page.
Drop it in and restart
Put the plugin in the engine’s extensions folder and restart. It registers itself and dials out, so there is no VPN and no inbound port.
Switch on your rules
The server appears on the fleet page and its history starts filling in. Enable the templates you want and point them at an inbox or a pager.
Mirth Connect, OIE and BridgeLink, on one fleet page.
Open Integration Engine monitoring works exactly like Mirth Connect monitoring, because the plugin is fork-agnostic. It runs on Mirth Connect (the open-source releases through 4.5.2 and commercial 4.6 and later), on OIE, and on BridgeLink, the same way on each, so a fleet that mixes them shows up on one page.
More on the Mirth Connect plugin →Monitoring data carries no PHI.
The monitoring path collects numbers and states: counts, percentages, timestamps and channel lifecycle events. Message content is never read, stored or sent by it. Alert emails and webhooks carry the rule, severity, state, channel, metric value and threshold, and nothing from the message.
- Outbound only. The plugin dials out. No inbound firewall port, no VPN, no DMZ.
- Stored on your server. Metric history and rule settings live in the plugin’s own database on each server and sync up for the fleet view.
- Secrets stay masked. Webhook signing secrets and mail passwords are hidden once saved and never sent back to the browser.
- Signed webhooks. HTTPS only, each one signed so your receiver can check it came from your server.
- Host details stay private. Operating system, Java version, hostname and IP are visible to the server’s owner or organization, not to anyone it is shared with.
Frequently asked questions.
Is OpenShare’s Mirth Connect monitoring free?
Yes. Monitoring is free to run and is not a separate subscription. You install the OpenShare Gateway plugin on your Mirth Connect or OIE server and monitoring comes with it in the OpenShare Console. The free tier covers the servers you need to get started, and larger fleets move to a paid tier. See pricing.
Which engines can it monitor?
Mirth Connect (the open-source releases through 4.5.2 and commercial 4.6 and later), the Open Integration Engine (OIE), BridgeLink, and other Mirth Connect-compatible forks. The same plugin installs the same way on each, so a mixed fleet shows up on one fleet page.
What does it alert on out of the box?
The rule drawer ships seven templates: Channel Stopped, High Error Rate, Queue Depth Warning, No Messages (30 min), JVM Heap High, Disk Usage High and Error Spike. They arrive switched off, so nothing notifies anyone until you enable a rule and choose where it goes. Every threshold, window, severity and scope is yours to change.
How do I find out when a whole server goes down?
OpenShare watches from outside the engine. When a server stops reporting, the platform emails you and the fleet page shows it offline, so no rule on the failed server has to fire. Rules can also send their email through OpenShare Cloud instead of the engine’s own mail settings, so it arrives even when the server cannot send anything.
Can alerts go to PagerDuty, Slack or a ticketing tool?
Yes. A webhook destination posts each alert as signed JSON over HTTPS to any receiver that accepts one, including PagerDuty, Slack incoming webhooks and ticketing systems. Webhooks fire whichever email option a rule uses, and a test button sends a sample alert before you rely on it.
We already have Mirth Command Center. Do we need this?
If every engine you run is licensed Mirth Connect 4.6 or later, Command Center is part of what you pay for, so start there. OpenShare covers what it cannot reach: OIE, the open-source Mirth Connect releases, and fleets that mix them. It also runs on the same plugin as the browser Console and remote access without a VPN.
Does monitoring send PHI anywhere?
No. Monitoring collects counts, percentages, timestamps and channel lifecycle events. Message content is never read, stored or sent by the monitoring path, and alert emails and webhooks carry the rule, severity, state, channel, metric value and threshold, never message content.
How long is monitoring history kept?
Each server keeps raw samples for 7 days, hourly rollups for 30 days and daily rollups for a year, and alert events for 90 days. Charts switch to the coarser rollups as you zoom out, so the same explorer answers last hour and last quarter.
Do we need a VPN or an open firewall port?
No. The plugin makes one outbound encrypted connection, so nothing dials in to your server and no inbound port is opened. You reach the dashboards from any browser through the OpenShare Console.
