One secure control plane for
dead-letter queue recovery

Triage is self-hosted and ships as a Docker image or Node.js application. It requires PostgreSQL (for audit log and configuration storage) and Redis (for session management and job queuing). It runs on any Linux server with 1 vCPU and 1 GB RAM or above — more for high replay volume. Users access it from any modern browser — Chrome, Firefox, Safari, or Edge. No agent or client software is installed on user machines.

No. Message payloads, attributes, and credentials never leave your infrastructure. Triage connects directly to your brokers server-side. The only optional external call is to your configured LLM provider (Anthropic, OpenAI, or any compatible model) for AI diagnosis — and that is opt-in, requires your own API key, and only sends the specific payload you choose to diagnose.

Not if application-layer encryption is enabled. The only sensitive payload Triage stores at rest is the before/after body snapshot on each replay and storage remediation. With envelope encryption on, those bodies are written as AES-256-GCM ciphertext whose data key lives only in application memory — wrapped at rest by a raw master key or a cloud KMS (AWS KMS, GCP KMS, or Azure Key Vault). Ciphertext read out of the database is useless without the key, which a database-level attacker never holds. This is the distinction that matters: at-rest volume/RDS encryption protects a stolen disk or backup but gives nothing against a live DB breach, because Postgres decrypts transparently for anyone who can connect. Encryption keeps the before/after diff fully working — bodies decrypt at render time. The data key is unwrapped once at startup and pinned in memory, so there is no KMS call on the per-message path. Cloud KMS providers require the "kms" license feature; the raw master-key provider is always available.

Both are your choice. Set SNAPSHOT_CAPTURE=false and audit rows are written without bodies — the payload is dropped at insert time and never touches the database; you keep the full "who remediated what, when, on which queue" record and give up only the before/after diff. Alternatively, set SNAPSHOT_RETENTION_DAYS=N and an hourly, leader-gated job scrubs body columns older than N days while keeping the metadata row intact, capping the blast radius of a breach to the last N days. By default bodies are retained indefinitely. Retention scrubbing is scoped to the provider names each instance owns, so in a shared database one instance’s policy never scrubs a co-tenant’s bodies. These controls compose with encryption — you can encrypt bodies and time-box them.

No. AI-assisted diagnosis is an optional feature. All core capabilities — inspection, transforms, replay, audit trail, and automation rules — work without it. If you enable it, Triage uses your own API key for your chosen LLM provider so usage is billed directly to your account and remains under your control.

Triage supports local credentials out of the box and integrates with OIDC/SSO providers for teams that require it. Role assignment (Viewer, Operator, Developer, Admin, Service Account) is managed in the Triage admin console, and can be derived from an OIDC group claim so your IdP stays authoritative. Service accounts authenticate via scoped API tokens for automated integrations.

Yes — that is the Developer role. Writing a transform script is a developer's job; operating the queue it runs on is not, so Developer grants authorship of transforms (create, test, clone, version, edit) and nothing else. It is not a rung on the Viewer → Operator → Admin ladder: a developer cannot replay, purge, manage users, issue tokens, or edit replay rules, and it is explicitly not trusted with production message payloads — the reads that return a body (queue peeks, the replay log, and message traces) are closed to it, so scripts are tested against sample payloads pasted into the editor. Two further guards apply. A developer cannot edit a transform an enabled replay rule already references, because that would silently change what production replays do on the rule's next tick — the editor points them at clone-and-edit, and an admin owns the promotion. And delete, which takes the version history with it, is limited to the transform that developer last authored; anyone else's is an admin decision.

Yes. Triage can connect to a Google Cloud Storage bucket, an Azure Blob container, or any S3-compatible store as a storage provider for poison-object remediation — files that a pipeline couldn't process and moved aside. The S3 provider is not limited to AWS: point it at an endpoint and it works with AWS S3, Cloudflare R2, Wasabi, Backblaze B2, DigitalOcean Spaces, or self-hosted MinIO, and Triage labels the store by vendor throughout the UI. You get the same browsing, search, edit, diagnose, and replay-to-queue workflow as DLQ messages, plus a dedicated storage audit log and storage-aware alert and replay rules. Bucket credentials live server-side only — no one needs direct bucket access or IAM keys on their laptop to inspect or fix rejected files. This is optional and configured independently of your queue providers.

