Independent monitoring for Iterable workflows and triggered campaigns
Iterable makes it easy to build multi-step workflows with filters, delays and branching logic. Each of those components can also break quietly. Iterable reports the workflow as active and the step as sent. The customer's inbox is empty.
Telltide confirms what actually arrived, step by step, from the inbox.
The flows that matter
Iterable sends our customers monitor
Iterable's email surface stretches across workflows, triggered campaigns, blast campaigns and transactional API calls. Each surface has its own quiet failure modes.
Iterable workflows
The most common monitored surface. Workflow steps fire on entry events, delays, filter nodes and split branches. A field rename or a filter misconfiguration can quietly drop users out of the path. The workflow shows as active. The step never fires.
Triggered campaigns
Fired on custom events like purchase completed, cart abandoned, subscription upgraded. When the event schema changes, when the trigger property is renamed, or when the event stops firing, the campaign sits idle. Iterable logs nothing. The customer waits.
Transactional API sends
Order confirmations, password resets, booking receipts. Often wired up by an engineering team that does not own the Iterable workspace day to day. When the API integration breaks, Iterable returns an error code to the caller. If nobody is watching that log, the customer sees nothing.
Blast campaigns
Scheduled sends fired to a static list or a dynamic segment. If the segment criteria change and the audience drops to zero, the campaign fires to nobody. The send log shows zero recipients. No alert fires.
Re-engagement workflow paths
Long-cycle workflows enrolled on inactivity windows. The entry criteria can be edited with the best of intentions, and a single boolean swap can quietly disqualify whole cohorts of users.
Journey reminder steps
Workflow nodes configured to send a reminder after a user action. When the action event schema changes, when the reminder delay is miscalculated, or when the filter condition no longer matches, the reminder skips silently.
How it goes wrong
Common Iterable silent-failure patterns
Iterable rarely throws errors when a workflow step simply does not fire. These are the failure modes we see most often in live workflows.
Filter node logic reverses after edit
A workflow filter is built on a user profile field. An engineer renames the field in the data schema. The workflow is updated to reference the new field name, but the filter logic is accidentally reversed. Half the users now pass when they should fail. The workflow reports full sends on both paths.
Delay node miscalculation skips the step
A workflow delay step is configured to wait for a relative time offset. The calculation references a user profile field that is null for a subset of users. Those users skip the delay and advance immediately to the next step, which has its own entry condition that now fails. The entire cohort drops out of the workflow silently.
Update profile step overwrites the trigger property
A workflow step updates a user profile field. The next step in the workflow is triggered on that same field equalling a specific value. The update step writes a different value than expected. The trigger condition never evaluates true. The step sits idle. Iterable logs the update as successful and the trigger as not met.
Exit rule ejects users before the email step
A workflow exit rule is added to remove users on a specific event. The event criteria are slightly broader than intended. Users get ejected from the workflow before the email step fires. The workflow is technically working as configured. The customer never sees the email.
Handlebars template references missing user field
A workflow email step includes a Handlebars template that references a user profile field. The field is deprecated and removed from the user schema. The template renders with a blank value. Iterable logs the send as delivered. The email arrives with a broken merge tag.
Split test node blocks workflow progression
A workflow includes a split test node before an email step. The split test is configured to wait for a conversion event before advancing. The conversion event never fires because the tracking pixel is removed from the landing page. The workflow progression halts. The email never fires.
Workflow observability vs native analytics
What Iterable's dashboards show, and what they miss
Iterable's workflow analytics are detailed. They show you every step, every conversion, every exit. What they cannot show you is whether the email that Iterable logged as delivered actually arrived at the inbox in the shape you intended.
Iterable reports delivery, not arrival
When Iterable logs an email as delivered, it means the receiving mail server accepted the message. It does not mean the message reached the inbox. It does not mean the message was not filtered to spam. It does not mean the message rendered correctly. Inbox-side monitoring confirms all three.
Workflow performance metrics aggregate over time
Iterable analytics show you conversion rates, open rates, click rates. They do not show you the individual email that failed to arrive for a single user. If a workflow step fires to a thousand users and one user never receives it, the aggregate metrics look healthy. That one user is your highest-value customer.
Exit rules and suppressions 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 exit rule, you will not know until you actively review the workflow exit logs. Inbox-side monitoring alerts you within 15 minutes when an expected send does not arrive.
Handlebars errors render silently
When a Handlebars template references a missing user profile field, Iterable renders the template with a blank value. The email is logged as delivered. The customer receives an email with a broken personalisation block. Iterable does not flag this as an error. Inbox-side monitoring compares the arrived email against a reference template and alerts on structural deviation.
How Telltide fits
A inbox-side monitor for every workflow step
Telltide does not sit inside Iterable. It runs alongside, watching the inbox for the sends Iterable says it made.
Add a monitored user to your Iterable list
Telltide gives you a unique inbox address per monitor. You create a user profile with that address in Iterable, give it the relevant profile fields or event history, and let it enter the workflow naturally at the entry step.
Set the expected arrival window
For a transactional API send, that might be five minutes. For a workflow step with a 24-hour delay, that arrival window is 24 hours plus a buffer. For a reminder step with complex filter logic, you set a wider window to account for processing time. Per monitor.
Get alerted when the inbox disagrees with Iterable
If the email does not arrive in the window, an alert fires. If the content is corrupt against the reference template, an alert fires. If the email arrives twice, an alert fires. The workflow dashboard might still report the step as healthy. The alert tells you what is actually arriving at the inbox.
Monitoring specific workflow components
Filter nodes, delay steps and update-profile actions
Each workflow component has its own monitoring considerations. Here is how to set up a Telltide monitor for the components that break most often.
Watch the step after the filter
If a workflow step includes a filter that checks a user profile field, create a Telltide monitor for the email step that follows the filter. Give the monitored user profile the field value that should pass the filter. If the filter logic breaks, the monitor will alert on the missing email.
Set the arrival window to match the delay duration
If a workflow step includes a 48-hour delay, set the Telltide monitor's expected arrival window to 48 hours plus a 30-minute buffer. The monitor will alert if the email arrives too early, which indicates the delay was skipped, or too late, which indicates the step fired but was delayed further downstream.
Monitor each branch path separately
If a workflow splits users into two branches based on a profile field, create two Telltide monitors. Give each monitor a unique user profile with the field value that qualifies it for one branch. Watch both branches independently. If one branch stops firing, you will know immediately which variant is broken.
Fire the entry event from a test harness
For a workflow that enters users on a custom event like subscription created, fire the event from a test script or an API client on a cadence. The Telltide user profile receives the event, enters the workflow, and the monitor confirms the first step fires. If the event schema changes and the workflow stops entering users, the monitor will catch it.
Template and content monitoring
Catching broken merge tags and layout drift
Iterable workflows often reference user profile fields in Handlebars templates. When those fields go missing, the template renders with blank values. Telltide compares the arrived email against a reference snapshot and alerts on structural deviation.
Set a reference template on first arrival
When you create a Telltide monitor, the first email that arrives becomes the reference template. Subsequent emails are compared against that reference. If a merge tag breaks, if a layout module is removed, if a link changes, the monitor alerts.
Update the reference when you intentionally change the template
When you deploy a new version of a workflow email, update the Telltide reference template. The monitor will use the new reference for future comparisons. This prevents false positives when you make intentional changes.
Monitor links and asset URLs
Telltide checks every link in the arrived email. If a link returns a 404, if an image asset fails to load, if a tracking parameter is missing, the monitor alerts. This catches broken links that Iterable's preview pane does not catch because the preview pane does not load external assets.
Pair it with
Concepts and use cases worth reading
The reading below covers the underlying concepts and the practical applications for Iterable monitoring.
- Triggered flow: how event-driven workflows differ from scheduled sends and where they break.
- Monitor by ESP: guides for other platforms if you send from multiple systems.
- How monitoring approaches compare: where native analytics end and where independent monitoring picks up.
FAQ
Common questions about monitoring Iterable
Doesn't Iterable's analytics show me whether emails went out?
Iterable reports on what its send infrastructure attempted and what it logged as delivered. It cannot confirm what arrived at a real inbox, when, or in what condition. Inbox-side monitoring closes that gap by watching the inbox itself.
What Iterable sends can I monitor?
Iterable workflows, triggered campaigns, blast campaigns, transactional emails sent via API, and journey steps. Anywhere Iterable dispatches an email, Telltide can confirm whether it arrived.
Do I need to grant Iterable API access or install a connector?
No. Telltide is independent of your Iterable workspace. You add a Telltide monitoring email as a user profile in the relevant list or workflow audience. We never log into your Iterable account.
How do I monitor an Iterable workflow with filter steps?
Create a user profile for the Telltide monitoring address. Enter it into the workflow at the entry step. Set the expected arrival window in Telltide to match the filter and delay logic. The monitor confirms each subsequent workflow step fires as configured.