Skip to main content

Does anyone know what might cause the number of “Helds” in Zap History to exceed the number of SMS recipients pulled from a Google Sheet? 

They were held initially because I had only been testing one or two SMS sends at a time, and today, was my first real push. I released some of those held, and there were no issues. But, of those that I’ve not yet re-played, I noticed that the number held in Zap History greatly exceed the number of actual recipients, and I’m hoping someone may have insight into what that is.

I downloaded the full list from Zapier, as a CSV, and looked it over carefully. There were no duplicate mobile numbers, and there were indeed nearly twice as many rows of data, and those only had a long string ID, but no data associated.

Anyone seen this before? I’d like to make sure I’m not causing an issue before I re play those remaining, but I may need to take a chance!  Thanks for any help!

Hi ​@ShawnP 

For us to have more context, post screenshots about what you are referring to. (data in the CSV, HELD Zap Runs, how your Zap steps are outlined/configured)


Hey ​@ShawnP, just checking in—were you able to get to the bottom of why the number of held runs and recipients in the spreadsheet didn’t match?

If not, and if you’re using the Google Sheets New or Updated Spreadsheet Row trigger, then it’s possible that an update to the spreadsheet caused the Zap to trigger again for existing rows. There are a few reasons this can happen, which you can learn more about that here: triggers unexpectedly or too soon. Do you think that might’ve been the case here?

Look forward to hearing from you! 🙂