Not by design — and that's a deliberate choice, not a limitation. Kafka has no dead-letter queue at the broker level: a "DLQ" there is only an application or framework convention (a Kafka Connect dead-letter topic or a Spring DLT), and its failure model is based on consumer offsets and retention rather than per-message removal — a model already served well by dedicated Kafka tooling, and one we're happy not to compete with. Triage is built for brokers with real dead-letter-queue semantics — SQS, RabbitMQ, ActiveMQ / Amazon MQ, Azure Service Bus, Google Pub/Sub, and Anypoint MQ — where failed messages land in a discoverable DLQ you can browse non-destructively, fix, and then replay or clear one message at a time. In practice this is a complement, not a gap: most enterprises run Kafka alongside the classic brokers — RabbitMQ, ActiveMQ, SQS and the rest are almost always in the estate too — and that conventional-queue layer is exactly where Triage lives. It sits happily next to your Kafka tooling and takes the DLQ triage off your plate for everything else, as a single self-contained binary alongside the Postgres and Redis you already run.

Yes. Triage has its own native message tracing — every replayed message is stamped with a triage_message_id and root_triage_message_id. These correlation IDs are written to replay events and storage events, and a trace timeline page reconstructs the full journey of a message across providers, storage actions, and federated Triage instances in chronological order. In addition, Triage emits OpenTelemetry spans for replay paths using a BatchSpanProcessor, and injects the W3C traceparent header into outgoing message attributes so upstream OTEL traces continue through Triage. Configure OTEL_EXPORTER_OTLP_ENDPOINT to ship spans to Datadog, Grafana, Honeycomb, or any OTLP-compatible backend.

Yes. Triage has a built-in GET /metrics endpoint in the Prometheus text format. It publishes triage_queue_depth (per-queue gauge), triage_replays_total, and triage_alert_firing (per alert rule, labelled by rule ID, queue, and label). When federation is enabled, it additionally exposes triage_federation_peer_up, triage_federation_peer_latency_seconds, and triage_federation_peer_cert_expiry_seconds per peer. Standard Go runtime metrics are also included. Point any Prometheus-compatible scraper — Prometheus, VictoriaMetrics, Grafana Agent, or the Datadog Agent — at <triage-host>/metrics to bring DLQ depth and alert state into your existing SRE dashboards, recording rules, and on-call alerts.

Yes. Triage ships a built-in Model Context Protocol server at /api/v1/mcp, so any MCP client can inspect live dead-letter state during incident response. Sixteen tools are exposed, role-scoped: a viewer token sees ten, while an operator or admin token adds the two live cross-peer tools and the four storage tools, the latter only where object storage is configured and licensed.

• → list_queues — every queue with its current depth, DLQ status, and per-queue capabilities.
• → get_queue_config — redrive policy, retention, visibility timeout, and TTLs: why messages are landing here.
• → get_provider_info — which broker this instance is attached to, and which operations it supports.
• → get_instance_info — this instance's id, version, broker and features, plus its federation peers and their health.
• → get_stats — replay counts and success rate over a rolling window, live depth totals, transform and alert-rule counts.
• → get_depth_history — time-series depth for one queue: filling for days, or spiked ten minutes ago.
• → get_alert_status — every alert rule's current state: alerting, ok, or never evaluated.
• → list_alert_events — when each rule started and stopped firing, to line up against a deploy window.
• → list_replays — whether these messages have already been retried, by whom or by which rule, and whether it worked.
• → get_trace — one message's full journey by id: every hop, replay attempt, and transform, including federated instances.
• → list_federation_peers — live workload on every instance in the group: DLQ counts, total depth, and firing alerts, so an agent can find which instance a backlog is actually on.
• → get_peer_queues — the queues on one federated peer that can receive a replay, confirmed live over mTLS before a cross-instance replay is proposed.
• → list_storage_buckets — the buckets this instance archives failed messages to, with backend type, endpoint, and whether each is actually reachable.
• → list_storage_objects — archived objects by prefix, key search, or extension: where to look when a queue is empty but messages are unaccounted for.
• → get_storage_object_metadata — an object's size, content type, and archived x-triage-* lineage, which hands a root id straight to get_trace.
• → list_storage_events — edits, republishes, moves, deletes, and restores against archived objects: has anyone already tried this, and what happened?

