Monitor Iterable workflow journeys from the inbox
Iterable workflows fire on triggers, filters, data-feed steps and conditional logic. Each component can break quietly. Iterable logs the step as executed. The customer's inbox is empty.
Telltide confirms each workflow step reaches the inbox, in the right order, at the right time.
Why workflows break quietly
The failure modes native analytics miss
Iterable analytics show aggregate metrics across hundreds or thousands of users. They do not alert when a single step fails for a single profile. That single profile is often your highest-value customer.
Filter nodes evaluate incorrectly after field renames
A filter step routes users on a custom user field. An engineer renames the field in the data schema. The workflow is updated to reference the new name, but the filter logic is accidentally inverted. Users flow to the wrong path. Both paths report full sends.
Data-feed steps time out silently
A workflow node pulls real-time data from an external API to personalise the email. The API response times out. Iterable moves the user to the next step with empty data fields. The email renders with blank merge tags. Iterable logs the send as delivered.
Update-user-profile steps overwrite trigger fields
A workflow step updates a user profile field. The next step triggers on that field equalling a value. The update writes a different value than expected. The trigger never fires. Iterable logs the update as successful and the trigger as not met.
Wait-until nodes skip when conditions are never met
A wait-until node holds users until a specific event fires or a timeout is reached. The event schema changes. The condition is never met. Users exit at the timeout. The workflow continues, but the email that should have fired on the event is skipped.
Liquid templates reference deprecated fields
An email step includes a Liquid block that pulls a custom field. The field is deprecated. The template renders with a blank value. Iterable logs the send as delivered. The email arrives with broken personalisation.
Trigger-based entry stops firing
Workflow entry is triggered on a custom event. The event schema changes upstream. The workflow sits idle. Iterable reports zero new entries. No alert fires because zero entries is a valid state.
Workflow vs campaign scope
Why multi-step journeys need step-by-step confirmation
A workflow is not a single send. It is a sequence of conditional steps. Each step depends on the state written by the previous step. One misconfiguration cascades.
Campaigns are stateless
A campaign fires once when the trigger condition is met. If it fails, you know immediately because the send count is zero. Workflow steps are stateful. They inherit context from earlier steps. A failure in step three looks like a drop in conversion rate, not a send failure.
Workflow steps can skip silently
A campaign either fires or it does not. A workflow step can be skipped because an earlier delay miscalculated, because a filter routed the user elsewhere, or because a wait-until node timed out. Iterable logs the skip. It does not alert on it.
Aggregate metrics hide single-user failures
Workflow analytics report conversion rates and send counts across the entire audience. If 999 users receive step four and one user drops out, the metrics look healthy. The dropped user might be the one who was about to convert.
How Telltide fits
A monitored profile for every workflow path
Telltide runs alongside Iterable, not inside it. You add a monitored user to the workflow entry filter. Telltide watches the inbox for each step Iterable says it sent.
Add the monitor address to your workflow filter
Telltide gives you a unique inbox address per monitor. You create a user profile with that address, assign the custom fields or event history the workflow needs, and let it enter at the first step.
Set the arrival window per step
For a step with no delay, the window might be five minutes. For a 24-hour delay, the window is 24 hours plus a buffer. For send-time optimisation, you set a wider window to account for variation.
Get alerted when the inbox disagrees with Iterable
If the email does not arrive in the window, an alert fires. If it arrives twice, an alert fires. If the content deviates from the reference template, an alert fires. Iterable might still report the step as healthy. The alert tells you what actually reached the inbox.
Monitoring specific workflow components
Delays, filters and data-feed steps
Each workflow component has its own monitoring considerations. Here is how to set up Telltide for the components that break most often.
Match the arrival window to the delay duration
A workflow with a 48-hour delay needs a 48-hour arrival window plus a 30-minute buffer. If the email arrives early, the delay was skipped. If it arrives late, something downstream held it up. Either case fires an alert.
Monitor each filter variant separately
If a workflow splits users into two paths based on a field value, create two monitors. Each monitor gets a unique user profile with the field that qualifies it for one path. If one path stops sending, you know which variant broke.
Watch the step after an update-user-profile action
If a workflow includes an update-user-profile step followed by a trigger that depends on the updated value, monitor the email step that follows the trigger. If the update writes the wrong value, the trigger will not fire, and the monitor will catch the missing email.
Fire entry events from a test harness
For a workflow that enters on a custom event, trigger the event from a script or API call on a schedule. The monitored profile receives the event, enters the workflow, and Telltide confirms the first step fires. If the event schema changes and entry stops, the monitor alerts within 15 minutes.
Workflow observability vs native analytics
What Iterable shows, and what it cannot
Iterable workflow analytics are detailed. They show every step, every conversion, every exit. What they cannot show is whether the email that Iterable logged as delivered actually arrived in the shape you intended.
Iterable reports delivery, not inbox arrival
When Iterable logs a send as delivered, it means the receiving mail server accepted the message. It does not confirm inbox placement, spam filtering, or correct rendering. Inbox-side monitoring closes that gap.
Iterable exits are logged, not alerted
When a user exits a workflow early, Iterable logs the exit reason. It does not alert you that the exit happened. If the exit was caused by a misconfigured wait-until node, you will not know until you actively review the exit logs.
Liquid errors render silently
When a Liquid template references a missing field, Iterable renders the block as blank. The email is logged as delivered. The customer receives broken content. Telltide compares the arrived email against a reference and alerts on structural deviation.
Pair it with
Concepts and related monitoring guides
The pages below cover the broader Iterable monitoring context and how it fits with other journey types.
- Monitor Iterable: the parent guide covering all Iterable send surfaces.
- Triggered flow: how entry events and conditional logic interact across platforms.
- Email monitoring tools compared: where native analytics end and independent monitoring picks up.
FAQ
Common questions about Iterable workflow monitoring
What Iterable workflow failure modes does inbox-side monitoring catch?
Filter nodes that evaluate incorrectly after a field rename, data-feed steps that time out silently, update-user-profile steps that write the wrong values, and wait-until nodes that skip when conditions are never met. Iterable logs each step as executed. The inbox tells you whether the email actually arrived.
How do I monitor an Iterable workflow with multiple delay steps?
Set the arrival window in Telltide to match the cumulative delay duration. If a workflow includes a 24-hour delay followed by a 12-hour delay, the monitor expects the email 36 hours after entry. If the email arrives early or late, the alert tells you which delay node broke.
Can I monitor Iterable workflow variants independently?
Yes. Create a separate monitor for each variant path. Each monitor gets a unique inbox address. You build a user profile for each address with the properties that qualify it for one variant. If one path stops sending, you know immediately which variant is affected.
Do I need Iterable API access to monitor a workflow?
No. Telltide operates independently of your Iterable workspace. You add the Telltide monitoring address as a user profile in the workflow entry filter. Iterable treats it as a normal user. Telltide watches the inbox for the sends Iterable logs.
Start watching your Iterable workflows
One monitor free. Paid plans from $49 USD per month. Set up takes about two minutes.
Iterable is a registered trademark of Iterable, Inc. Telltide is an independent monitoring service and is not affiliated with, endorsed by, or sponsored by Iterable.