Hard to tell without a lot more information - you should really raise a case with Meraki Support, if you didn't already.
But... you should maybe think about re-configuring your Hub MX(s) - probably the MX450 in youData Centre - to manual NAT traversal; this fixes the IP address and port to which tunnels are built and can result in greater reliability when establishing / re-establishing tunnels (my guess is that your upstream firewall may now be discarding key tunnel packets, because punch-based sessions have expired). Given that DC infrastructure doesn't change IP addressing often - and even then, only with due notice and change control - this shouldn't affect solution flexibility and might really help. It's also particularly useful for solutions involving cellular connectivity at the Spokes, where carriers use CG-NAT:
Allocate a specific IP and UDP port to be used for VPN tunnels at the Hub, rather than relying on dynamic allocation by the VPN registry, using manual NAT traversal; see here: https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#NAT_Traversal Do this at the target Hub, not the Spoke.
This approach fixes both the destination IP and UDP port, in one direction. It does rely, of course, on the upstream firewall, behind which the Hub sits, also having appropriate config to ensure that the public IP and UDP port pair you nominate gets forwarded to the Hub MX in question. For the UDP port, I recommend choosing one between 1025 and 32768, but avoiding 4500
All your Spokes remain on the default automatic NAT traversal.
