Journeys that survive crashes, deploys, and success
A durable, versioned, crash-safe journey engine with a visual canvas, real-time event entry, honest A/B statistics, and per-recipient send-time optimization.
Automation that doesn't lose people
Email automation journeys here run on a durable, versioned, crash-safe engine: state persists outside any process, so a worker crash or a deploy resumes a journey instead of restarting or dropping it. The canvas is visual; the machinery underneath is what makes it trustworthy.
How it works
- Build the journey on the visual canvas — nodes and edges, readable by the non-engineers who will own it.
- Enter contacts in real time from custom events: the CDP ingests events you send, and an event can trigger entry the moment it arrives.
- Test variants with A/B splits whose winner statistics are peeking-safe — looking early doesn't corrupt the verdict.
- Let send-time optimization schedule each recipient individually, at the hour their history says they read.
Journeys are versioned: an edit creates a new version rather than silently rewriting what came before.
The evidence
// POST /v1/events
{
"email": "ada@example.com",
"event": "trial_started",
"properties": { "plan": "growth" }
}The event lands on the contact's CDP timeline and can enter them into a journey in real time — no polling loop, no nightly sync job to babysit.
Honest limits
encrypted sends give up click-tracking, send-time optimization, and per-recipient analytics — that is what “we can't read it” costs, and we say so. For organizations with at-rest encryption enabled, that applies to journeys too: they run, but send-time optimization and per-recipient engagement analytics don't. Separately: peeking-safe statistics mean the engine won't declare an A/B winner early just because you looked — verdicts take as long as the math requires, and impatience doesn't shorten it.
Where to go next
Journeys pair with newsletters on the content side and feed on the same events you can receive over webhooks. The creator door shows where automation fits the bigger loop, and if you're coming from a creator suite, the Kit comparison covers what changes and what you'd give up.
Questions, answered plainly
What happens to in-flight journeys during a crash or deploy?
They resume. Journey state persists outside any process, so a worker crash or a deploy picks up exactly where it left off — contacts are neither dropped nor restarted from the beginning.
What can trigger journey entry?
Custom events, in real time: the CDP ingests events you send, and an event can enter a contact into a journey the moment it arrives — no polling loop, no nightly sync.
What makes the A/B statistics "peeking-safe"?
Checking results early doesn't corrupt the verdict. The engine won't declare a winner just because you looked at a promising moment — the math runs to a sound conclusion regardless of how often you refresh.
Does send-time optimization work with encrypted sends?
No — encrypted sends give up click-tracking, send-time optimization, and per-recipient analytics — that is what “we can't read it” costs, and we say so. Journeys still run for those organizations; the per-recipient timing and analytics features don't apply to encrypted sends.