Monitoring and runs

Once a journey is live, you'll want to see it working — who's moving through it, where they've gotten stuck, and whether anything failed. Every journey has its own monitoring view for exactly that, and there's a separate list that pulls together failed runs from every journey at once, so you don't have to check each one individually.

Watching a journey run

Open a journey and go to its monitoring view to see a running tally of contacts currently in the journey, waiting at a step, completed, or failed, along with a table of every run — one row per contact, showing their status, current step, when they enrolled, and when they were last active. Click a row to open a detail panel showing the outcome of each step that contact has passed through so far.

From that detail panel, you can also open a full contact trace — a decision-by-decision view of everything worked out for that contact across every journey that has touched them, including why each choice was made at every branch along the way. It's the most detailed view available for a single contact, useful when a result looks surprising and you want to know exactly why.

The monitoring view also has a tab for incoming events — the actions and signals (like a form submission or an email click) that can start or move a journey along — showing how many arrived recently and how many actually matched and triggered something. If an event came in but didn't match, expand it to see why, which helps explain a contact you expected to enter a journey but didn't.

Events that matched but started nothing

The same tab reports a third number: Skipped. A skipped event did reach the journey's trigger — so there's nothing wrong with how the trigger is set up — and then started no run for that contact. The usual reason is that the contact is already in the journey, or went through it once already and Allow re-entry is off, which is the default. With re-entry on, a trigger event is also skipped when the contact entered the journey less than 30 seconds ago (broadcasts, scheduled entries and manual entries aren't held back this way), and an event the journey caused itself (a receipt for its own email, a tag its own step applied) never re-starts it — see Re-entry limits and self-triggering.

This is worth knowing because a skipped event is otherwise invisible: no run appears, no branch counter moves, and the journey looks exactly as if it had run and taken a different path. It catches people out most often while testing — submitting the same form again with your own address only enrols you the first time, so every later attempt looks like the journey ignored what you changed.

When any event has been skipped, the Events tab shows the count next to its name so you can see it without opening the tab. Expand a row marked Skipped for that event's exact reason. To let the same contact come back through, switch on Allow re-entry in journey settings — click an empty part of the canvas, with no step selected, to reach them.

If the journey uses an Approval gate, pending approvals also show up in this same monitoring view. See Approvals for how to review those requests — not covered again here.

Finding failed runs

A run fails when a contact's journey hits a step it couldn't complete — for example, a message that couldn't be sent. Failed runs for a single journey show up in that journey's monitoring view, with the reason for the failure and a one-click Retry. To see every failed run across all of your journeys in one place instead, use the Failed runs list under Automations, which lets you filter to runs still eligible for a retry versus ones that have stopped for good, and retry or stop a run from there.

Retry limits

Retry from failed step picks the run up again at the step that failed. Each run can be retried up to 3 times; the run's detail panel shows how many it has used ("Retried 2 of 3 times"). After the third, Retry is replaced by a short note saying so — a run that keeps failing at the same step needs the journey (or the contact's data) fixed, not another try. Fix it, then enrol the contact again.

A run that stopped on a loop limit can't be retried at all: retrying would only send it round the same loop again. Its detail panel and the Failures tab show why in place of the Retry button. A run stopped because one step was held too long is not a loop, so Retry stays available for it — and so does one stopped because the service kept stopping while it worked on a step.

Loop limits

A journey can't be published with a loop in it unless a Go to step closes the loop (see Branching and timing). A journey published before that rule existed keeps running, so every run also carries its own limits, counted for the whole life of the run — across every wait and pause:

A run may visit one step at most 50 times. A contact going round a loop is stopped at the step it would have reached for the 51st time — usually the first step of the loop. A journey whose own Go to steps need more gets more: two Go to steps of 25 back to the same step visit it 51 times, and that run finishes normally.
A run may take at most 1,000 steps in all — more for a large journey, enough for every step on every pass its Go to steps allow.
A run may take 200 steps in a row without pausing (at a wait, an approval or similar). A loop with no wait in it stops there.
A Go to step stops the run once it has jumped back as many times as its Max iterations.

A run stopped by any of these shows as failed at the step where it stopped, with a reason such as "Stopped at “Send reminder”: a run may visit one step at most 50 times, and this one kept coming back here." Change the journey so the loop finishes, publish it as a new version, then enrol the contact again.

A step held too long

A send can be held — re-checked later rather than sent now — by quiet hours, a frequency cap, a contact who hasn't yet confirmed their subscription, or the checks every send must pass being unavailable for a while. A held send is re-checked when the hold ends (the end of quiet hours, the frequency-cap window), or every 15 minutes while the checks can't be run. A hold doesn't last for ever:

1 day while the checks can't be run. If the checks a send must pass before it goes out can't be run for a whole day, the step stops holding.
8 days in all, whatever held it — quiet hours, a frequency cap and a pending confirmation can each legitimately last days, but not longer than that. The first thing that held the send is always waited out, though: a frequency cap counted over more than 8 days holds the send to the end of its period (31 days at the most), and only after that does the 8-day limit apply.

