Early Access · beta. We're building toward 1.0 — and we want people involved now, while it can still be shaped. Where the project stands →

MessageFoundry™
Admin & monitoring console

Watch every interface, live

The operations view for the people running MessageFoundry — every interface's health and throughput on one screen, the tools to trace a single message end to end, and start/stop, alerts, and replay close at hand. It reads and drives the engine through one localhost API, so what you see is exactly what the engine is doing.

Get started See the whole toolkit →
The MessageFoundry monitoring console showing the live Connections dashboard: a left sidebar (Connections, Alerts, Dead Letters, Log Search, Engine Status, Users) and a table of interfaces with a status badge each — RUNNING, DEGRADED, FAILED, STOPPED — plus direction, method, per-connection logs, idle time, and counts for errored, read and written messages, queue depth, and backlog. The header shows the signed-in admin and a 2-second auto-refresh.
Every counter here is live from the engine — messages read, written, and errored per connection, plus queue depth and backlog — refreshed every couple of seconds, so what the dashboard shows is what the engine is actually doing. Nothing is counted that wasn't durably stored first: messages are persisted before they're acknowledged, then delivered at-least-once, so a failed delivery surfaces as a dead letter rather than a silent drop. How throughput really works →
Connection dashboard

Every interface, at a glance

The home screen is a live table of every connection — inbound and outbound — refreshing on its own. One look tells you what's healthy, what's slow, and what's stuck.

Click into any connection's logs, or select one and start, stop, or run an action — the controls are right there, gated by your role.

  • Status at a glance — RUNNING, DEGRADED, FAILED, or STOPPED — and a SIM tag when a destination is running in simulation.
  • Throughput, per connection — messages read, written, and errored, so a climbing error count is obvious immediately.
  • Queue depth & backlog — see exactly where messages are piling up, and how far behind a slow peer has fallen.
  • Per-connection logs — jump straight from a row to that interface's log stream.
  • Start / Stop / Actions — operate interfaces in place, permission-gated.
  • Auto-refresh — the view updates every couple of seconds; no reloading.
When something needs attention

Catch problems, then chase them down

From a red status to the exact message that failed, the trail is short.

Alerts

A single page of the alert rules in effect and what they're watching — so the conditions that page someone are written down and visible, not buried in a config file.

Dead Letters

Every message that exhausted its retries, in one list. Inspect why it failed and replay it with one click once the downstream is healthy again — no database surgery.

Trace a message

Search the log for a message, then follow it: its disposition (routed, filtered, or unrouted), its full delivery & audit trail, and an HL7 parse-tree viewer to read it field by field — with replay when you need it.

Operate with confidence

Engine health and access, built in

  • Engine Status — the engine's health at a glance, with a heartbeat indicator that's green when all is well.
  • Users & sessions — manage accounts, roles, and active sessions from the console; every action is recorded in the tamper-evident audit log.

A pure API client

The console drives and observes the engine only through the one localhost API — it never imports the engine or touches the database directly. So authentication, RBAC, and the audit log sit at a single choke point rather than spread across every tool.

Monitoring is read-only; actions like start/stop and replay are permission-gated. The same API powers the CLI and the VS Code editor — see how it fits together.

One engine, one console, full visibility

Run your interfaces in the open — see every message's fate, and act on it.

Get started See the whole toolkit →