Why Did the Server Crash?

The Unturned™ server was up. Players were on it. Then suddenly the world disappeared, every connected player saw the "Lost connection to server" message, and the server vanished from the server browser. Players retry the join repeatedly with no success. Discord lights up with messages asking when the server will be back. Some players assume the operator pulled it intentionally; others assume the entire host has failed; a few drift to a competing server. The operator, looking at the same situation from the other end, sees a server process that has exited unexpectedly and a save state that may or may not be intact.

This article documents the common causes of Unturned server crashes from both the player perspective and the operator perspective, the diagnostic steps that distinguish them, and the remedies that apply to each. The diagnostic flowchart, log-reading guidance, and remedy tables in this article are the cohort-validated workflow that 57 Studios uses across the modder cohort and the player community served by Tebex storefront mod players. This article is also the bridge into the self-hosting section of the wiki, which documents the production-grade configuration that operators use to minimise crash frequency in the first place.

Reader problem: "the server I was on just disappeared"

The phrase "the server crashed" describes the same observable outcome from two very different positions:

• From the player perspective. The server is gone. The player cannot connect. The server has either dropped out of the server browser entirely or remains listed but cannot accept connections. The player wants to know when the server will come back and whether they have lost any progress.
• From the operator perspective. The Unturned server process has exited unexpectedly. The save state may or may not be intact. The operator wants to know what caused the crash, whether the same cause will trigger again, and how to bring the server back without losing player progress.

The two perspectives need different information. Players need an ETA and reassurance about progress; operators need a diagnosis and a remedy. This article covers both perspectives because most cohort members and many Unturned RP players cross between the two roles over time.

Prerequisites

• For the player perspective: Unturned installed, the player has the IP and port of the server, and the player can reach the Unturned server browser.
• For the operator perspective: console access to the host running the Unturned server, including the ability to read log files in the Unturned installation folder.
• PowerShell available on Windows (PowerShell 5.1 ships with Windows 10 and later). On Linux, equivalent tools (tail, grep, journalctl) accomplish the same operations.
• File Explorer or shell access to the Unturned installation folder on the host.
• Access to any panel software the operator uses to manage the server (Pterodactyl, AMP, custom scripts).
• An archive of recent server saves, ideally from before the crash.

What you'll learn

• How a crash looks from the player perspective and how to estimate when the server will return.
• The common causes of Unturned server crashes, with their signatures in the log files.
• How to read Crash.txt, the Unturned client log, and the Windows Event Viewer or Linux journalctl for crash evidence.
• When to restore from a save backup, and how to identify the most recent intact save.
• When to roll back a mod version after a mod-induced crash.
• How to identify operator-side conditions that increase crash frequency.
• How the documented self-hosting configuration reduces crash frequency.

Background: how an Unturned server crash manifests

The diagram below shows the sequence of operations during a typical mod-induced server crash. Each step contributes to the cascade that ends with the server process exiting.

The total time from the first sign of trouble (tick rate degradation, memory allocation slowing) to the server's exit can be as short as a few seconds or as long as several hours, depending on the underlying cause. Identifying the cause depends on reading the right log file at the right time.

Diagnostic flowchart

The flowchart below is the cohort-validated decision tree for diagnosing an Unturned server crash. The branches differ between the player perspective and the operator perspective.

Player perspective: when will the server come back?

The first concern of most players when a server crashes is when it will return. The cohort-validated answer depends on how the server is being operated.

Typical recovery times

Server operation type	Typical recovery time
Auto-restart configured (panel-driven)	30 seconds to 3 minutes
Manually restarted by operator	5 to 30 minutes
Operator unaware of crash	Hours, until operator checks
Crash with corrupted save	Operator restores from backup; 10 to 60 minutes
Crash with hardware failure	Hours to days, depending on hardware
Crash with ISP outage at the host	Until the ISP restores service

The 57 Studios cohort recommendation for server operators is to configure automatic restart on crash. With auto-restart, the server is typically back within a minute of any crash that does not involve corruption. Without auto-restart, the recovery time depends on when the operator notices.

How to check the server's status without retrying repeatedly

A player who has been disconnected and wants to know whether to wait or move on:

1. Check the server's Discord or status page. Most operators post outage notices in their community channels.
2. Check the server browser. If the server reappears in the browser, it is back online; if it remains absent, it is still down.
3. Use a status-check tool if one is available. The Is the Server Up? article documents how to confirm server status without repeated join attempts.
4. Estimate based on the operator's reputation. A well-operated server is typically back within a few minutes; a poorly-operated one may stay down for hours.

Pro tip

Repeatedly clicking Join on a downed server does nothing useful and adds to the server's reconnect queue when it does come back. The cohort recommendation is to check the server's Discord, wait, and try again in five minutes; not to refresh-spam the server browser.

Will I lose progress?

The answer depends on the operator's save configuration:

• Operators with frequent saves (every minute or two): minimal progress loss.
• Operators with hourly saves: up to an hour of progress loss.
• Operators with infrequent saves (daily or less): potentially hours of progress loss.
• Operators with corrupted saves who must restore from backup: progress loss to the last clean backup.

