# Journeys that survive crashes, deploys, and success

> Email automation journeys on a durable, versioned, crash-safe engine: visual canvas, real-time event entry, A/B testing, and send-time optimization.

Canonical: https://emailfast.dev/features/automation

## 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

1. Build the journey on the visual canvas — nodes and edges, readable by the non-engineers who will own it.
2. Enter contacts in real time from custom events: the CDP ingests events you send, and an event can trigger entry the moment it arrives.
3. Test variants with A/B splits whose winner statistics are peeking-safe — looking early doesn't corrupt the verdict.
4. 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

:::panel Event in, journey entered
```json
// 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

:::tradeoffs Two honest notes
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](/features/newsletters) on the content side and feed
on the same events you can receive over [webhooks](/features/webhooks). The
[creator door](/creators) shows where automation fits the bigger loop, and if you're
coming from a creator suite, the [Kit comparison](/compare/kit-alternative) covers
what changes and what you'd give up.

## 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.