Since also Jac is here (and I trust him ), let me check if it’s me missing something.
I agree that in general a strategy for rejoining is needed (in particular for nodes with 5y expected life). However, it seems to me that thinking at network server failure is looking at the least important factor.
@cultsdotelecomatgmai advice works well first of all for the most likely events (failed or moved gateway, a truck in front of the node that shields signals, etc), while network server failing could be considered one of the least likely. It does not only need that the server is temporarily switched off, but also that it lost all keys, without backup. If it just shuts down gracefully and then is restarted, there is no real need for rejoin (@kersing: am I missing something on this? it’s not a TCP connection). You could do it, but guidelines ask not to do it too often, and I would not use it as a solution for other issues.
This technique does not tell you that a rejoin is needed. 99.9% of times it tells you there is something wrong in the communication chain (your node and gateways being the first places to look for). So it’s not that a new join is needed: you know you need to do something. First thing to try is to increase SF, if you are not yet at SF12. If it failed 10 times, there is a high probability that a new join will fail too, because of something in the middle.
This without considering how you know that 10 attempts failed. If you mean that all packets are confirmed, then one per hour is more than the maximum allowed by fair use policy.
it is useful to know if a joining attempt succeeds, but then it will stay as is even if the network server is switched off. So it is not a way to know the network server crashed.