Well I still don't think it is out of scope then for just the NUT client for enterprises or HomeLabs on XCP-NG.

SBCs are everywhere these days. Using a Raspberry Pi as the NUT Server in a homelab or a flavor of a more robust server for NUT seems like a solid choice. No USB passthrough to worry about, uptime on a 1500VA+ UPS, forget about it! There are a handful of guides how to get it running for a Pi or anything else (including this post).

As I think this though, I would still feel ok with another external device watching, waiting, and notifying me on a successful power off of any number of my hosts and VMs. Not all enterprises or homelabs can afford (even if their appetites want it) to get enterprise level power automations. We have our power. Break the chain. @olivierlambert

Would just having the nut client be sufficient enough on the base XCP-NG to tigger a shutdown via NUT? Maintaining the NUT server seems to be a hold up and add extra complexity for XCP-NG. We all may have different DC power situations, but we could all use tools in our belt at home or the data center.

@Andrew I had a very similar issue over the last couple of weeks producing the same error.
My coworker had been running similar S3 backups with success on the same ISP from a different site and then again at a site with Starlink. The only differences between the sites were the circuit and edge router.
I dove a little deeper and found that I had misconfigured a new VLAN/subnet and had IDS touching xen-orchestra and was flagging the port 80 traffic outbound to S3 as malicious. I could see the firewall actively dropping the outbound packets in the packet filter. This would make the S3 backup stop after about 30 minutes and subsequent backups would fail.
It may not be your exact issue, but this post struck a chord with me.