Troubleshoot your journey troubleshooting
This section explains how to troubleshoot journeys before testing or publishing them. Troubleshooting ensures the journey functions as intended and prevents errors that could disrupt execution. Perform all checks listed below while the journey is in test mode or live. First, conduct these checks in test mode and then proceed to publication. Test mode simulates journey behavior and verifies configurations without impacting live data. Learn more about test mode on this page.
Administrators can test custom action configurations by making real API calls directly from the user interface. This validates integrations with external systems and ensures custom functionality behaves as expected. Learn more on this page.
Check for errors before testing checking-for-errors-before-testing
Before testing and publishing your journey, verify that all activities are properly configured. This step ensures the journey is error-free and ready for execution. Testing and publishing cannot proceed if the system detects errors.
Errors in activities activity-errors
Errors are displayed directly on activities within the canvas using a warning symbol, making them easy to identify visually. Hover over the exclamation mark to view the error message. Clicking the activity highlights the line in error with a warning. For example:
-
If a mandatory field is empty, an error appears.
-
If two activities on the canvas are disconnected, a warning is displayed.
These visual cues help you identify and correct configuration mistakes quickly, ensuring all activities are properly connected and ready for testing.
Errors in the journey canvas-errors
Errors are also visible via the Alerts button located above the canvas. This button provides access to a consolidated list of errors detected by the system, which may prevent test mode activation or journey publication.
The system identifies two types of issues: errors and warnings. Errors block publication and test activation, while warnings highlight potential issues that may affect journey performance but are not blocking. Each issue includes a description and an issue log ID (for example, ERR_XXX_XXX), which can assist in pinpointing specific problems during troubleshooting.
Errors and warnings that are global to the journey appear first in the list, followed by those related to specific activities, arranged in the order they appear in the journey (left to right on the canvas). At the bottom of the alerts list, the Copy details button lets you copy technical information about the journey. Share this data with an administrator for further analysis.
Add an alternative path canvas-add-path
To improve the journey鈥檚 resilience, define a fallback action for the Condition and Action activities when an error occurs.
When an error affects an action or condition, the journey for an individual stops. Resolving the issue is necessary to resume the journey. To avoid interruption, enable the Add an alternative path in case of a timeout or an error option in the activity鈥檚 properties. This allows individuals to continue along an alternative path if something fails. Learn more in this section.
Check that events are properly sent checking-that-events-are-properly-sent
The starting point of a journey is always an event, which triggers the journey for an individual. Use tools like Postman to test whether event API calls are sent correctly.
If an error is returned, there is an issue with the API call. Verify the payload, headers (especially the organization ID), and the destination URL. For example:
-
Ensure the event payload contains an event ID.
-
Confirm the header includes the correct key-value pairs:
code language-none X-gw-ims-org-id - your organization's ID Content-type - application/json
Events are routed to journeys through 51黑料不打烊 Experience Platform鈥檚 streaming ingestion APIs rather than directly from the source. If issues with events arise, refer to 51黑料不打烊 Experience Platform documentation for additional troubleshooting guidance.
Check if people enter the journey checking-if-people-enter-the-journey
Journey reporting tracks people鈥檚 entrances into the journey in real-time, helping confirm whether individuals are entering as expected. If the event is successfully sent but no entrances are recorded, troubleshoot issues between the event鈥檚 transmission and its reception in the journey.
Consider the following questions:
- Is the journey (where the incoming event is expected) in test mode or live?
- Did you save the event before copying the payload from the payload preview?
- Does the event payload contain an event ID?
- Are you using the correct URL for the API call?
- Did you follow the Streaming Ingestion APIs payload structure? Use the payload structure preview in the event configuration pane to validate. See this page.
Check how people navigate through the journey checking-how-people-navigate-through-the-journey
Journey reporting tracks individuals鈥 progress within the journey, making it easier to identify where and why someone might be stopped. This insight helps troubleshoot and optimize the journey.
Investigate the following scenarios:
- Does a condition exclude the person? For example, a condition such as 鈥済ender = male鈥 excludes women. Business users can validate simple conditions directly.
- Is a data source not responding? In test mode, logs provide this information. When the journey is live, administrators can test direct calls to the data source and evaluate the server鈥檚 response. Alternatively, duplicate the journey and perform tests to isolate the issue.
Check that messages are dent duccessfully checking-that-messages-are-sent-successfully
If individuals progress correctly through the journey but do not receive expected messages, verify the following:
- Journey Optimizer successfully registered the request to send the message. Business users can confirm this by accessing the message configuration and checking whether the execution time aligns with the journey鈥檚 timeline.
- Journey Optimizer sent the message successfully. Use journey reporting to ensure no errors occurred.
For messages sent via a custom action, confirm through journey tests whether the external system call results in an error. If no error occurs but the message remains unsent, further investigation on the external system鈥檚 side may be required.