Browsing and reprocessing messages

The message browser is where you answer the two questions that follow any incident: what did we receive, and what happened to it?

Browsing

Messages are listed per channel with their status, timestamp and destination outcomes. Filter by time window, status and destination to narrow down an incident.

Retention follows the plan: 7 days on Free, 30 on Team, 365 on Enterprise. Extended retention is available as an add-on.

Format-aware viewers

Raw payloads are hard to read under pressure, so the detail view renders by format:

• HL7 v2 — a segment viewer that breaks the message into segments and fields rather than one long pipe-delimited line.
• FHIR — a resource tree you can expand.
• CDA / CCDA — a document view.

The detail view also shows the payload at each stage, which is what distinguishes “we never received it” from “we transformed it wrong”.

Reprocessing

Single reprocess — open a message and reprocess it. Useful while debugging a mapping fix.

Batch reprocess — select a range and reprocess it in bulk. This is the one you want after a downstream system has been down: filter to the outage window, confirm the set, and replay.

Reprocessing is available on every plan, including Free.

Each reprocess is recorded in the event stream with who initiated it, so the replay itself is auditable.

Before you replay

Two things worth checking:

1. Is the downstream system actually back? Replaying into a system that is still failing just moves the problem later.
2. Is the destination idempotent? For FHIR destinations, a conditional upsert matching on an identifier converges rather than duplicating. For HTTP destinations, that depends on the receiving system.

Events

Alongside messages, the Events stream records platform activity — deployments, promotions, approvals, role changes, reprocess runs. Messages tell you what happened to clinical data; events tell you what people did to the platform.