Automatically detecting when a Linux game server is down

A game server outage is often noticed by players before the administrator. A periodic check, however, lets you automatically detect a stopped service and trigger an alert. This method is no substitute for full monitoring, but it provides a simple foundation for a Linux VPS hosting Minecraft, FiveM, Rust or another dedicated server.

What monitoring should detect

Start by defining the failure you want to report. A missing process, a stopped systemd service and a closed port do not all describe the same problem. A server can be running but no longer accept connections, or answer on its port while being unable to process a command correctly. A useful check therefore combines several levels:

• the presence of the expected service or process;
• its state in systemd when it is managed as a service;
• the response of the network port used by the game;
• the time of the last check and the number of consecutive failures.

The number of consecutive failures matters. An alert after a single check can flag a momentary network loss. Two or three checks close together give a more usable signal, without masking a real interruption.

Preparing a reliable service

Monitoring is easier to read when the game server is started by a systemd service rather than an SSH session. The service should use a dedicated user, an explicit working directory and a suitable restart policy. Before automating an alert, check that an intentional stop of the service is clearly distinguishable from a failure, and that the logs let you understand the last startup.

Do not configure an automatic restart without checking its effects. A restart loop can worsen a configuration error, fill the logs or consume resources. Start by logging and alerting, then add a controlled restart once the server's behavior is known.

Creating a local check

A local check can query the state of the service and write a dated result to a log. The idea is to return an error code as soon as a critical check fails, so that the scheduling mechanism can tell a normal state from a failure.

#!/bin/sh
SERVICE="mon-serveur-jeu.service"

if ! systemctl is-active --quiet "$SERVICE"; then
  printf '%s panne service=%s\n' "$(date -Is)" "$SERVICE" >> /var/log/jeu-monitoring.log
  exit 1
fi

printf '%s ok service=%s\n' "$(date -Is)" "$SERVICE" >> /var/log/jeu-monitoring.log
exit 0

Replace the service name and test the script with an intentional stop during a maintenance window. The log file should have restricted permissions and planned rotation. A check that only writes to a file that is never read is not an alert.

Checking the game port

The state of the service is not always enough. Add a test of the expected port from the VPS or from an external check point. The test must use the protocol and port actually documented by your game server. An open port only proves that a network listener answers, not that the world, the match or the database works correctly.

To avoid false positives, set a timeout, limit how often the tests run and keep the time of the last success. Do not open a firewall port just to satisfy a monitoring tool. The port must stay consistent with your configuration and your security policy.

Scheduling with systemd

A systemd timer is well suited to a periodic check on a Linux machine already managed with systemd. It runs the check at a regular interval and lets you review its runs in the system logs. The timer must be tested after every change and its unit must stay separate from the game service.

[Unit]
Description=Contrôle du serveur de jeu

[Timer]
OnBootSec=2min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

Pair this timer with a service-type unit that runs the script. The check must stay short: it should neither download an update nor run a full backup. Those operations have their own constraints and can be handled separately.

Monitoring VPS resources

A service can be active yet become unplayable when the virtual server's resources are saturated. Monitor RAM, CPU load, the processor and the available space on the SSD disk. A game server also consumes resources during a backup, a world generation, an update or a restart.

Keep thresholds specific to your usage rather than universal values. A disk-space alert should leave time to delete or move old logs. A memory alert should lead to checking the processes, the number of players and the game configuration. If a MySQL database is used by your server, it must be monitored separately from the game process.

Sending an alert without exposing a secret

A useful alert states the server involved, the time, the type of failure and the number of attempts. Store tokens, passwords and private URLs outside the script, with suitable permissions. Never write a secret into a command copied into a ticket or into a public repository.

A notification can go through a monitoring tool, a webhook or a team channel. The IP address and the service name can be included if that information is not public. However, do not broadcast an API key, a password, a database identifier or an administration link.

Also plan a back-to-normal alert. It avoids keeping people working while the service has already restarted. For a team, pair every alert with a procedure: check the resources, read the logs, test the port, then examine the network or the host if necessary.

Choosing the Linux environment to monitor

To host a game server, a Linux VPS provides a virtual machine with administrator access, usually over SSH. Ubuntu and Debian are common environments, but the procedure must follow the distribution actually installed. The root account, dedicated users, the firewall and the updates must be handled with care.

A hosting provider may offer a control panel, a console access or a public IP address. These help you regain control when the network or the service is down, but they do not replace the check run on the machine. A VPS is still a virtual server: you must monitor its resources and keep an independent backup.

Virtualization lets you isolate several virtual servers on a cloud infrastructure, but each instance keeps its own limits on RAM, processor, storage and bandwidth. So check the remaining storage space and the bandwidth actually needed before grouping several game servers on the same VPS plan. An external backup must stay reachable even when the virtual server is down.

For a larger project, compare the needs of a virtual server and a dedicated server. A physical server can offer more reserved resources, while a VPS is often easier to scale. In both cases, the alert must cover the game service, the network, the storage and the host.

Testing and evolving the monitoring

Reliable monitoring is tested like a backup. Stop the service in a controlled window, check that the alert is received, measure the delay, then restart the server and check the recovery message. Also test a closed port, a nearly full disk and a temporary loss of connectivity if your procedure allows it.

Start with a single server and a few indicators. When the setup is stable, add disk space, memory and CPU load measurement. These checks address other causes of failure and must be interpreted together with the server type, the number of players and the scheduled tasks.

Finally, document the domain name, the IP address, the ports, the services, the firewall and the backup method. This sheet speeds up diagnosis when a different person works on the VPS. An administration panel or a managed-services solution can complement the scripts, but it does not remove the need to test alerts and backups.

To go further, also read our network diagnosis of an unreachable VPS, the guide to securing a dedicated server, the advice on updating a Linux game server, our guide to high-availability backups and the solutions to restore a Pterodactyl server.