FiveM Server Keeps Crashing: How to Keep It Online 24/7 with Auto-Restart
FiveM server crashing on its own? Set up auto-restart, watchdog, and RAM/CPU monitoring to keep it online 24/7 with no manual intervention.
A FiveM server crashing in the middle of peak hours is one of the most frustrating problems for anyone running a community. The player disconnects, loses progress, complains on Discord, and you only find out about the crash hours later when someone reports it. Without auto-restart, every crash becomes a manual intervention at 3 AM.
This guide is for anyone already running a FiveM server on a Linux VPS (Ubuntu or Debian) who wants to set up a recovery layer that keeps the service online 24/7 — so even if FXServer crashes, it comes back on its own within seconds. We’ll cover diagnosing the real cause, configuring a systemd watchdog, monitoring RAM/CPU, and scheduling restarts to mitigate memory leaks.
Estimated time: 30-45 minutes for a complete implementation, including testing.
Prerequisites
Before starting, confirm you have server access and the basic tools installed.
You need Ubuntu 22.04 LTS or Debian 12 with root access over SSH, FXServer already installed and running (crashing, but running), and txAdmin configured. Also recommended: 4 GB RAM minimum, 2 vCPUs, and SSD storage.
30120/udp + tcp 40120/tcp fivem (not root) /home/fivem/server If you still run FXServer inside tmux or screen, this guide replaces that setup with systemd — which is the correct way to keep any long-running service alive on Linux.
Diagnosis: why it’s crashing
Before setting up auto-restart, you need to know what’s killing the process. Layering auto-restart on top of an undiagnosed problem is treating the symptom and ignoring the disease.
Check if it was an OOM kill (out of memory):
sudo dmesg -T | grep -i "killed process"
sudo journalctl -k --since "24 hours ago" | grep -i oomIf you see a line like Killed process 12345 (FXServer) total-vm:8GB, the kernel killed it due to lack of RAM. This points to a memory leak in a resource or an undersized VPS.
Check if it was an internal FXServer crash:
tail -n 500 /home/fivem/server/server.log | grep -iE "error|exception|crash"Look for a stack trace or lines like [script:resource_name] ERROR. Lua resources with infinite loops or unhandled exceptions take down the whole server.
Check network saturation (possible DDoS):
sudo apt install -y vnstat
vnstat -l -i eth0If inbound traffic (rx) is in the hundreds of Mbps with few players connected, it’s a flood. Note the peak so you can compare later.
If the server consistently crashes near the same uptime (e.g., every 8-10h), it’s almost certainly a gradual memory leak. Monitor htop during a full session to watch the FXServer process RAM grow linearly until it explodes.
Configuring systemd as a watchdog
Systemd is the standard init system on Linux and has native support for restarting services that crash. We’ll create a dedicated service unit for FXServer.
Create a dedicated user for the server (if it still runs as root, this is mandatory for security):
sudo useradd -m -s /bin/bash fivem
sudo chown -R fivem:fivem /home/fivem/serverRunning internet-facing services as root is a full-compromise vector if an RCE is ever discovered in FXServer.
Create the service unit file:
sudo nano /etc/systemd/system/fivem.servicePaste the content below, adjusting the paths to match your installation:
[Unit]
Description=FiveM FXServer
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=fivem
Group=fivem
WorkingDirectory=/home/fivem/server
ExecStart=/home/fivem/server/run.sh +exec server.cfg
Restart=always
RestartSec=10
StartLimitBurst=5
StartLimitIntervalSec=300
StandardOutput=append:/home/fivem/server/server.log
StandardError=append:/home/fivem/server/server.error.log
LimitNOFILE=65535
[Install]
WantedBy=multi-user.targetThe critical directives: Restart=always restarts on any exit (crash or normal), RestartSec=10 waits 10 seconds between attempts (gives the UDP socket time to release), and StartLimitBurst=5 prevents an infinite loop if the server is truly broken.
Enable and start the service:
sudo systemctl daemon-reload
sudo systemctl enable fivem.service
sudo systemctl start fivem.service
sudo systemctl status fivem.serviceThe output should show active (running) in green. If it shows failed, run sudo journalctl -u fivem.service -n 50 to see the error.
If you had FXServer running in tmux or via standalone txAdmin, kill those processes before starting systemd. Two processes trying to bind the same UDP port cause a crash loop and can corrupt the save state of your resources.
Scheduled auto-restart to mitigate memory leaks
Even with the root cause fixed, it’s good practice to schedule a daily restart to free memory and prevent degradation. Do this during your lowest-activity window.
Create a systemd timer for a daily restart at 6 AM:
sudo nano /etc/systemd/system/fivem-restart.timer[Unit]
Description=Restart FiveM daily at 6am
[Timer]
OnCalendar=*-*-* 06:00:00
Persistent=true
[Install]
WantedBy=timers.targetAnd the service that the timer triggers:
sudo nano /etc/systemd/system/fivem-restart.service[Unit]
Description=Restart FiveM service
[Service]
Type=oneshot
ExecStart=/bin/systemctl restart fivem.serviceEnable the timer:
sudo systemctl daemon-reload
sudo systemctl enable fivem-restart.timer
sudo systemctl start fivem-restart.timer
sudo systemctl list-timers fivem-restart.timerThe output should show the next scheduled run. You can adjust the time to another window — always pick when your server has the fewest players online.
Configure a resource that broadcasts in-game 5 and 1 minute before the scheduled restart time. A surprise restart frustrates players and generates complaints. Resources like vMenu or txAdmin scheduled restarts handle this natively.
Continuous RAM and CPU monitoring
Auto-restart is only effective if you know when it’s happening too often. Basic monitoring warns you about degradation before it turns into a real problem.
Install htop and vnstat for real-time observation:
sudo apt install -y htop vnstat
sudo systemctl enable --now vnstathtop shows process by process. Filter with F4 and type FXServer to see only what matters.
Create a simple alert script that checks FXServer RAM every 5 minutes:
sudo nano /usr/local/bin/fivem-mem-check.sh#!/bin/bash
THRESHOLD=85
MEM_PERCENT=$(ps -o %mem= -C FXServer | head -n1 | tr -d ' ')
MEM_INT=${MEM_PERCENT%.*}
if [ "$MEM_INT" -gt "$THRESHOLD" ]; then
echo "$(date): FXServer using ${MEM_PERCENT}% RAM" >> /var/log/fivem-mem.log
# Optional: send to a Discord webhook
# curl -H "Content-Type: application/json" -d "{\"content\":\"FiveM RAM high: ${MEM_PERCENT}%\"}" $DISCORD_WEBHOOK
fiMake it executable and schedule it in cron:
sudo chmod +x /usr/local/bin/fivem-mem-check.sh
echo "*/5 * * * * root /usr/local/bin/fivem-mem-check.sh" | sudo tee /etc/cron.d/fivem-memVerification
Confirm the entire stack is working before considering the setup complete.
Force a simulated crash to see if auto-restart works:
sudo pkill -9 FXServer
sleep 15
sudo systemctl status fivem.serviceAfter 10-15 seconds, the status should show active (running) again, with a short uptime. If it shows failed or inactive, review the service unit.
Check the latest restarts in the systemd log:
sudo journalctl -u fivem.service --since "1 hour ago" | grep -E "Started|Stopped"Each Started/Stopped pair represents one restart cycle. High frequency indicates the root cause hasn’t been fixed.
Troubleshooting
Server restarts in an infinite loop
If systemd keeps restarting the service every few seconds without ever stabilizing, it’s usually a server.cfg configuration issue or a broken resource. Temporarily stop auto-restart with sudo systemctl stop fivem.service, run run.sh manually as the fivem user, and read the output directly in the terminal. The error shows up immediately.
Port already in use after restart
A UDP socket can stay in TIME_WAIT state for a few seconds. Increase RestartSec in the service unit from 10 to 20-30 seconds. If the problem persists, force release with sudo fuser -k 30120/udp before restarting.
txAdmin doesn’t see the systemd-restarted server
When you migrate from standalone txAdmin to systemd, txAdmin loses control of the process. Solution: run txAdmin as part of the same service unit (passing +set txAdminPort 40120 in ExecStart), or accept that txAdmin becomes just a visualization dashboard — the real restart comes from systemd.
Next steps
With auto-restart working, it’s worth evolving the setup:
- Configure automatic database backups (MySQL or MariaDB) with
mysqldumpin a daily cron - Implement external monitoring with Uptime Kuma or similar to alert when the server is actually offline
- Optimize problematic resources — use in-game
resmonto identify which ones consume the most CPU/RAM - Consider separating the database onto its own server once you pass 64 slots
- Configure a firewall (ufw or nftables) to limit exposed ports and protect against automated scans
If your FiveM server is crashing due to hardware overload rather than resource bugs, it’s worth comparing what your current VPS delivers against a game-optimized hosting plan — dedicated vCPUs and DDoS protection prevent most of the crash categories we covered here.
Frequently asked questions
Why does my FXServer crash without any error message?
In most cases it's an OOM (out-of-memory) kill — the Linux kernel silently terminates the process when RAM runs out. Check with `dmesg | grep -i 'killed process'` or `journalctl -k | grep -i oom`. Other common causes: a Lua script with an infinite loop blocking the main thread, and a heartbeat timeout with CnL (Cfx.re).
What's the difference between txAdmin restart and systemd restart?
txAdmin restarts only the FXServer process inside the same runtime — fast, but if the problem is a persistent memory leak, the leak continues. Systemd kills the whole process and its children, fully releases the memory, and starts from scratch. For recurring crashes, systemd is more robust.
How many players can a FiveM server handle before crashing?
It depends more on the scripts than on the hardware. A server with 32 slots and few resources runs comfortably on 4 GB of RAM. With 64+ slots and heavy scripts (ESX/QBCore + custom), plan for 8-16 GB. The bottleneck is almost always a single CPU thread saturated by a poorly written script, not a lack of total RAM.
Does auto-restart fix a permanent memory leak?
It treats the symptom, not the cause. A scheduled restart every 6-12h masks the leak and keeps the server online, but each restart drops every player. The ideal approach is to identify the guilty resource with in-game `resmon` and fix or replace it. Auto-restart is a temporary solution while you investigate.
txAdmin already has a monitor — do I need systemd too?
Yes. txAdmin monitors FXServer, but if txAdmin itself hangs or the Node.js process dies, nothing restarts it. Systemd sits one layer above, watching txAdmin. It's defense in depth: txAdmin handles the game, systemd handles txAdmin.
How do I know if the crash is a DDoS attack or an internal problem?
Check the FXServer log at the moment of the crash. An internal crash leaves a stack trace or exception message. A DDoS shows up as saturated tx/rx network traffic (`vnstat -l`) with no error in the FXServer log — the process simply stops responding because bandwidth is fully consumed. Hosting with DDoS protection solves the second category.