@girish Thanks! This ended up being a combination of issues I believe. So throttling on the backups due to using rsync, encryption, and file names ended up being too long (only a few) So I've changed some settings around and it seems to have been resolved. I appreciate the help from both @robi and yourself.
I really like the blackllist checking being built-in. Frankly, I'd also be a fan of getting notifications about it. I suppose UX-wise, perhaps this is the appropriate sort of thing to trigger a yellow status on email.
@girish so I created a new WP install on a different cloudron for the domain, https://slappersonly.co -- everything seems in order now, even for people who had errors before. Meanwhile I switched the older WP install to a new domain on the original cloudron https://slaps.vip .. there do not seem to be any issues for either domain now.
Not too terribly inconvenient as the 2 sites serve different purposes for the same brand, but bizarre nonetheless.
The root cause for this was the Cloudron server had the hostname as "box.domain.com" (same as the relay). Debian/Ubuntu has a quirk that it will put the hostname in /etc/hosts to resolve as 127.0.1.1. This meant that when we try to set it as relay, it resolves to 127.0.1.1 instead of the actual IP.
To add to the confusion, I suggested using the host command which does not use /etc/hosts (i.e the nsswitch mechanisms) and uses only the DNS. If I had suggested using ping then we would have narrowed down the issue more quickly...
Anyway, the fix is simply to hostnamectl set-hostname somethingelse.domain.com and also edit /etc/hosts (for some reason, hostnamectl doesn't change hosts file even after reboot, 🤷 ).