How to Detect and Handle Server Crashes Automatically

Crashes Happen, Silence Is the Problem

A Minecraft server will crash eventually. A plugin update introduces a null pointer, the JVM runs out of memory, or a chunk corruption triggers an infinite loop. The crash itself is usually recoverable. The real damage comes from nobody noticing for hours while players bounce off a dead connection and move on to another server.

The goal is not to prevent every crash (that is impossible) but to detect server crashes on your minecraft server within seconds and respond automatically. We will set up three layers: a process watchdog that restarts the server, log monitoring that identifies why it crashed, and Discord alerts that notify your team the moment it happens.

Layer 1: Process Watchdog Script

The simplest way to detect server crashes on minecraft is to wrap the server process in a restart loop. When the Java process exits for any reason, the script waits a few seconds and starts it again.

#!/bin/bash
# start.sh with automatic restart
while true; do
  echo "[Watchdog] Starting server at $(date)"
  java -Xms4G -Xmx4G -jar server.jar --nogui
  EXIT_CODE=$?
  echo "[Watchdog] Server exited with code $EXIT_CODE at $(date)"

  # Check if a stop was intentional
  if [ -f "stop.flag" ]; then
    echo "[Watchdog] Stop flag found, not restarting."
    rm stop.flag
    break
  fi

  echo "[Watchdog] Restarting in 10 seconds..."
  sleep 10
done

This script runs the server inside a while true loop. If the server crashes, the loop catches the exit, waits 10 seconds, and launches again. The stop.flag file lets you shut down intentionally without the watchdog restarting it. Just run touch stop.flag before issuing /stop in the console.

For a deeper look at restart strategies, including Pterodactyl schedules, see our auto-restart guide.

Layer 2: Crash Log Detection

Restarting after a crash is good, but you also need to know what caused it. Minecraft writes crash reports to the crash-reports/ directory. A monitoring script can watch for new files in this directory and extract the key details.

#!/bin/bash
# crash-monitor.sh, run in background alongside the server
CRASH_DIR="./crash-reports"
inotifywait -m -e create "$CRASH_DIR" | while read dir event file; do
  CRASH_FILE="$CRASH_DIR/$file"
  # Extract the first 20 lines which contain the exception
  HEAD=$(head -20 "$CRASH_FILE")
  echo "[Crash Monitor] New crash report: $file"
  # Send to Discord webhook (see Layer 3)
  curl -s -X POST "$DISCORD_WEBHOOK"     -H "Content-Type: application/json"     -d "{"content": "**Server Crash Detected**
```$HEAD```"}"
done

This script uses inotifywait to detect server crashes on minecraft by monitoring the crash-reports folder in real time. The moment a new crash report appears, it sends the first 20 lines (which contain the exception stack trace) to a Discord webhook.

Layer 3: Discord Alerts

Discord is where most server teams communicate, so it is the natural place for crash alerts. Create a webhook in your staff channel (Channel Settings, Integrations, Webhooks) and save the URL.

You can also detect server crashes on minecraft by polling from outside. A simple uptime check pings the Minecraft port every 30 seconds:

#!/bin/bash
# uptime-check.sh
MC_HOST="localhost"
MC_PORT=25565
WEBHOOK="https://discord.com/api/webhooks/..."

while true; do
  if ! nc -z -w5 "$MC_HOST" "$MC_PORT" 2>/dev/null; then
    curl -s -X POST "$WEBHOOK"       -H "Content-Type: application/json"       -d '{"content": "**Alert:** Minecraft server is not responding on port '"$MC_PORT"'!"}'
    sleep 120  # avoid spam, wait 2 min before next alert
  fi
  sleep 30
done

This catches not only full crashes but also freezes where the process is alive but the server is unresponsive (a common symptom of GC stalls or deadlocked plugins).

Pterodactyl Crash Detection

If you run Pterodactyl, crash detection is built in. Pterodactyl monitors the container process and can automatically restart it when it exits. In the server's Startup tab, enable "Crash Detection" and set the restart delay. Pterodactyl also supports scheduled tasks that can run health checks and trigger alerts through the API.

For external monitoring of Pterodactyl servers, use the API to poll server status and feed it into Grafana for visualization and alerting.

Reading Crash Reports

When a crash report lands, knowing how to read it saves debugging time. The report has three important sections:

• Description: The top line tells you the exception type (OutOfMemoryError, NullPointerException, etc.).
• Stack trace: The chain of method calls leading to the crash. Look for your plugin names in the trace to identify the culprit.
• System details: JVM version, flags, loaded plugins, and world info. Useful when reporting bugs to plugin developers.

For a deeper guide on interpreting logs and crash reports, see how to read server logs. Learning to detect server crashes on your minecraft server is only half the job. Understanding what the crash report tells you lets you fix the root cause instead of just restarting into the same failure.

See a well-run server in action: Astroworld MC, IP play.astroworldmc.com, Java + Bedrock.