Most CRM teams find out their lifecycle journeys are broken after customers tell them. A welcome flow stops sending. A password reset never arrives. A cart abandonment email fires twice. The platform reports success, but the customer experience is wrong.
A journey audit is the only way to know what is actually running before a customer notices it is not. Here is the checklist we use.
What a lifecycle journey audit actually checks
A journey audit is not a campaign review. Campaign reviews check strategy, copy, segmentation, and send time. Those matter, but they do not catch the failure modes that break journeys silently.
A journey audit checks whether the infrastructure that executes your campaign does what you told it to do. Does the trigger fire when it should? Does the send actually go out? Does the right content render for the right person? Do the links work? Does the flow continue to the next step without dropping anyone?
These are not questions the platform can answer honestly, because the platform only knows what it tried to do. A journey audit checks what the customer received.
The five-step CRM journey audit framework
Map every step in the journey
Start by documenting the entire flow from entry to exit. For each step, record the trigger condition, delay duration, send type (email or other channel), template name, and next step or exit condition. If your journey uses branches, record every path.
This sounds basic, but most CRM teams discover gaps here. A Braze Canvas might have a delay node configured in hours when the brief called for days. A Klaviyo flow might have a conditional split that no longer matches the segment definition it was built against. Mapping the journey on paper, independent of the platform's visual editor, surfaces these mismatches immediately.
Identify silent-failure risk points
Not every step in a journey carries the same risk. Some failures are visible immediately. Others hide for weeks. Prioritise the points where a failure would be invisible to the platform but obvious to the customer.
High-risk points include entry triggers (especially event-based triggers that depend on external systems), merge tag resolution (where personalisation pulls from a data source that might be stale or incomplete), link destinations (especially if they pass through redirects or campaign parameters), and delay nodes (where timezone mismatches or incorrect duration settings can shift a send window without flagging an error).
In one case, a broadcaster's Saturday-morning newsletter failed to send for the first hour of the scheduled window. The platform reported success. The inbox stayed empty. The trigger had fired, but a downstream rate-limit throttle held the batch without logging it as delayed. No alert fired because the platform considered the job in progress. The failure was silent until the operator checked manually.
Define acceptable vs broken states for each step
For every step in the journey, write down what "working correctly" looks like in measurable terms. This is not the same as defining success metrics. Success metrics measure outcomes (open rate, conversion). Acceptable states measure execution (send went out within 5 minutes of trigger, correct template rendered, link resolved to intended destination).
Be specific. "Email sends on time" is not specific enough. "Email sends within 2 minutes of user completing signup form" is. "Merge tag populates correctly" is not specific enough. "First name field resolves to a non-empty string in 100% of sends" is.
A broken state is anything outside the acceptable range. If the acceptable send window is 2 minutes and a send goes out 30 minutes later, that is broken even if the platform does not flag it. Late arrival in the first 30 minutes of a send window is almost always a scheduling or timezone issue, not a genuine infrastructure breakage, but it is still a deviation worth catching.
Set monitoring checkpoints
Once you know what acceptable looks like, decide how you will verify it. The platform's logs and dashboards are not sufficient, because they measure what the platform attempted, not what the customer received.
Monitoring checkpoints are test identities placed inside the live journey. When the journey runs, these identities receive the same experience as a real customer. The difference is that their inbox is instrumented, so you can measure send timing, content rendering, and link integrity end to end.
For high-value journeys (welcome flows, transactional emails, revenue-driving automations), set checkpoints at every major step. For lower-priority journeys, checkpoints at entry and exit are often enough. The goal is not to instrument every possible failure mode. The goal is to catch the failures that would otherwise stay silent until a customer complains.
Run the audit on a schedule
A journey audit is not a one-time exercise. Journeys drift. Data sources change. Templates get updated. Triggers that worked last month stop working this month, often without any deliberate change to the journey itself.
Run the audit monthly for stable journeys. Run it weekly for journeys under active development or connected to frequently changing data sources. If a journey touches external systems (a CDP, a product catalogue, a pricing API), run the audit after every upstream deployment.
The audit does not need to be manual. Once you have documented the acceptable states for each step, the checkpoint monitoring can run continuously in the background. The audit becomes a review of the monitoring data, not a manual test of the journey.
What to do when the audit finds a problem
When a checkpoint flags a deviation, treat it as a signal worth investigating, not an automatic rollback. Not every deviation is a failure. Some are expected behaviour under edge-case conditions.
Start by checking whether the deviation matches a known pattern. A delay of 5 minutes when the acceptable window is 2 minutes might indicate infrastructure load, not a broken journey. A missing merge tag in 1% of sends might indicate incomplete customer records, not a template error.
If the deviation is consistent across multiple checkpoints or affects a significant portion of real customer sends, escalate it. Treat it the same way you would treat a spike in hard bounces or a drop in open rate, with the same priority and the same cross-functional review.
The hardest pattern to catch is the absence of an expected send. If a journey is supposed to send 500 emails per day and only sends 480, most platforms will not flag it. The missing 20 might be customers who qualified for the journey but were silently excluded by a filter, a rate limit, or a duplicate-suppression rule that nobody documented. Heartbeat monitoring catches this by tracking expected volume against actual volume over time, and alerting when the gap exceeds a threshold.
Why lifecycle journey audits matter more than campaign reviews
Campaign reviews are still necessary. You still need to check copy, segmentation, send time, and creative before a journey goes live. But campaign reviews do not catch the failure modes that actually cost revenue.
A campaign with perfect copy and targeting that never sends is worthless. A journey with a broken merge tag that personalises to an empty string damages trust. A password reset email that arrives 45 minutes late costs the customer and the support team time.
These are infrastructure failures, not strategy failures. They show up in the customer experience before they show up in dashboards. The only way to catch them early is to audit the journey from the customer's perspective, using the same infrastructure the customer uses, and measuring the same outcomes the customer sees.
That is what a lifecycle journey audit does. It tells you whether the system is doing what you think it is doing, independent of what the platform reports. For CRM teams running high-volume or high-value journeys, that independent view is the difference between finding failures before customers do and finding out from support tickets.
Audit your journeys with independent monitoring
Telltide runs the checkpoint monitoring layer described in this framework. Place test identities inside your live journeys in Klaviyo, Braze, Salesforce Marketing Cloud, HubSpot, or Iterable. Telltide watches what they receive, measures it against your acceptable states, and alerts you when something deviates. Start monitoring free at telltide.io.