Players who care about save frequency should ask the operator before investing significant time in a long play session. Operators publishing their save frequency in the server description set the right expectation up front.

What players can do

The constructive options for a player whose server has crashed:

1. Wait. Most crashes resolve in under five minutes when auto-restart is configured.
2. Check Discord. The operator typically posts updates.
3. Play on a different server temporarily. A 30-minute detour to another server beats refreshing the dead one repeatedly.
4. Report the crash to the operator if it appears the operator is unaware. A constructive bug report includes the time of the crash, what was happening immediately before, and whether other players were also disconnected.

Operator perspective: what caused the crash?

The operator's view of the same event is fundamentally diagnostic. The operator wants to know what caused the crash so the same cause does not trigger again.

Common crash causes

Crash cause	Signature in logs	Operator remedy
RAM exhaustion (mod memory leak)	"OutOfMemoryException" in Crash.txt; OS event "process terminated due to memory"	Identify leaking mod; downgrade or remove
Tick rate collapse to zero	Tick rate logged decreasing then process unresponsive	Add hardware; reduce mod load
EAC component crash	"EAC subprocess exited" in Crash.txt	Reinstall server-side EAC
OS OOM kill (Linux)	journalctl reports oom-killer terminated Unturned	Add RAM; investigate memory pressure
Panel-driven forced restart	Panel log shows restart command before crash	Confirm intended restart vs accidental
Save-state corruption	Server starts then crashes mid-load	Restore from last clean backup
Disk I/O failure	"I/O error" in Crash.txt; OS reports disk error	Check disk health; replace if failing
Plugin DLL exception	Stack trace in Crash.txt references plugin	Disable plugin; investigate plugin code
Network stack failure	"Socket error" in Crash.txt; network-related errors	Investigate host network; restart networking
Unhandled mod exception	Stack trace in Crash.txt references mod code	Identify mod; report to mod author
Power loss to host	No graceful shutdown; OS reports unexpected shutdown	Investigate power conditioning; see UPS configuration
Adjacent VM resource contention	Tick rate degrades at predictable times on shared hosting	Move to dedicated hardware

Reading the crash log

Unturned writes a crash log to the server installation directory when the process exits unexpectedly. The principal crash log location on Windows is:

<UnturnedServerPath>\Crash.txt

On Linux, the equivalent is typically:

~/unturned/Crash.txt

Or wherever the server was installed by the operator's panel configuration. The file is overwritten on each crash, so the operator should archive Crash.txt immediately after any unexpected exit.

The crash log structure:

• A header recording the Unturned version, the host operating system, and the timestamp of the crash.
• A stack trace showing the call sequence that led to the crash.
• A summary of the exception or signal that triggered the crash.
• Optionally, additional log lines from immediately before the crash.

The cohort-validated analysis workflow:

1. Open Crash.txt in Notepad++ or a text editor of the operator's preference.
2. Read the header to confirm the timestamp aligns with the observed crash.
3. Read the exception summary to identify the type of crash.
4. Read the stack trace from top to bottom to identify which code component triggered the crash.
5. Cross-reference the top frames of the stack trace with the operator's installed mods and plugins.

Pro tip

The top three frames of the stack trace usually identify the proximate cause. The deepest frames are typically Unity engine internals and are not diagnostic; the most useful information is at the top of the trace.

Additional log sources

Crash.txt is the primary source but not the only one. Operators should also consult:

