I think you first need to determine why things are failing now.
When using unconfirmed uplinks, and assuming the node does not try to exceed the built-in legal maximum duty cycle, the RN2483 will always return mac_tx_ok, without it knowing if its transmission was received by any gateway. (Also, if it is exceeding the limits, then you should not restart the device on getting no_free_ch.)
As the problems started when the gateways were offline for just a few hours, I’d guess your nodes are transmitting quite a lot (or: too often?) and maybe the gap between the counter of the last received uplink and the current ones has exceeded the maximum gap of 16,384 messages?
If not, then I’d assume that the nodes use ADR. With ADR enabled, if a node does not get any downlink from TTN for some extended period then it will automatically request one explicitly. And if it does not receive that one either, then it will decrease its data rate, and at some point might even fall back to SF12. Again, I’d guess your nodes are transmitting quite a lot (or: too often?), making ADR notice the missing downlinks quite soon. Maybe you could try to detect the uplink’s low data rate. But there’s no reason why the TTIG would not handle low data rate uplinks, so triggering a re-join might not even solve this.
So: how many message were missed, what’s the current SF, why does the TTIG not receive it, does the TTIG receive any other traffic, are you sure the devices do not transmit?