A re-check that comes more than an hour late — because its journey was paused, or the service that runs journeys was down — doesn't count the time it was late towards these limits, so resuming a journey after a long pause re-checks its held sends rather than failing them. A re-check that is late by less than an hour counts in full.

A step that reaches either limit takes its error path if you've connected one, so the journey can carry on for that contact. Without one, the run stops and shows as failed at that step with a reason such as "Stopped at “Send reminder”: it was held for more than 8 days (the frequency cap)… — not a loop in the journey. Retry picks the step up again." A hold whose release time can't even be read stops the step straight away, with a reason saying so, instead of being re-checked on a guess.

Each re-check is also a step, so a send held again and again can bring the run to its step limit. That is not a loop in the journey either, and the reason says so ("it was held and re-checked until the run reached its limit…").

Either way the run is not a loop, so Retry stays available: once whatever held it has cleared, Retry carries on from that step, with the hold's clock started again and room for the run to continue — the re-checks it spent don't count against it.

Metrics

Where a journey sends messages, you can pull up a metrics view for a specific send to see high-level numbers like how many messages went out and how recipients responded — a quick read on performance without digging through individual contact runs.

Pausing and resuming a journey

Pausing a journey from its monitoring view stops all of its in-flight runs, not just new enrollments — every contact currently moving through the journey freezes in place, and no messages send or AI credits get used while it's paused. New contacts also stop enrolling. Resuming picks every run back up from exactly where it froze, so nobody skips a step or repeats one because of the pause.

You can see this in the runs table: while a journey is paused, every run in it shows a Paused status instead of Running or Waiting. A contact who was part-way through a wait keeps that date visible — "Paused · was waiting until 13 Oct" — so you can tell at a glance what each person was in the middle of. The tally above the table gains a Paused count, and the status filters gain a Paused option for listing just those runs. Resuming tells you how many runs it released.

Waits keep counting down while a journey is paused. Pausing holds the contacts, but it doesn't stop the clock: a "wait 7 days" step that was due to finish during the pause still comes due. Nothing happens at the moment it does — the run stays paused — but it's then ready to move, so it continues as soon as you resume. The practical consequence is that a long pause releases everything that came due during it at once when you resume. If you've paused a busy journey for a while, expect a burst of activity on resume rather than a gentle restart.

Anything a contact does while the journey is paused still counts. If a run was waiting for someone to click an email and they click it mid-pause, that's recorded against the run — it isn't lost, and the contact takes the branch their click chose once you resume.

Archiving a journey

Archiving retires a journey for good. Nothing new enrolls in it, its triggers stop listening, and its status becomes Archived.

An archived journey is read-only, and archiving can't be undone. Its monitoring view keeps everything you need to read the history — the journey map, the runs table, events, failures and insights are all still there — but it offers no Edit journey, Pause or Archive button, because there is no way back to a live journey from an archived one. Archive it when you're genuinely done with it, not as a way to park it: pausing is what holds a journey you intend to bring back.

If you want a journey you've archived, clone it from the automations list (the copy button on its row). The copy comes back as a fresh draft you can edit and publish, and the archived original stays where it is with its history intact.

Cancelling a run

Pausing holds every run in a journey; sometimes you want to stop just one contact instead. Open the run from the runs table and choose Cancel run in the detail panel. After you confirm, the contact leaves the journey straight away: any wait it was in the middle of is called off, it stops listening for clicks or replies, a pending approval for it is closed, and none of the steps it hadn't reached yet will run.

You can cancel a run that is running, waiting at a step, or paused. Runs still in flight from an earlier version (after Edit as new version) are cancelled the same way, from that version's runs list. A cancelled run shows a Cancelled status and stays in the runs table so you can still see the steps it completed. It can't be restarted — if you want the contact to go through the journey again, enrol them again (with Allow re-entry on). Starting them yourself through a manual entry works straight away; a trigger event within 30 seconds of when they last entered is held back by the re-entry cooldown. Runs that have already finished, exited or failed have nothing left to cancel, so the option doesn't appear for them.

Cancelling is the way to deal with a run you don't want to continue while the rest of the journey is paused: cancel it first, and resuming the journey releases everyone else without it.

When a step fails after a message went out

If something goes wrong part-way through a step after its message has already been sent, the run is marked failed at that step instead of being tried again on its own, so the contact never gets the same message twice. It shows up with the error in the failed-runs view, where Retry picks it up from that step once you've looked at what happened.

The error shown names what went wrong — the field and the rule it broke, such as "Birthday: bad date". When the database refuses a change, the copy of the contact's record (or the clashing value) that the database attaches to its error is left out. The message can still repeat the value the step tried to write, so glance at it before sharing a screenshot.

When the service stops in the middle of a step

