Journey step
A journey step is a single action in an automated email workflow. Send an email, wait, update a profile field, split based on behaviour. Each step can fail silently when the platform logs success but the expected outcome does not occur.
Definition
What a journey step is
A journey step is one node in a multi-step automated email workflow. The workflow might be called a journey, a flow, or an automation, depending on the platform. The step is the unit of work inside it. A welcome journey might have five steps: send welcome email, wait 24 hours, check whether the customer opened, send follow-up if they did not, mark journey complete.
Every sending platform surfaces steps as visual blocks in a builder. Each block does one thing. The platform executes the journey by moving a customer from step to step. If a step fails without raising an error, the journey continues and the failure is silent.
Common step types
The actions a step can perform
Send email
The most common step type. Fires a specific email template to the current customer in the journey. Can fail silently if merge tags break or the send queues but does not complete.
Wait or delay
Holds the customer in the journey for a fixed duration or until a specific time. Common for drip sequences. Rarely fails, but timezone handling can cause late arrival if the wait calculation is incorrect.
Update profile
Writes a value to a customer data field. Used to track journey progress or set flags for downstream logic. Can fail silently if the field name changed or permissions broke.
Decision split
Routes customers down different branches based on behaviour, profile data, or event properties. Does not fail in the traditional sense, but can route incorrectly if the condition logic is stale.
Why steps fail silently
Platform logs versus inbox reality
Most platforms log a step as complete when it finishes executing, not when the outcome arrives. A send step logs success when the email enters the send queue, not when it reaches the inbox. An update step logs success when the API call returns, not when the value persists in the database. The platform's native activity log shows green, but the customer sees nothing.
Silent failures happen when the step runs but a downstream dependency breaks. The merge tag references a field that no longer exists. The sending domain lost its authentication records. The API integration timed out. The platform has no way to know the outcome did not occur, so it moves the customer to the next step as if everything worked.
Monitoring versus platform logs
Why you need inbox-side checks
Platform logs tell you whether the step executed. Inbox-side monitoring tells you whether the expected outcome occurred. If a send step completes but the email does not arrive, the platform log is clean and the inbox is empty. You only know about the gap if you check the inbox.
Most operators learn this the hard way. A Saturday-morning newsletter that did not send for the first hour of the window. The platform reported success for every step. The inbox stayed empty. By the time the gap surfaced in subscriber complaints, the broadcast window had closed. Late arrival in the first 30 minutes of a window is almost always a scheduling or timezone issue, not a genuine breakage, but the symptom is identical from the inbox: the absence of the expected email.
Heartbeat-mode monitoring catches where the symptom is the absence of the expected send, not an error event in the platform. If a transactional flow normally fires fifty times an hour and goes silent for twenty minutes, heartbeat mode alerts on the gap. The platform logs show every step completing. The inbox shows the rhythm stopped.
What Telltide watches
Steps that send, not steps that route
Telltide monitors the outcome of send steps from the inbox. It does not monitor update-profile steps, decision-split logic, or delay nodes. The surface it watches is whether the expected email arrived on time, without duplication, with working merge tags and links. If a step sends but the inbox stays empty, Telltide alerts. If the step routes a customer incorrectly, Telltide does not see it.
The monitoring model is end-to-end: a live identity enters the journey, progresses through the steps, and triggers the expected email. Telltide checks the inbox for arrival. The check is identical to how a customer would experience the journey, but automated and repeatable. If the email does not arrive within the expected window, the alert fires in under two minutes from breakage to notification.
Related reading
Concepts that travel together
- Triggered flow: the workflow a journey step belongs to.
- Silent send: what happens when a send step completes but the email does not arrive.
- Heartbeat monitoring: the right approach when individual step failures are noisy but the rhythm of sends is meaningful.
- Full glossary: all the inbox-side monitoring terms in one place.
Watch your journey steps from the inbox
One monitor free. Paid plans from $49 USD per month.