For AI agents: the complete documentation index is available at https://docs.clickmax.io/en/llms.txt, the full documentation bundle is available at https://docs.clickmax.io/en/llms-full.txt, and this page is available as Markdown at https://docs.clickmax.io/en/features/automations/step-execution-numbers.md.
  • English

      • Why doesn't a step's General number match Successes plus Failures?

      Because General counts every run that went through the step, while Successes and Failures only count the runs that have already ended. The difference is runs that are still going or that were stopped. The step footer shows those two groups as In progress and Canceled whenever there is at least one, so the numbers add up:

      General = Successes + Failures + In progress + Canceled

      When there are no runs in progress and none canceled, both numbers stay hidden and the footer shows the usual three.

      Role: any member with access to the workspace. Test runs are not counted anywhere.

      What each number means

      NumberWhat it counts
      GeneralEvery run that went through this step, in any state.
      SuccessesRuns that reached the end of the automation.
      FailuresRuns that stopped, at this step or another one, with an error.
      In progressRuns that are queued, waiting on a timer, or waiting for the contact to reply.
      CanceledRuns that were stopped: with the Stop button, by archiving the automation, by removing the step they were on, or because the contact met an exit condition before reaching the end.

      A run moves between groups over time. The same run that is In progress today shows up under Successes or Failures tomorrow, without changing General.

      See who is behind each number

      Click any number in the footer to open the list of contacts behind it. In progress and Canceled open the list too and let you turn the group into a contact list, like the other three.

      On the Executions tab, the In progress filter shows the same set: whoever is queued, waiting on a timer, or waiting for a reply.

      A run stuck in the queue

      In rare infrastructure failures, a run can be created without ever entering the processing queue. It would sit under In progress forever without running a single step. The platform looks for those runs every few minutes and sorts them out on its own:

      • If the run has not executed any step yet and is less than 6 hours old, it goes back into the queue and runs normally, starting from the trigger.
      • If it is older than 6 hours, or if it stopped in the middle of the automation, it moves to Failed, with the reason shown on the Executions tab. That way you decide whether it still makes sense to run it, using Try again on the Executions tab.

      If the automation was already archived, the stuck run moves to Canceled, the same outcome as runs that were queued when the automation was archived. In an automation that went back to draft, a stuck run that never executed a step is canceled too; one that had already started moves to Failed, so you can retry it once you publish again. A paused automation keeps its runs going, so the rule above applies to it just like a live one.

      The same goes for a run that fails to enter the queue at the moment it is triggered: it is created as Failed, with the reason, instead of getting stuck under In progress.

      A run waiting on a multi-day timer, or waiting for the contact to reply, is not considered stuck: it stays In progress until the timer ends or the reply arrives.