Now and then the service running your journeys restarts while a run is in the middle of a step — during an update, or when it runs out of memory. The run isn't lost: it picks up again from the last step it finished, about a minute later, and an email or text that step had already sent is not sent again — the contact gets it once. A message that had already gone out isn't re-checked when the run picks up again, so it isn't held by quiet hours or by a frequency cap that its own send counted towards. A message that had only been drafted when the service stopped is checked like any other send before it goes out — it can still be held by quiet hours, or not sent at all to a contact who has since unsubscribed or cancelled their registration — and a text whose contact no longer has a mobile number fails at that step with a reason saying so. (A webhook or a team notification that had already gone out can go out a second time.)

If the same run is interrupted 3 times in a row before it gets past the step, it is stopped rather than tried over and over, and shows as failed at that step with a reason like:

Stopped at “Send welcome email”: the run was interrupted 3 times in a row before this step could finish — the service stopped while working on it each time. It was stopped instead of being tried again. Retry picks the step up again.

One interruption on its own never counts against a run: as soon as the run gets past the step, the count starts again from zero. A run stopped this way is not a loop, so Retry is available (it counts towards the run's 3 retries). If the same journey keeps stopping like this, look at the step it stops at — a very large audience or a slow external service behind it is the usual cause.

A run waiting at a Wait step (or a held send, or an AI step waiting for credits) is carried on by a timer. If that timer itself can't be fired — it fails 5 times in a row — the run doesn't wait for ever: it is stopped and shows as failed at that step with a reason starting "the timer that was to carry this run on could not be fired". Retry picks the step up again.

An AI step works the same way: its AI work is picked up again if the service stops while it runs, and after the third interruption in a row the run is stopped at that step with a reason saying the step's worker stopped before it finished every time — so you aren't charged AI credits again and again for work that never completes. Retry picks it up again.

If the AI service has a brief problem while an AI step is working, the step tries the call again itself a few times; if it still gets no usable answer, the run carries on without one — an AI decision takes its default branch, and Generate message produces no message (the run's trace says "No message generated").

If the step doesn't finish within its time limit (2 minutes), or fails for a reason outside the AI call itself, it is tried again, but not straight away: after 30 seconds, then after 2 minutes, so a short outage has time to clear. After the third failed try the run stops at that step, and the step shows why ("The AI step failed 3 times; the last time: …"). A failure that trying again can't fix — your AI credit spend limit has been reached, for example — isn't retried at all: the run stops at once with that reason. Retry picks the step up again once you've dealt with the cause.

AI nodes and credits

Steps like AI decision and Generate message call the AI model for every contact at the moment they run, so they're AI Credits Intensive — a journey with a lot of contacts flowing through one of these steps can use up your AI credits noticeably faster than a journey that only sends static messages.

Running out of AI credits doesn't fail your journeys. When a run reaches an AI node and there aren't enough credits available, that run holds at the step and resumes automatically once credits are available again — availability is re-checked periodically, so you don't have to do anything by hand. It holds the same way when the limit is reached while the step is already running, so it makes no difference whether the credits ran out just before the step or during it. If credits stay unavailable for a long stretch (seven days by default), the run is marked failed and shows up in the failed-runs view instead of holding forever.

If an AI step fails for some other reason — the model couldn't be reached after several tries, or it kept taking too long — the run follows the step's error path when you've connected one on the canvas, exactly as a send step does, so you can route the contact to a fallback message or a notify step. The run only stops and shows as failed when there is no error path to take. Either way the step carries the reason, so the contact trace says what went wrong.

Tips

Use the contact trace when a single contact's outcome looks wrong and you want the full reasoning behind every decision the journey made for them.

FAQ

Q: A journey went live before I felt ready. Can I stop it? A: Yes. Pause it from its monitoring view — that stops new contacts from entering and freezes every run already in flight, so no further messages go out. Resuming picks each run up exactly where it froze. To change the journey itself, use Edit as new version, which pauses the live version and gives you a fresh draft to work on.

Q: One contact's run is misbehaving. Do I have to pause the whole journey? A: Pause it if you need everything to stop right now, then open that contact's run and Cancel run. Resuming afterwards releases every other run and leaves the cancelled one where it is.

Q: Why is there no Retry button on this failed run? A: Either the run has already been retried 3 times, or it stopped on a loop limit, where retrying would only go round the same loop again. The note in place of the button says which. See Retry limits.

Q: A send waited for days and then the run failed. Why? A: The send was held — by quiet hours, a frequency cap, a subscription the contact hadn't confirmed, or because the checks before sending couldn't be run — for longer than a hold may last (8 days in all, 1 day for checks that can't be run). Connect an error path from the send step to decide what happens to the contact then, or press Retry once the cause has cleared. See A step held too long.

Q: A run failed with "the run was interrupted 3 times in a row". Did the contact get the message three times? A: No. A step picked up again after an interruption finds the message it already sent and doesn't send it again. The run stopped because it never got past that step; once you've checked the step, Retry carries on from it. See When the service stops in the middle of a step.

Q: I paused a journey for two weeks. Why did so much happen the moment I resumed? A: Because waits keep counting down while a journey is paused. Every step that came due during those two weeks was ready to go the instant you resumed, so they all moved at once. Nothing was sent during the pause itself — it all went out on resume. For a busy journey, resume when you can keep an eye on it.