Troubleshooting automations: Queue, History, failures and resending

When an automation doesn't seem to have done what it should, Queue and History are where you go to find out why. Queue shows what's still due to run. History shows what's already run, whether it succeeded or failed, and gives you a way to fix and rerun the failed ones.

Where to find Queue and History

There are three scopes, depending on how much you want to see at once.

On the main automations page, Queue and History tabs show everything, across every automation, all in one place.

Click into an individual automation and its own Queue and History tabs show only what belongs to that one.

On a job, or any entity with a View Automations link available from Views, Queue and History show only the items tied to that specific entity.

Start broad if you're not sure which automation is involved, and narrow down to the entity level once you know which record you're actually chasing.

What's in the Queue

Queue shows items that are due to run, each with a scheduled date. You can toggle any item off if you need to stop it running before it fires.

Held tasks show up here too. If a workflow includes a step that pauses and waits for a task to reach a particular status, the human in the loop pattern, that paused workflow appears in Queue with wording along the lines of waiting for task X to be status X.

This matters because it looks similar to anything else sitting in Queue waiting its turn. It is not stuck and it is not broken. It's working exactly as designed, waiting on a person to complete the task before it continues. If you see this wording, the fix is to go and complete the task it's waiting on, not to treat it as a failure.

What's in History

History shows items that have already run.

A successful run shows the date it ran. A failed run shows an explanation of why, with the exact wording depending on the type of step involved, and, depending on the type of step, an option to rerun it.

The explanations are fairly basic, but they cover most of what you actually need to diagnose a failure.

Common reasons a step fails

Automations can fail for a number of different reasons, and the type of step usually points to the type of problem.

An email step can fail because the connected email account has expired, or because the login details on it are no longer correct. A webhook can fail because it never received a response back from wherever it was sent. An SMS step can fail because the connected provider account, Twilio for example, has run out of credit.

These are examples rather than a complete list. Whatever the actual cause, History is the place to check it for any specific run, since it will tell you what happened on that attempt rather than leaving you to guess.

Whether one failure stops everything else

This is set per automation, and it's worth knowing which way yours is configured before you assume a failure has broken the whole thing.

When a step fails, you can have the entire workflow pause there and wait, or you can have that step skipped so the rest of the workflow carries on regardless.

This is why the same underlying failure can look like two completely different problems depending on the setting. On a pausing automation, a failure looks like everything downstream simply never happened. On a skipping automation, everything downstream still ran, except for the one part that quietly didn't. If something's missing further down a workflow that otherwise seems to have worked, check this setting before assuming the whole automation is broken.

Testing an automation

There is no test mode for an entire workflow. Running one means it genuinely runs.

Some individual steps do have their own way to test just that step. A webhook step, for example, has a button to test it and confirm you're getting a successful response back, without needing to trigger the whole automation to check it.

Resending a failed step

Rerun retries only the step that failed, not the whole automation from the beginning.

It stays pointed at the original record it was triggered by, so rerunning a failed step on one job won't somehow apply itself to a different job or a different lead. What it does pull fresh is the record's actual data at the moment you click rerun, not a snapshot frozen from when the automation first ran.

This is worth knowing because it changes what rerunning can actually fix. If a step failed because a variable was pulling from a field that was empty or wrong at the time, and that field has since been corrected on the record, rerunning it now will use the corrected value and can genuinely succeed. It isn't destined to fail identically a second time just because it failed once.