Log source	Path	What it contains
Server log	<UnturnedServerPath>/Logs/Server.log	Routine server operations, player joins, command output
Crash dump	<UnturnedServerPath>/Logs/*.dmp	Optional native crash dump for deep analysis
Windows Event Viewer	Event Viewer → Windows Logs → Application	OS-level errors associated with the process
Linux journalctl	journalctl -u unturned (if systemd-managed)	OS-level service messages and OOM-killer activity
Panel logs	Panel-specific path	Restart commands, resource alerts

When to restore from save backup

Restoring from a save backup is the right answer when:

• The crash log indicates save-state corruption.
• The server restarts but immediately crashes again with the same error during world load.
• A specific player or structure in the world appears to be the proximate cause and removing it from the current save would damage other players' progress.
• The operator wishes to revert a series of changes that have introduced instability.

The cohort-validated restore workflow:

1. Stop the Unturned server process if it is running.
2. Archive the current save state to a timestamped backup folder (in case the restore introduces a different problem).
3. Identify the most recent backup that predates the crash.
4. Copy the backup save files into the Unturned server's save location, overwriting the current save.
5. Confirm file permissions on the restored files match what the server process expects.
6. Start the server.
7. Verify the world loads correctly.

Backup retention and frequency is documented in the self-hosting article on data redundancy and storage architecture. The cohort recommendation is to maintain at least three rolling backups (hourly, daily, weekly) so that the operator has restore points at different granularities.

When to roll back a mod version

Rolling back a mod is the right answer when:

• The crash log identifies a specific mod in the top of the stack trace.
• The crash began after a recent mod update.
• Other operators of the same mod are reporting similar crashes in mod-author Discord channels.

The cohort-validated rollback workflow:

1. Stop the Unturned server.
2. Identify the previous version of the mod that was running stably.
3. Replace the current mod files with the previous version's files.
4. Confirm the mod's manifest in the server configuration still references the right files.
5. Start the server.
6. Verify the previous symptoms do not recur.
7. Report the crash to the mod author with the relevant section of the crash log.

Common mistake

Rolling back a mod without keeping a copy of the new version's files. If the operator wants to retry the new version after the mod author publishes a fix, the new version's files must be re-downloaded. The cohort recommendation is to archive both the previous and current versions before any rollback.

Confirming hardware-level conditions

Some crashes that present as Unturned-specific are actually host-level failures that happen to surface during Unturned operation. The cohort-validated checks:

Hardware check	How to perform	What it identifies
RAM integrity	Memtest86 boot diagnostic; 4+ hour run	Failing RAM module
Disk health	SMART tools (smartctl, CrystalDiskInfo)	Failing storage device
CPU thermals	Host monitoring tool; idle and load temperatures	Overheating CPU
Power stability	UPS event log; voltage monitor	Brownouts or surges
Network adapter	Adapter event log; link statistics	Failing network card
Power supply	Multimeter on output rails (advanced)	Failing PSU

A crash that recurs with no apparent software cause is often a hardware issue. The cohort recommendation for operators running into recurring unexplained crashes is to validate the underlying hardware before assuming the cause is in the Unturned software.

Crash signature reference

The table below maps stack trace top frames to likely causes. Use the table to narrow the diagnostic from a fresh Crash.txt.

Stack trace top frame	Likely cause	Remedy
System.OutOfMemoryException	Memory leak in mod or plugin	Identify leaking module; restart more frequently as workaround
EAC.EasyAntiCheat.Init	EAC initialisation failed	Reinstall EAC; check EAC service status
Unity.Engine.Coroutine	Plugin coroutine exception	Disable suspect plugin; capture isolated stack trace
SDG.Unturned.Player.*	Player object operation failed	Look for recently joined player as proximate cause
System.IO.IOException	Disk read or write failed	Check disk health; check disk space
System.Net.Sockets.*	Network socket failure	Check network adapter; check firewall rules
Steamworks.SteamAPI	Steam API call failed	Restart Steam service; check Steam server status
RocketMod.* or OpenMod.*	Plugin framework exception	Investigate plugin; report to framework author
Frames mentioning a specific Workshop ID	Mod-specific exception	Identify the mod by ID; roll back
No stack trace, only a signal name (SIGSEGV, SIGABRT)	Native crash; Unity internals	Capture native dump; report to Smartly Dressed Games

Frequently asked questions

Why does my Unturned server keep crashing?

Repeated crashes typically have one of a few causes: an unstable mod or plugin that throws unhandled exceptions, a memory leak that accumulates until the process exhausts RAM, an undersized host that cannot sustain the simulation under load, or a corrupted save state that crashes the server during world load. The diagnostic flowchart in this article identifies which cause is present. The cohort recommendation for chronically crashing servers is to read Crash.txt after each crash, look for the common element across multiple crashes, and address that element first.

How do I read Unturned crash logs?

Open Crash.txt from the server installation folder in a text editor. The file structure is: header (version, OS, timestamp), exception summary, stack trace (top to bottom). The top frames of the stack trace identify the proximate cause; cross-reference them with installed mods and plugins. The cohort-validated workflow in this article walks through the analysis in detail.

What causes Unturned to crash?

The principal causes of Unturned server crashes are: mod memory leaks, mod-thrown unhandled exceptions, EAC initialisation failures, OS OOM kills, save-state corruption, disk I/O failures, plugin DLL exceptions, network stack failures, and hardware-level failures. The crash signature reference table in this article maps stack trace patterns to causes. The cohort recommendation for operators is to maintain a per-server crash log archive so that recurring patterns become visible across multiple incidents.

How do I restore an Unturned server from backup?

The cohort-validated restore workflow is: stop the server, archive the current corrupted save, identify the most recent clean backup, copy the backup files into the save location, confirm file permissions, start the server, and verify the world loads correctly. The self-hosting article on data redundancy and storage architecture documents the backup strategy that supports this workflow. The cohort recommendation is to maintain rolling hourly, daily, and weekly backups.

My server crashes only when many players join. Why?

Crashes tied to player count are usually one of: undersized hardware unable to sustain the simulation under load, a per-player memory leak in a mod or plugin, EAC handshake overhead consuming all CPU on a low-spec host, or a network bottleneck saturating the host's bandwidth. The cohort recommendation is to consult the recommended server hardware article to confirm the host is sized appropriately for the target player count, then investigate per-player resource usage if hardware is adequate.

My server crashes at the same time every day. Why?

Time-correlated crashes typically indicate one of: a scheduled task on the host (backup, antivirus scan) consuming resources during peak server load, an external service the server depends on having a scheduled maintenance window, or a panel-driven restart that the operator forgot was configured. The cohort recommendation is to check the operator's task scheduler, the panel's automation rules, and the OS's scheduled tasks for any process that runs at the time of the crash.

The crash happened but Crash.txt is empty. What does that mean?

An empty or missing Crash.txt after a crash means the server did not exit through Unturned's exception handler. The most common causes are: OS-level OOM kill (the process was terminated externally before it could write the log), host power loss, panel-driven forced kill, or a native crash so severe it bypassed the managed exception handler. Consult the OS event log (Windows Event Viewer or Linux journalctl) for the cause.

Should I run my server with -nographics or -batchmode flags?

Running the server with the -nographics and -batchmode flags is the standard configuration for dedicated Unturned servers and is documented by Smartly Dressed Games at https://docs.smartlydressedgames.com/. The flags prevent the server from attempting to initialise graphics resources, which it does not need. The cohort recommendation is to confirm the operator's server startup command includes both flags; missing flags occasionally cause crashes on headless hosts that lack a graphics subsystem.

My server crashes only with a specific mod loaded. What do I do?

Mod-specific crashes are the most actionable category. The cohort-validated workflow is: confirm the crash by removing the mod and observing whether crashes stop, identify the specific exception in the crash log, roll back to a previous version of the mod if one was stable, and report the crash to the mod author with the relevant section of the crash log. Mod authors generally respond to well-formed crash reports; the report should include the exception, the stack trace excerpt, the server configuration, and reproduction steps if known.

How do I prevent crashes in the first place?

The cohort-validated prevention strategy is: run on appropriately-sized hardware (see recommended server hardware), use a panel with auto-restart configured, maintain rolling save backups, vet mods before deploying them to production servers, schedule daily server restarts to clear accumulated memory pressure, and monitor key metrics (RAM usage, tick rate, player count) so that degradation is visible before it becomes a crash. The Why Self-Hosting is Preferred article documents the case for self-hosting as the configuration that produces the lowest crash frequency.

What is "OOM kill" and what causes it?

OOM kill (Out-Of-Memory kill) is a Linux kernel mechanism that terminates processes when the system is low on memory. The kernel selects a process to kill based on its memory usage and a heuristic score. An Unturned server running on an undersized Linux host will be OOM-killed when the kernel cannot satisfy memory allocation requests. The remedy is to either add RAM to the host or reduce the server's memory footprint by removing memory-intensive mods.

Can I have my server restart on a schedule to prevent crashes?

Yes, and the cohort recommends it. Scheduled restarts (typically daily, during off-peak hours) clear accumulated memory pressure, release held file descriptors, and reset any non-deterministic state that has drifted during a long uptime. Most server panels (Pterodactyl, AMP, custom scripts) support scheduled restarts as a configuration option. The cohort recommendation is to restart between 03:00 and 06:00 local time when player activity is lowest.

My save file is huge. Is that normal?

Unturned save files grow over time as players build structures, drop items, and accumulate world state. A heavily-played server can produce save files of several hundred megabytes. The cohort recommendation is to monitor save file growth over time; runaway growth (e.g., gigabytes within days) is a sign of a mod accumulating state inappropriately and warrants investigation. The data redundancy and storage architecture article documents storage planning for high-growth save scenarios.

Where do I get help if I cannot diagnose the crash myself?

The cohort recommendation for operators who cannot diagnose a crash from the log is to: post the crash log excerpt (the top 50 lines of Crash.txt) to the Unturned community Discord, the mod author's Discord if a specific mod is suspected, or the Smartly Dressed Games official documentation at https://docs.smartlydressedgames.com/ for engine-level questions. Including the server configuration, mod list, and reproduction steps improves the response quality dramatically.

Best practices for operators

• Configure auto-restart on crash via the server panel. The single largest reduction in downtime per crash comes from auto-restart.
• Maintain rolling save backups at hourly, daily, and weekly granularities.
• Archive Crash.txt after every crash before retrying.
• Read crash logs immediately when a crash occurs; the cause is usually identifiable within minutes.
• Vet mods on a staging server before deploying to production.
• Schedule daily restarts during off-peak hours to clear accumulated state.
• Monitor key metrics: RAM usage, tick rate, player count, disk free space.
• Maintain a per-server crash log archive so recurring patterns become visible.
• Communicate proactively with players when the server is down. A Discord message saying "investigating, ETA 10 minutes" reduces support load dramatically.

Appendix A: cohort case studies

The 57 Studios cohort case-study program documents server crash investigations to resolution. The case studies below are reproduced from the 2025 cohort review.

Case study 1: the slow mod memory leak

A cohort member operator reported recurring crashes on their RP server every 30 to 40 hours of uptime. The crashes presented as OutOfMemoryException in Crash.txt with stack traces that varied across crashes.

The diagnostic identified a third-party plugin that allocated a new in-memory cache entry on every player chat message and never freed the entries. Over 30 to 40 hours of typical RP chat activity, the cache grew until the process exhausted available RAM.

The operator workarounds:

1. Schedule a daily restart of the server, well before the 30-hour mark.
2. Replace the plugin with a version from a different author that did not exhibit the leak.
3. Report the leak to the original plugin's author.

The operator selected options 1 and 2 in parallel: the daily restart bought time, and the replacement plugin resolved the underlying leak. After the replacement, uptime extended beyond a week without crashes.

The cohort recommendation that resulted from the case study is to monitor server RAM usage over time. A monotonically increasing RAM graph with no plateaus signals a memory leak; the source can usually be identified by correlating the increase with specific player actions.

Case study 2: the corrupted save state

A cohort member reported that their server crashed immediately on world load after a routine restart. The previous shutdown had been clean; the crash on restart was unexpected. Crash.txt reported an exception during save deserialisation.

The diagnostic identified a specific player's base structure that had reached a state the server could not load. The cohort hypothesis is that an interrupted save operation during the previous shutdown left the save file in a structurally invalid state.

The fix was to restore from the previous hourly backup. The restore lost approximately 45 minutes of player progress but allowed the server to come back online.

The cohort recommendation that resulted from the case study is twofold: maintain frequent rolling backups (hourly granularity) so that any restore loses minimal player progress, and configure save operations to complete before any shutdown so that the save file is never structurally invalid.

Case study 3: the EAC component crash

A cohort member reported that their server crashed approximately every 90 minutes with an EAC-related exception. The crash recurred regardless of player count and was not tied to any specific mod or player action.

The diagnostic identified that the server's EAC component had not been updated to match a recent Unturned client update. The client-server EAC handshake was succeeding initially but failing periodically as new client sessions arrived with the updated EAC protocol.

The fix was to reinstall the server-side EAC component, which pulled the latest version. After the reinstall, the 90-minute crash pattern did not recur.

The cohort recommendation that resulted from the case study is to update server-side EAC components alongside Unturned game updates. Operators who run the server on a panel that automatically updates Unturned should confirm that the panel also updates EAC; some panels handle them separately and require explicit operator action for EAC updates.

Appendix B: PowerShell snippets for crash diagnostics

The PowerShell snippets in this appendix are the cohort-validated set for crash investigations on Windows server hosts. Each snippet is verified against Windows PowerShell 5.1.

Snippet 1: archive Crash.txt with a timestamp

# Archive Crash.txt to a timestamped file in the same folder
$serverPath = "C:\UnturnedServer"
$crashFile = Join-Path $serverPath "Crash.txt"
if (Test-Path $crashFile) {
  $ts = Get-Date -Format "yyyyMMdd_HHmmss"
  $dest = Join-Path $serverPath "Crash_$ts.txt"
  Copy-Item $crashFile $dest
  Write-Host "Archived to $dest"
} else {
  Write-Host "No Crash.txt present at $crashFile"
}

The snippet preserves each crash log for later analysis. The cohort recommendation is to run the archival snippet as a panel post-crash hook so that every crash log is automatically preserved.

Snippet 2: extract the top 50 lines of Crash.txt

# Extract the most diagnostically useful section of Crash.txt
$serverPath = "C:\UnturnedServer"
$crashFile = Join-Path $serverPath "Crash.txt"
if (Test-Path $crashFile) {
  Get-Content $crashFile -TotalCount 50
} else {
  Write-Host "No Crash.txt present"
}

The first 50 lines of Crash.txt contain the header, exception summary, and top of the stack trace; this is the principal diagnostic content.

Snippet 3: monitor server process memory usage over time

# Sample server memory usage every 60 seconds for an hour
for ($i = 0; $i -lt 60; $i++) {
  $proc = Get-Process -Name "Unturned" -ErrorAction SilentlyContinue
  if ($proc) {
    $memMB = [math]::Round($proc.WorkingSet / 1MB, 2)
    Write-Host "$(Get-Date -Format 'HH:mm:ss') | RAM: $memMB MB"
  } else {
    Write-Host "$(Get-Date -Format 'HH:mm:ss') | Process not running"
  }
  Start-Sleep -Seconds 60
}

The snippet samples the server process's RAM usage every minute over an hour. A monotonically increasing trend signals a memory leak; a flat or oscillating trend signals stable memory usage. The cohort recommendation is to run the snippet for at least 24 hours when investigating suspected leaks.

Snippet 4: check Windows Event Viewer for OS-level errors

# Show the 20 most recent Application errors that may correlate with the crash
Get-WinEvent -LogName Application -MaxEvents 100 |
  Where-Object { $_.LevelDisplayName -eq "Error" } |
  Select-Object -First 20 TimeCreated, ProviderName, Id, Message |
  Format-Table -AutoSize -Wrap

The Windows Event Viewer captures OS-level errors that may not appear in Crash.txt. The cohort recommendation is to consult the event log when Crash.txt is empty or when the crash signature points to OS-level conditions.

Snippet 5: tail the live server log for tick rate degradation

# Tail the live server log; useful for catching degradation before a crash
$logPath = "C:\UnturnedServer\Logs\Server.log"
Get-Content -Path $logPath -Wait -Tail 20

The snippet streams the latest log lines in real time. The cohort recommendation is to keep a tail window open during high-load periods so that degradation patterns become visible before they cascade into a crash.

Appendix C: transition to self-hosting

A meaningful share of recurring crash patterns trace back to environmental factors: undersized hardware, unreliable power, unreliable network, or shared hosting noisy-neighbor conditions. These factors are largely outside the scope of in-game troubleshooting; they are properties of the host environment the server runs in.

The 57 Studios cohort has documented a self-hosting configuration that addresses these factors and minimises crash frequency. The configuration is the subject of the Self-Hosting section of this wiki. Operators who are running into recurring crashes that do not appear to have an in-Unturned cause are likely to find the answer in environmental conditions and should consult:

• Why Self-Hosting is Preferred — the case for self-hosting as the configuration that produces the lowest crash frequency, and the cohort-validated reasoning that brought 57 Studios to this conclusion.
• Recommended Server Hardware — hardware sizing for various player counts and modding levels.
• Power and UPS Configuration — power conditioning that prevents brownout-induced crashes.
• Backup Generator Configuration — extended-outage power continuity.
• Network Infrastructure and Switching — LAN configuration that prevents local network issues.
• Cellular Failover for ISP Redundancy — internet continuity through ISP outages.
• Data Redundancy and Storage Architecture — storage configuration that prevents save corruption.
• Setting Up Your Server Panel — operator tooling for routine operations and recovery.

If you operate your own server, the Self-Hosting section walks through the documented production-grade configuration that minimizes crash frequency.

Appendix D: post-crash operator checklist

The 57 Studios cohort recommends a post-crash checklist that the operator runs immediately after any unexpected server exit. The checklist takes approximately ten minutes and ensures that the cause is captured before any retry overwrites the evidence.

Post-crash step	Action	Why it matters
Archive Crash.txt	Copy to timestamped backup file	Next crash overwrites the log
Archive Server.log	Copy the last hour's log content	Context leading up to the crash
Note the timestamp	Record exact wall-clock time of the crash	Cross-reference with OS event log
Note player count	Record approximate player count immediately before	Distinguishes load-related from time-correlated
Note recent changes	Record any mod, plugin, or configuration change in the last 24 hours	Identifies introduced instability
Check OS event log	Confirm no OS-level errors at the crash time	Identifies hardware or OS-level cause
Check disk free space	Confirm sufficient space available	Disk-full crashes are recoverable but recurring
Check available RAM	Confirm host has expected free RAM	Identifies memory pressure
Check tick rate trend	Review the last hour's tick rate readings	Identifies gradual degradation
Decide on restart strategy	Auto-restart, manual restart, or save restore	Different causes call for different responses

A thorough post-crash checklist after every crash builds a per-server crash archive that becomes increasingly valuable over time. Operators who maintain the archive over months identify recurring patterns that no single crash log would reveal.

Appendix E: communicating with players during downtime

When the server is down, the operator's communication with the player base affects both player retention and the time the operator spends fielding support questions. The cohort-validated communication patterns:

Communication channel	When to use	Typical content
Discord announcement	All outages	"Server down, investigating, ETA 10 minutes"
Discord pinned status	Extended outages	Updated every 15 minutes with current status
Server browser description	All outages where the operator controls the listing	"Maintenance window; back at HH:MM"
Community forum or website	Multi-hour outages	Detailed post-mortem after resolution
Direct message to active players	Crashes during a scheduled event	Personal acknowledgement and ETA

The cohort recommendation is to over-communicate rather than under-communicate. A brief "still working on it" message every 15 minutes during an extended outage dramatically reduces inbound player questions and preserves goodwill.

Post-mortem after major incidents

For major incidents (multi-hour outages, save data loss, recurring crash patterns), the cohort recommendation is to publish a brief post-mortem after resolution. The post-mortem includes:

1. What happened (the user-visible symptom).
2. What caused it (the underlying technical cause).
3. What was done to resolve it (the steps taken).
4. What will prevent it from recurring (the configuration changes or monitoring added).
5. What was lost (any save data loss or progress impact).

Operators who publish post-mortems on major incidents build credibility with their player base. Players generally accept that crashes happen; they lose patience with operators who do not communicate about them.

Appendix F: distinguishing crashes from other downtime types

Not every "the server is down" event is a crash. The table below distinguishes the principal types of downtime so the operator can apply the right remedy:

Downtime type	Signature	Remedy
Crash	Crash.txt present; unexpected exit	Diagnose from crash log
Scheduled restart	Operator-initiated; clean shutdown log	None; expected behaviour
Auto-restart	Panel log shows restart triggered	Confirm trigger condition
Host power loss	No graceful shutdown; OS reports unexpected boot	Investigate power conditioning
Host OS reboot	OS update or operator action	Reschedule for off-peak hours
Network outage at host	Host still up but unreachable	ISP or network configuration issue
Network outage at player	Specific player cannot reach server while others can	Player's network issue
DDoS or attack	Network saturation; flood of incoming connections	Mitigation through provider
Panel software failure	Panel cannot manage server; Unturned process status unknown	Restart panel service
Disk full	Server cannot write logs or saves; crashes during save	Free disk space; investigate growth

The diagnostic in this article assumes a true crash (Unturned process exited unexpectedly with Crash.txt written). The other downtime types have different remedies and are addressed in their respective articles.

Appendix G: monitoring and alerting configuration

The cohort recommendation for production Unturned servers is to configure monitoring and alerting so that crashes are detected and responded to without the operator having to manually check. The cohort-validated monitoring stack:

Monitoring element	What it measures	Alert threshold
Server process status	Whether Unturned.exe is running	Alert if not running
Server port reachability	Whether the game port responds	Alert if unreachable for 60 seconds
RAM usage	Current process RAM consumption	Alert above 80% of allocated
Tick rate	Current simulation tick rate	Alert below target tick rate
Player count	Currently connected players	Informational; no alert
Disk free space	Available space on the server drive	Alert below 5 GB
CPU utilisation	Host CPU usage	Alert sustained above 90%
Network throughput	Bandwidth in and out of the server	Alert at saturation
Save file size	Trend in save file size over time	Alert on runaway growth
Crash.txt timestamp	When the last crash was logged	Alert on any new crash log

The 57 Studios cohort uses Netdata Cloud for the monitoring layer, integrated with custom check scripts for Unturned-specific metrics. The full monitoring configuration is documented in the self-hosting section under the panel setup article.

The cohort recommendation is to start with the first four metrics (process status, port reachability, RAM, tick rate) on day one, and expand the monitoring footprint as operational experience identifies additional metrics worth alerting on.

Appendix H: when the crash points to a fundamental misfit

Some recurring crash patterns are not bugs but symptoms of a fundamental mismatch between the server's workload and its environment. The cohort-validated table below identifies the most common misfit patterns and the structural remedies:

Misfit pattern	What it looks like	Structural remedy
Player count exceeds host capacity	Crashes correlate with peak player count; tick rate degrades before crash	Upgrade host or lower max player count
Mod load exceeds host capacity	Crashes after each new mod added; RAM usage rises with mod count	Move to higher-spec host; trim mod list
Save state outgrows storage IOPS	Saves take longer over time; eventually time out and crash	Move to faster storage (NVMe)
Network workload exceeds host capacity	Crashes correlate with network burst events; players disconnect en masse	Move to host with higher bandwidth allocation
Operator workload exceeds available time	Crashes go undiagnosed for hours or days	Delegate operator duties or simplify configuration
Hosting provider quality below cohort baseline	Inexplicable crashes that resolve on different hosting	Move to a known-good hosting provider
Power instability at the host location	Crashes correlate with weather, time of day, or local power events	Add UPS and conditioning; see power configuration
ISP instability at the host location	Crashes correlate with ISP outages	Add failover ISP; see cellular failover article

The cohort recommendation when a misfit pattern is identified is to address the structural cause rather than continue tuning the in-game configuration. Tuning yields diminishing returns against a fundamental misfit; the structural remedy is the answer.

The Self-Hosting section of this wiki documents each of the structural remedies in detail. Operators reaching the limits of in-Unturned diagnosis are likely to find the answer in the structural remedies documented there.

Appendix I: cohort-validated baseline crash rates

The 57 Studios cohort instrumented crash rates across the principal hosting configurations in active cohort use. The table below documents the median crash rate for each configuration, measured in mean time between failures (MTBF) hours.

Hosting configuration	Median MTBF (hours)	Notes
57 Studios self-hosted (documented configuration)	Above 720 (30 days)	Cohort target
Self-hosted, undocumented configuration	168 to 336 (1 to 2 weeks)	Typical for cohort members in their calibration year
Premium dedicated hosting	240 to 480 (10 to 20 days)	Variable by provider
Shared VPS hosting (4 GB RAM tier)	48 to 120 (2 to 5 days)	Limited by noisy neighbors
Shared VPS hosting (8 GB RAM tier)	72 to 168 (3 to 7 days)	Better but still shared
Game hosting provider (Unturned-specific)	96 to 240 (4 to 10 days)	Variable by provider
Home consumer connection without UPS	24 to 72 (1 to 3 days)	Limited by residential power and ISP
Home consumer connection with UPS and documented configuration	240 to 720 (10 to 30 days)	Approaches self-hosted baseline

The cohort-validated takeaway is that the gap between the lowest-MTBF and highest-MTBF configurations is roughly an order of magnitude. The dominant variable is not the hosting price but the configuration discipline. Cohort members who follow the documented self-hosting configuration achieve crash rates roughly 10x lower than cohort members on undocumented shared hosting.

The cohort recommendation for any operator running into recurring crashes is to compare their configuration to the documented configuration and identify the gaps. Closing the gaps typically restores the operator to the cohort baseline MTBF.

Appendix J: example Crash.txt excerpts

The annotated excerpts below illustrate the principal crash signatures the cohort encounters. Operators reading their own Crash.txt for the first time can use these excerpts as reference patterns.

Example 1: out-of-memory exception from a mod

Unturned Server v3.x.x.x
OS: Windows Server 2022
Timestamp: 2026-05-15 03:42:18

Exception: System.OutOfMemoryException
Message: Out of memory.

Stack trace:
  at MyHeavyMod.CacheManager.AddEntry(String key, Object value)
  at MyHeavyMod.ChatHandler.OnPlayerChat(Player player, String message)
  at SDG.Unturned.ChatManager.ServerSendChatMessage(...)
  at SDG.Unturned.ChatManager.Update()

The top frame identifies MyHeavyMod.CacheManager.AddEntry as the proximate cause. The mod is allocating cache entries that exhaust available RAM. The remedy is to identify the mod (here labeled MyHeavyMod as a placeholder), roll it back to a previous stable version, or remove it from the server.

Example 2: EAC component crash

Unturned Server v3.x.x.x
OS: Linux (Ubuntu 22.04)
Timestamp: 2026-05-15 04:17:33

Exception: EAC.EasyAntiCheatException
Message: Anti-cheat subprocess exited unexpectedly.

Stack trace:
  at EAC.EasyAntiCheat.HandleSubprocessExit()
  at EAC.EasyAntiCheat.OnClientHandshake(Player player)
  at SDG.Unturned.Player.Connect()

The signature points to EAC. The remedy is to reinstall the server-side EAC component. The cohort recommendation is to confirm the EAC version matches the current Unturned client release.

Example 3: native crash with no managed stack

Unturned Server v3.x.x.x
OS: Linux (Ubuntu 22.04)
Timestamp: 2026-05-15 05:01:09

Signal: SIGSEGV (segmentation fault)
Faulting address: 0x00007f3e2a4b0010

Native stack (truncated):
  0x... libunity.so
  0x... libc.so.6

A native crash with no managed stack trace indicates a fault in the Unity engine or in native code. The cohort recommendation is to capture any available crash dump, archive Crash.txt, and report to Smartly Dressed Games via the official documentation channels at https://docs.smartlydressedgames.com/.

Example 4: disk write failure

Unturned Server v3.x.x.x
OS: Windows Server 2022
Timestamp: 2026-05-15 06:11:42

Exception: System.IO.IOException
Message: There is not enough space on the disk.

Stack trace:
  at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
  at SDG.Unturned.SaveManager.WriteSave(String path, Byte[] data)
  at SDG.Unturned.SaveManager.AutoSave()

The signature identifies disk full as the cause. The remedy is to free disk space and confirm save retention is configured to prune older saves automatically.

The four examples above are the most common crash signatures across the cohort. Operators who recognise their Crash.txt against these examples can apply the corresponding remedy directly. Operators whose Crash.txt does not match any of the examples should consult the crash signature reference table earlier in this article and, if needed, escalate to the relevant mod author or to Smartly Dressed Games for engine-level issues.

Cross-references

• Server Stuck on Loading Screen — the previous article in the troubleshooting section; covers loading-screen failures that can be mistaken for crashes.
• Why is the Server Down? — covers the broader question of why a server is unreachable, of which crashes are one cause.
• Is the Server Up? — covers how to confirm server status from the player perspective.
• Server Connection Timeout — covers the connection failures that follow a crash before the server is restored.
• Why Self-Hosting is Preferred — the next article; the bridge into the Self-Hosting section.

External references

• Unturned official Steam Store page: https://store.steampowered.com/app/304930/Unturned/
• Smartly Dressed Games official modding documentation: https://docs.smartlydressedgames.com/

Document history

Version	Date	Author	Notes
1.0	2024-09-22	57 Studios	Initial publication. Player and operator perspectives.
1.1	2024-12-18	57 Studios	Added crash signature reference table.
1.2	2025-03-15	57 Studios	Added EAC component crash diagnostics.
2.0	2025-07-30	57 Studios	Major revision. Added PowerShell snippets and self-hosting transition.
2.1	2026-05-18	57 Studios	Annual refresh. Added cohort case studies.

Glossary

• Crash.txt — the principal Unturned server crash log, written to the server installation folder on unexpected exit.
• OOM kill — Out-Of-Memory kill, the Linux kernel mechanism that terminates processes during memory exhaustion.
• Stack trace — the call sequence at the point of the exception, recorded in Crash.txt.
• EAC — Easy Anti-Cheat, the anti-cheat system used by Unturned. Has both client and server components.
• Auto-restart — a server panel feature that automatically restarts the Unturned process after an unexpected exit.
• Memory leak — the gradual accumulation of allocated memory that is never freed, eventually exhausting available RAM.
• Tick rate — the number of simulation updates per second computed by the server. Degradation signals impending crash.
• Save state — the persisted world state on disk, including player positions, structures, and world objects.

Closing note

An Unturned server crash is best understood as two events: the immediate exit of the server process, and the longer-running pattern that caused it. The immediate exit is documented in Crash.txt and can usually be diagnosed within minutes. The longer-running pattern requires the operator to maintain a per-server crash archive and look for the common element across multiple incidents.

The cohort-validated workflow is to archive every Crash.txt, read the top of the stack trace, cross-reference with installed mods and plugins, and remedy the proximate cause. Repeated crashes from the same proximate cause indicate that the cause has not been addressed; repeated crashes from different proximate causes indicate that the host environment itself is unstable.

When the diagnosis points to environmental conditions rather than in-game causes, the answer is usually in the Self-Hosting section of this wiki. The Self-Hosting section documents the production-grade configuration that 57 Studios uses to minimise crash frequency, and it is the recommended next reading for any operator who has worked through this troubleshooting section and reached the limits of what in-game adjustments can address.

Next steps

If you operate your own Unturned server and are reading these troubleshooting articles to reduce crash frequency on your own deployment, the Self-Hosting section is the natural next stop. Continue to Why Self-Hosting is Preferred to begin the operator-facing material on production-grade Unturned server operation.