Objective:
This guide provides an overview for the main causes and scenarios pertaining to server stops, which will be defined for the purposes of this article as "the final stage of the server lifecycle which takes place when the server build executable process comes to an end."
Explanation:
There are two varieties when considering server stops - internal and external stops. Internal stops are the result of "events that originate from the game server itself (the process of the build executable)." External stops are those that originate from any source outside of that.
An internal stop will come about either because of an intentional exit or a crash. In the case of an intentional exit, the server process will terminate with exit code 0, and most often this occurs after a game session ends. This action triggers an automatic deallocation of the server slot. A crash, on the other hand, takes place when the server process terminates with any exit code other than 0. It's important to also understand that although Multiplay Hosting will attempt to recover the server the server by restarting it with the same allocation ID, but will not continue if crashes persist - this is known as the crash backoff.
An external stop has more potential causes. An allocate API call with the restart flag set to true will cause a server stop. The purpose of the restart flag is threefold: 1) Forces allocation to use a fresh server instance, 2) Ensures a clean server state for debugging, and 3) Guarantees that the latest build version is running. Game server misbehavior will also cause a server stop. Misbehavior should be understood as "something unexpected (other than a crash) happened with the build executable process." Two common examples are resource overutilization (think CPU or RAM) or the server failing to respond to queries for an extended period of time. The next scenario are server restarts due to allocations being placed on server slots using the wrong build configuration. Note that changes to values in a build configuration currently in use by a server may not be reflected immediately. Finally, servers are stopped when a machine is descaled entirely out of a fleet.
ClanForge users should also be aware that pressing the stop button on an allocated server will not deallocate it. Remember that the recommended approach is to let the server exit with code 0 after a session ends, which will automatically handle deallocation, rather than making explicit deallocation API calls. However, if manual intervention is absolutely necessary, then use a deallocation call.
Supplemental Resources:
https://docs.unity.com/ugs/en-us/manual/game-server-hosting/manual/concepts/server-lifecycle#Internal_stops
https://docs.unity.com/ugs/en-us/manual/game-server-hosting/manual/legacy/game-server-management