> For the complete documentation index, see [llms.txt](https://docs.dinmo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dinmo.io/journeys/monitoring-and-troubleshooting.md). # Monitor and troubleshoot a Journey Once your Journey is published, you can monitor its activity, understand where profiles are, and investigate unexpected results. DinMo provides three complementary views: * The Journey canvas shows the latest known distribution of profiles. * The **Activity** panel provides detailed metrics for a selected step. * **Run history** provides information about each execution of the Journey. ## Monitor activity Open **Activity** from the Journey header to review Journey-level totals. To inspect one step, select it on the canvas and open its **Activity** tab. Use **Date range** to choose: * **Last 7 days** * **Last 30 days**, selected by default * **Since launch** * **Custom range** Date boundaries follow the workspace timezone. The Journey-level view shows **Entered** and **Exited** totals. Each metric includes the total for the selected date range and the value from the latest successful run. The step-level view displays one metric according to the step type: * **Entered** for Start * **Exited** for Stop * **Passed through** for every other step The timestamp below the metrics identifies the latest successful run included in the display. Activity figures are not updated in real time. ### Understand activity notices The Activity panel may display a notice instead of, or alongside, the metrics: * **No successful run**: the Journey has not completed a successful run yet. * **Run in progress**: the latest run is scheduled, queued, or running. The displayed current state may not include its results yet. * **Latest run failed**: the current state still reflects the previous successful run. * **Partial activity data**: some earlier executions are not included in the displayed metrics. * **Statistics unavailable**: activity metrics could not be calculated for the selected step. Use the notice and the last-updated timestamp before drawing conclusions from the figures. ## Review the run history When **Run history** is available in your workspace, open it from the Journey header to review previous executions.
Journey run history table showing version, mode, status, and profile progression metrics

Run history lets you compare Journey executions and the version used for each run.

For each run, you can see: * **Started**: when the execution started. * **Version**: the Journey version used for the execution. * **Mode**: the type of execution. Test executions are identified as simulations. * **Status**: the combined outcome of the Journey evaluation and its expected audience activations. See the status definitions below. * **Entered**: profiles that entered the Journey during the run. * **Advanced**: profiles that progressed to another step. * **Exited**: profiles that left the Journey. * **Finished**: profiles that reached the end of a path. * **Actions**: actions executed by Activate steps. * **Audience activations**: the number of audience activations associated with the run. Select the activation count to review each Activate step and destination. The details show the membership policy and every add or removal operation, including its status, extracted and loaded records, source issues, destination issues, and any reported error. A dash means that the information was not reported for that run, which may be the case for some earlier executions. ### Understand run statuses The Journeys list shows the status of the latest real run. Simulations do not update this status. * **Pending first run**: no real execution has started yet. * **Running**: the Journey evaluation or at least one expected activation is scheduled, queued, or running. * **Success**: the evaluation succeeded and every expected activation completed without a technical failure. A run with no activation to execute can also be successful. * **N activations failed**: the evaluation succeeded and all activation operations finished, but one or more activations failed. The label shows the number of failed activations. * **Failed**: Journey preparation or evaluation failed. * **Canceled**: the execution was canceled. Select the activation count or failure detail to identify the affected Activate step, destination, operation, and reported error. {% hint style="warning" %} A **Success** status confirms that the Journey evaluation and its expected activations completed without a technical failure. It does not necessarily mean that profiles entered the Journey, progressed, or triggered an action. {% endhint %} For example, a successful run with no new entries may simply mean that no profile matched the entry rules at that time. ### Inspect why a profile entered In the profile inspector, select an occurrence to review the events that contributed to an event-based entry. The **Contributing events** section shows the total number of contributing events. Each displayed event includes its stable event ID, event source ID, and occurrence time. If the complete list is longer than the displayed selection, DinMo indicates how many events are shown. All contributing events remain recorded in the event ledger, but their raw payloads are not displayed. The inspector also indicates the date from which event deduplication is guaranteed. Events before that date are outside the recorded coverage, so an older occurrence may not provide a complete contributing-event history. Audience-only occurrences do not display contributing events. ## Investigate unexpected behavior Start with the symptom you observe, then compare the Journey canvas, the selected step's Activity panel, and the run history. ### No profiles entered the Journey Check that: 1. The latest run completed successfully. 2. Enrollment is open and the Journey is not paused. 3. The entry rules match profiles in the source model. 4. The source data was refreshed before the Journey ran. 5. You are reviewing the version used by the latest run. If re-entry is allowed, also check that the configured re-entry delay has elapsed. ### Profiles are not progressing Select the step where profiles are currently located and open its **Activity** tab. Profiles may legitimately remain at a: * **Wait** step until its duration has elapsed. * **Pause Until** step until the expected event occurs or the timeout is reached. Also check whether the Journey is paused or whether its latest run is still in progress. ### Fewer actions were executed than expected Check that profiles: 1. Entered the Journey. 2. Reached the relevant Activate step. 3. Did not exit at an earlier step. 4. Matched the branch leading to that action. Then verify the Activate step configuration and inspect the latest run for a failure or error details. ### Activity figures appear outdated Check: * The timestamp of the latest successful run. * Whether another run is currently in progress. * Whether the latest run failed. * Whether the Activity panel reports partial or unavailable statistics. * Which Journey version was used for the execution. The canvas and Activity panel may continue to show the previous successful state while a newer run is running or after it has failed. ### A run failed Open the failed run and review its error details when they are available. Record the following information before investigating or contacting support: * The execution date and time. * The Journey version. * The error code and message. Investigate the cause before triggering another run, as the same configuration may produce the same failure again. ## Resolve validation issues Before publication, select **View errors** to open the validation panel. Selecting an issue helps you locate the related step on the canvas.
Journey validation panel listing blocking errors and non-blocking warnings

Resolve every error before publishing and review each warning against the intended Journey behavior.

Validation issues are divided into two categories: | Type | Effect | Recommended action | | ----------- | ----------------------------------------------------------- | ------------------------------------------------------ | | **Error** | Blocks publication | Resolve it before publishing | | **Warning** | Does not block publication, but identifies a potential risk | Review it and confirm that the behavior is intentional | Common blocking errors include: * A missing custom Journey name. * A Start step without a configured entry audience or event. * An incomplete step configuration. * A branch that does not end with a Stop step. * An invalid Journey structure or exit rule. Warnings can highlight designs that are valid but may need additional review. For example, DinMo may warn you when: * The same destination is used in multiple Activate steps. * A Segment step contains only one group. * A path contains a long or unusual sequence of Wait steps. * A branch contains no Activate step. * Re-entry is enabled without a delay before the first activation. After correcting an issue, review the validation panel again. Resolving one configuration problem may reveal another issue elsewhere in the Journey. ## Related pages * [Configure entry, re-entry, and exit rules](/journeys/entry-rules.md) * [Configure Journey steps and branches](/journeys/steps-and-branches.md) * [Publish and manage a Journey](/journeys/publish-pause-and-resume-a-journey.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dinmo.io/journeys/monitoring-and-troubleshooting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.