Sirius A product of
Documentation Contact

How-to

Replay a message

Replay is how you recover after a downstream outage. Sirius never edits the original ledger row. It writes a new, auditable attempt with a causation link back to the first message.

From the console

  1. Open Monitor.
  2. Search the ledger by integration, time, status, or payload text.
  3. Open the message. Confirm the payload and the original destination.
  4. Click Replay. Optionally set an idempotency key if you will retry the click.
  5. Watch the new attempt in History. The original row stays put.

If the message is already in the dead-letter queue, prefer the DLQ actions:

ActionWhen to use it
RetryThe destination is healthy again. Creates a new attempt.
ResolveA human handled it outside Sirius. Closes the item without another send.
TerminalYou are done. Irreversible. Do not use this as a first try.

From the API

curl -s "$SIRIUS/messages?tenant_id=default&limit=20"

curl -s -X POST "$SIRIUS/messages/<queue_id>/<sequence>/replay" \
  -H 'content-type: application/json' \
  -d '{"request_id":"replay-001"}'

curl -s "$SIRIUS/failures?tenant_id=default&limit=50"
curl -s -X POST "$SIRIUS/failures/<id>/retry"
curl -s -X POST "$SIRIUS/failures/<id>/resolve"

Reuse request_id if the first replay call times out. A new key means a second replay.

What replay does not do

  • It does not mutate the original payload in place.
  • It does not skip the transform. The live graph runs again.
  • It does not copy secrets or invent a destination. The integration must still be bound and started.

If the same message keeps failing, fix the destination or the mapping first — then retry. See Page on failure and Write a transform.