Notification stops about half way – Is my fix stable?

I recently set up the ability to send and email based on bbPress forum item edit to a um-role list on our wp site using Planner. During test, the distribution was limited to 6 email addresses. When it went live, the list grew to ~180 users. On first use, it failed about 50% through and on re-submit in the notification log and repeated about the same.

Actions I took:

1. Researched Sync vs Async sending and decided to change the cron configuration based on https://publishpress.com/knowledge-base/troubleshooting-notifications/ using cPanel in GoDaddy. It looks successful and the message that cron wasn’t found on the log went away. I set the cron job to run every 10 minutes since I want a short time lag from edit to send.
2. Took the 180 emails and put them through a validator. Found 8 dead end emails and deactivated those users. Found 1 malformed email and changed @yahoo.net to @yahoo.com.

Results:

The job ran again and all recipients have a green check mark now, count looks good. Since I made both changes above without a test in between, I don’t know which item fixed it.

Question:

• If an email address fails to send, does the notification code continue to process the next email? If not, is this fix only good until the next bad email shows up or someone drops their email account or similar? Is the code robust?
• Do you think the cron set-up change made a difference? We do have a low traffic site.

Comment:

This is a very nice plugin and has enable a piece of functionality envisioned over a year ago, but only now have I figured out a way to get all the pieces together. I have been working with the plugin and other items for about a month on this feature to get it all working. I plan to leave a strong positive review once I know it is stable.

In my working with the plugin, it appears to me that this plugin conflicts with some of the global variables in bbPress shortcodes so I made a work-around with snippets and cashing variables. It is working, but I prefer not need the work-around as in increases technical debt (and is less than elegant). Any thoughts on this?

Thanks,
Phil