Together they cover an incident walkthrough without a human relaying state, and — with federation configured — reach across the whole mesh from the single endpoint the agent is pointed at. The storage tools close the loop the other way: an object found in a bucket carries the lineage to identify the message that produced it, so a queue that reads empty is not the end of the trail. Because Triage is broker-agnostic, an agent gets one consistent tool surface across SQS, RabbitMQ, ActiveMQ / Amazon MQ, Azure Service Bus, Google Pub/Sub, and Anypoint MQ — a question a single-broker cloud console cannot answer. The transport is stateless streamable HTTP, so replicas stay interchangeable behind a load balancer with no sticky routing.

No — the tool surface is read-only by design, not by configuration. Replay, purge, and delete are simply absent: remediation stays human-authored, so an agent that can only observe cannot turn a bad inference into a production change. There is also no tool to peek at messages still sitting in a queue, because peeking is a real receive on most brokers and an agent looping it would redrive healthy messages into the DLQ. Nor does any tool return a message body — not the messages queued in a DLQ, and not the before/after snapshots of ones already replayed. The surface is metadata only, by deliberate design: an agent cannot exfiltrate payload contents even for a message a human could open in the Triage UI. list_replays still reports whether a body was modified before it was sent, without exposing either version. The storage tools hold the same line: an archived object's body is never transferred, and neither the sender's own message attributes nor the object's user-defined metadata are returned — only the x-triage-* lineage Triage itself wrote. Object keys are the one thing that cannot be pruned, since they address every storage tool, so MCP_STORAGE_TOOLS=false withholds that group outright for estates whose keys carry customer identifiers. Access is authenticated exactly like the REST API: the endpoint sits behind the same auth middleware and every tool runs with the caller's own token and role, so a viewer token yields a strictly read-only agent and share links are rejected outright. Each tool dispatches into the same handler as the REST endpoint it mirrors, so RBAC, audit logging, error mapping, and provider-capability fallbacks are identical by construction — a tool cannot drift from the endpoint behind it.

Yes. Triage has a dedicated Architecture view and an admin-only REST endpoint, GET /api/v1/export/archimate, that generates a live ArchiMate Open Exchange model of the running instance and — when federation is configured — its peers. Pass ?version=3.1 or ?version=3.2 (default 3.2) to match your tool. The model is built from real runtime data: host interfaces and OS, Go runtime, Postgres/Redis addresses, the queue provider and storage backend endpoints, and the mTLS federation mesh with shared-store blast radius. Because it is standard ArchiMate 3.x XML, you can poll it on a schedule and ingest it into Archi, BiZZdesign Blue Dolphin, or any compatible modeling tool to keep an always-current view. In-app the same model renders as a searchable list and a layered topology diagram, and you can generate a time-limited read-only share link so architects, support, and engineers — and on-call SREs during break-fix — can see the current-state picture without a Triage login.

Not yet — Triage is currently self-hosted only. A managed cloud offering is on the roadmap. In the meantime, the Docker deployment is designed to be straightforward, and we offer implementation services to get you running quickly.

Licensing is priced on the number of message providers you connect, not per seat and not per message — a metric that reflects the size of your estate rather than how badly it is failing. There is a free Community tier for a single provider; Team and Business are annual licences you can buy directly; Enterprise is priced per estate. A licence covers your whole organisation, including unlimited instances and non-production deployments. See the pricing page for the current tiers, or get in touch and we can discuss what fits your environment.