Test and operate
Inspect and replay events
Use the customer event ledger to diagnose source data, identity, processing, and journey behavior without creating accidental duplicates.
What to inspect
| Field | Question |
|---|---|
| Source | Did the expected connection produce it? |
| Message ID | Will a producer retry deduplicate? |
| Customer | Was the signal linked to the intended person? |
| Event and properties | Do names, values, and types match the contract? |
| Processing status | Was it processed, rejected, or failed? |
| Journey enrollments | Which journeys evaluated or enrolled this customer? |
Replay is a deliberate re-evaluation
Replay asks the journey engine to evaluate an existing customer event again. It is not the same as resending the HTTP request, and it should be used only after fixing the relevant journey or processing problem.
Safe replay procedure
- 01
Explain why replay is needed
Record the failed or incorrect condition you have fixed.
- 02
Inspect prior outcomes
Confirm no duplicate send or task will be created.
- 03
Use one controlled event
Replay a synthetic or internal customer event first.
- 04
Verify the timeline
Inspect enrollment, exit, and action state before replaying a wider set.