Journey Governance
Lifecycle operations and monitoring
Keep live customer journeys visible, monitor entry and sending separately, respond to data outages and review operational faults.
Lifecycle operations means knowing which customer journeys can affect people now, whether eligible customers enter and progress, and what to do when data or sending fails. Keep a current record of each sending path, monitor entry and delivery separately, and let the team hold messages that may have become inaccurate.
Keep an operating view
For each active journey, record its purpose, entry source, owner, sending systems, exit rule and any messages that may wait. Include separately scheduled sends that can reach the same customers, and note when the configuration was last checked.
The detailed method belongs in the journey inventory; this operating view should let someone locate a path during an incident.
A running workflow does not mean a delivered message. In Customer.io, an automation can run while an individual message is set to Queue Draft.
In Customer.io, the automations list can be filtered by name, description, trigger, status, topic, tags and object types. Icons identify trigger types; listed message and action types show what a workflow can do.
The list’s table view can show selected automation data and metrics, with adjustable date ranges and sort order. These display settings affect your view only, not other team members’ views.
Monitor the path
| Question | Signal to inspect | Possible explanation |
|---|---|---|
| Are qualifying actions being recorded? | Source events and processing delay | Changed activity, tracking or feed failure |
| Are eligible customers entering? | Entries beside an independently counted eligible population | Trigger, filter, identity or timing problem |
| Are journeys progressing? | Waiting, skipped and exited instances | Expected delay, exclusion or broken condition |
| Are messages leaving? | Drafted, queued, attempted, sent and failed states | Different stages needing different responses |
Define the counting unit and date basis for each comparison. A person, account and journey instance are different units.
In Customer.io, a queued message has not been counted as sent; its workspace performance dashboard also separates incoming data, outgoing messages and processing delays. Other tools may use different status names.
Set alerts against each journey’s normal rhythm and the consequence of a missed or wrong message. Compare like periods and inspect customer histories before declaring an incident.
Fewer entries may reflect fewer qualifying actions; steady send volume can still conceal stale messages.
The Overview tab shows active issues, current incoming data and outgoing messages, processing speed, and work running now. Processing delay covers the previous 24 hours for both data ingress and outgoing-message queues.
The dashboard distinguishes Healthy, Busy and Slow performance. Busy means the workspace is processing a higher-than-normal volume of events and may have delays.
Slow performance indicates major processing delays and at least one error needing attention. Check active issues when the status shows a problem, then use the Data and Messaging tabs to inspect daily ingress and messaging-output metrics.
Keep individual delivery status separate from aggregated performance metrics. Customer.io records the progress of each delivery and journey, while metrics aggregate status information; a message can have a status before it has generated metrics.
Statuses and metrics also vary by message type, and some reporting depends on information from the delivery provider or recipient.
Customer.io Message Statuses vs. Delivery Performance
- Status: Drafted
- Message not yet queued; may be held for review
- Status: Queued
- Message awaiting delivery; not yet sent
- Status: Sent
- Message delivered to recipient via provider
- Status: Failed
- Delivery attempt failed; may require manual intervention
- Performance: Healthy
- Normal processing; no delays or errors
- Performance: Busy
- Higher-than-normal volume; potential delays
- Performance: Slow
- Major delays or errors requiring attention
Lifecycle Journey Monitoring Workflow
- 1. Verify Source Events — Check if qualifying actions are being tracked and processed
- 2. Confirm Eligible Entry — Validate customers meet trigger conditions and filters
- 3. Track Progression — Monitor waiting, skipped or exited journey instances
- 4. Assess Message Delivery — Review draft, queued, attempted, sent and failed states
- 5. Trigger Alerts — Set up notifications for deviations from normal rhythm
Key Metrics in Customer.io Workspace Dashboard
- Incoming Data (Last 24h)
- Number of events ingested into the system
- Outgoing Messages (Last 24h)
- Total messages sent or attempted
- Processing Delay
- Time between event receipt and message delivery
- Active Issues
- Current alerts or errors requiring attention
Respond to a break
Trace a change from source action through event delivery, entry rule, journey step and delivery provider. Record the first affected time, journeys and customer states. Hold messages still under your control when their claims depend on unreliable data.
After a data outage, confirm service has resumed and assess whether affected journeys and messages are safe to continue.
For Australian commercial email and SMS, check current ACMA guidance and your organisation’s records before sending recovery communications.
When using Customer.io’s Queue Draft behaviour, drafts are retained for 30 days and then deleted. Changing a live message to Send Automatically affects future messages, not drafts already waiting; those require a separate manual send decision.
Conversely, switching a live message to Queue Draft affects future messages, while people continue moving through the automation and a draft can become irrelevant.
Event timing can affect whether an event triggers entry in Customer.io automations. Check the relevant documentation when timing may be involved.
Using Queue Draft in Customer.io: Pros and Cons
- ProsAllows message review before sending; drafts retained for 30 days; reduces risk of inaccurate messages
- ConsChanges to live settings don’t affect existing drafts; drafts may become irrelevant if customer moves through journey; requires manual send decision
Post-Outage Recovery Checklist (Australia)
- Confirm service restorationVerify data feeds and messaging systems are back online
- Review affected journeysAssess whether messages depend on unreliable or stale data
- Check ACMA complianceEnsure recovery communications follow current spam guidelines
- Decide on manual sendsOnly release queued drafts after validation; consider timing and relevance
- Document decisionsRecord who approved what and why, for audit and governance
Review the operation
Review active journeys at a cadence suited to their risk, and after material changes or incidents. Compare each journey’s purpose with its current entry, exit and message rules.
Examine missed entries, stale sends, data holds and unresolved exceptions. Record each repair with an owner and a check that will show whether it worked.
Entries, sends and skips describe what the system did. A later customer outcome alone does not show that the journey caused it.
In this guide
- Building an inventory of active customer journeysBuild and verify a register of active customer journeys, including entry rules, waiting messages, sending systems and owners.
- Monitoring unexpected drops in journey entryDiagnose a fall in lifecycle journey entry by checking eligibility, event delivery, filters, repeat entry and reporting units.
- Checking message queues after a data outageSeparate delayed data from message states after an outage, triage stale sends and verify a controlled restart.
- Running a quarterly lifecycle journey reviewRun a quarterly review of live journeys using current rules, exceptions, customer histories and specific follow-up decisions.
