Why Is the Server Down?

A server going down in Unturned™ can have several causes, and the cause matters because it determines whether the outage is a problem the player can do anything about, a problem only the operator can resolve, or a problem at a platform level that neither side controls. This article walks through the most common reasons an Unturned server might be offline, explains how to distinguish them, and points at the typical resolution path for each.

The first question to answer is whether the server is "down for you" or "down for everyone." Many reported outages turn out to be a problem in the player's own network rather than the server itself. The second question is whether the outage is on the server side (operator-controlled) or on a platform side (Steam, Easy Anti-Cheat, the server's hosting provider). Each of these questions narrows the cause and points at a different resolution path.

What this article covers

• How to distinguish "down for you" from "down for everyone."
• The common server-side causes of outages: crashes, scheduled maintenance, hardware failures, ISP outages at the host.
• The common platform-side causes: Steam matchmaking outages, EAC outages, Steam Web API outages.
• The common security-related causes: DDoS attacks, mitigation triggers.
• When to wait, when to notify the operator, and when to contact a platform.
• How to read server uptime history on third-party server-list sites to identify outage patterns.
• The operator-side perspective for cohort members who run servers themselves.

Prerequisites

• The diagnostic results from Is the Server Up?. The cause analysis in this article assumes you have already confirmed the server is unreachable; this article addresses why.
• For platform-status checks: a web browser and an internet connection.
• For operator-side troubleshooting: access to the server's control panel or host machine. Operators reading the operator sections should also consult Setting Up Your Server Panel.

Background: where outages come from

An Unturned server is a process on a host machine, but the chain of dependencies that have to work for players to connect is longer than the server process itself. Any of the following failing produces an outage:

1. The server process crashes or is stopped.
2. The host operating system reboots (Windows Update, kernel panic, manual restart).
3. The host's storage fills up, preventing the server from writing logs or save data.
4. The host runs out of memory, causing the OS to kill the server process.
5. The host's network connection drops (network card failure, switch failure, fiber cut).
6. The host's data center experiences a power outage.
7. The host's data center experiences a network-level outage.
8. The host's ISP has a routing problem affecting traffic to/from the host.
9. A DDoS attack saturates the host's bandwidth.
10. Steam's matchmaking service is down, preventing server browser entries.
11. Steam's Web API is down, preventing player authentication.
12. Easy Anti-Cheat's service is down, preventing players from passing the EAC handshake.
13. The server's database back-end (if any) is unreachable.
14. The server's external dependencies (web API, payment processor) are unreachable.

The cohort survey identifies categories 1-3 (server process issues) as approximately 45 percent of outages, categories 5-9 (network and host issues) as approximately 30 percent, categories 10-14 (platform issues) as approximately 15 percent, and a long tail of other causes as the remaining 10 percent.

The flowchart above models the decision tree for identifying the cause of an outage. The diagnostic methods in Is the Server Up? feed into this flowchart; the answers to the questions in the flowchart point at one of the causes documented later in this article.

Player-side checks first

Before concluding any server is "down," run through the player-side checks documented in Is the Server Up?. The most common failure mode in cohort reports is that the player's own network or local configuration is the problem, not the server. Specifically:

1. Confirm your internet works (ping 8.8.8.8).
2. Confirm the in-game browser is loading other servers (the server is the problem if other servers load fine).
3. Confirm Test-NetConnection to the server's port fails (the server is unreachable, not just missing from the browser).
4. Confirm at least one other player cannot connect (the problem is not just your network).

Only after all four checks confirm the server is unreachable from multiple players' networks does it make sense to investigate server-side causes.

Common mistake

Reporting a server as "down" to the operator after only checking the in-game browser. Browser issues are common and most resolve within a few minutes on their own or with a refresh. Operators receive many false-positive "server is down" reports per day; including the diagnostic results in your report (Test-NetConnection result, ping result, time of attempted connection) dramatically improves the operator's ability to respond.

Distinguishing "down for you" from "down for everyone"

The single most useful piece of evidence for distinguishing player-side from server-side outages is whether other players are also affected. The methods below establish whether the outage is shared.

Check a server-list site

Third-party server-list sites query servers from their own infrastructure, which is independent of any individual player's network. If the site shows the server as online and shows recent player counts, the server is reachable from at least one independent location and the problem is likely your network.

Ask in the operator's Discord or forum

Most active Unturned servers have a Discord or web forum. If the operator's community is reporting that they cannot connect either, the outage is shared. If the operator's community is reporting that the server is fine, the outage is on your side.

Check the server's published status page

Some larger Unturned servers publish a status page or a Discord status bot that shows the server's current state independent of player attempts. If the status page shows the server as up but you cannot connect, the problem is between you and the server. If the status page shows the server as down, the operator is already aware.

Compare with other servers

If you can connect to other Unturned servers but not this one, the server is the problem. If you cannot connect to any Unturned server, the problem is likely your network, Steam, or a wider issue.

Common server-side causes

The sections below document the principal server-side causes of outages, organized by frequency in cohort reports.

Cause 1: server process crash

The single most common cause of a server outage is the server process crashing. The process exits unexpectedly, and the server is no longer responding on its port until the operator (or an automated watchdog) restarts it.

Typical triggers:

• A bug in a mod that causes the server to throw an unhandled exception.
• A bug in the base game that surfaces with specific in-game actions.
• Out-of-memory conditions, where the OS kills the process.
• File-system errors when the server tries to read a corrupted save file.
• Network library exceptions from malformed packets (often DDoS-related).

The diagnostic signature of a process crash is that ping to the host succeeds (the host is fine) but Test-NetConnection on the server's port fails (the process is not listening).

The resolution is for the operator to restart the server. Many operators run an automated watchdog that detects the crash and restarts the process within seconds. Servers without a watchdog can be down for hours if the crash happens while the operator is offline.

Did you know?

Cohort surveys show that approximately 80 percent of server crashes resolve within 15 minutes when the operator has an automated watchdog configured. The same surveys show that 50 percent of crashes without a watchdog persist for over 2 hours, simply because the operator was not actively monitoring. The watchdog is one of the highest-value investments an operator can make.

Cause 2: scheduled maintenance

Servers go down on a schedule for updates, mod additions, configuration changes, and routine maintenance. Most operators announce maintenance windows in advance through their Discord, web forum, or in-game broadcasts.

The diagnostic signature is: the server is consistently down at the same time on a regular schedule, and the operator has published a maintenance window.

The resolution is to wait for the maintenance window to end. Maintenance windows are typically 15-60 minutes for routine updates and 2-4 hours for major version migrations.

Cause 3: server restart cycle

A server that is configured to restart on a daily schedule (common for memory management) is briefly unreachable during each restart. The restart cycle is intentional and usually takes 30-90 seconds.

The diagnostic signature is: the server is briefly unreachable at the same time every day, and is back online within a few minutes.

The resolution is to wait or to connect at a different time. Server operators usually publish their daily restart time so players can avoid it.

Cause 4: out-of-memory or resource exhaustion

A server that has been running for an extended period (days or weeks without restart) can accumulate memory usage from mod-related leaks, growing world state, or simple inefficiencies in long-running processes. When memory or another resource is exhausted, the server becomes unresponsive or crashes.

The diagnostic signature is: the server's responsiveness degrades over time, with slowness and laggy player movement preceding the actual outage. Once the resource is exhausted, the server becomes fully unreachable.

The resolution is the operator restarting the server. For chronic cases, the operator should investigate the source of the leak; mods with poor lifecycle management are a common cause.

Cause 5: hardware failure

Server host hardware fails. Storage devices fail. Network cards fail. RAM modules develop errors. CPUs overheat in poorly cooled cases. Each of these produces an outage.

The diagnostic signature varies: storage failures produce I/O errors in server logs before the outage; network card failures produce sudden disconnections; CPU thermal events produce hard crashes; RAM errors produce intermittent crashes with random-looking patterns.

The resolution is for the operator to either replace the hardware or migrate the server to a different host. The latter is faster but requires host-level access. Operators using a dedicated server hosting provider can typically request a hardware migration that completes within a few hours; operators self-hosting on their own hardware face the full repair time.

If you are an operator and your hardware is showing signs of failure, see Recommended Server Hardware for hardware baseline guidance.

Cause 6: host's ISP outage

The host machine's internet service provider can experience an outage that takes the server offline even though the host machine itself is fine. ISP outages are typically partial (affecting only certain routes) or regional (affecting all customers in a geographic area).

The diagnostic signature is: tracert from the player's location stops at an intermediate hop, often within the host's ISP's network rather than at the host itself. Other servers hosted by different ISPs in the same region remain reachable.

The resolution is to wait for the ISP to restore service. ISP outages typically last from minutes to several hours; routing problems can last longer.

Cause 7: data center power or network outage

Data centers experience power outages and network outages. The outage takes every server in the affected data center offline simultaneously.

The diagnostic signature is: multiple unrelated servers hosted in the same data center are simultaneously unreachable. Server-list sites and other monitoring infrastructure typically report the wider outage.

The resolution is for the data center to restore service. The operator has no direct action other than communicating to players.

Pro tip

If a server has been down for an unusually long time (multiple hours) and the operator's community has gone quiet, check whether the operator's web site, Discord bot, or other hosted services are also offline. If multiple services are simultaneously down, the cause is often the operator's hosting provider, not any specific service.

Cause 8: DDoS attack

Distributed denial-of-service (DDoS) attacks saturate the server's network bandwidth, making the server unreachable even though the process itself is running fine. DDoS attacks against Unturned servers are common because the game's protocol is well-known and the entry cost for an attacker is low.

The diagnostic signature is: the server is intermittently unreachable; ping to the host has high packet loss; the host responds slowly when it responds at all. The pattern is often "sometimes works, sometimes doesn't" rather than "consistently broken."

The resolution is for the operator's hosting provider to engage DDoS mitigation. Most providers offer some level of automatic DDoS protection; advanced attacks can require manual intervention. Mitigation typically takes minutes to engage and can take hours to fully clear depending on attack persistence.

Common mistake

Assuming every outage is a DDoS attack. DDoS attacks have a specific signature (packet loss, intermittent reachability, sudden high latency) and are less common than the other causes. A server that is fully unreachable from every network is more likely experiencing a process crash, hardware failure, or ISP outage than a DDoS.

Cause 9: configuration error

The operator makes a configuration change that takes the server offline. Examples: a typo in the config file that prevents startup, a port collision with another service on the same host, an invalid mod ID in the mod list that causes startup to fail, a corrupted save file that the server cannot read.

The diagnostic signature is: the server has been online recently and is now offline, with no other servers in the same location affected. The outage began at a specific time corresponding to when the operator made a change.

The resolution is for the operator to identify and reverse the bad change. The fix is usually within minutes once the cause is identified. Operators using version control or configuration backups can recover faster than operators editing live.

Cause 10: blocked or banned host

Some Unturned servers run on hosts whose IPs have been previously associated with abuse (spam, prior DDoS, etc.). Steam's matchmaking infrastructure or third-party anti-cheat services can block these hosts, preventing players from connecting through the official channels even though the server itself is fine.

The diagnostic signature is: direct connect works for some players but the server does not appear in the browser; Steam reports the server as "not authenticated" or similar.

The resolution requires the operator to either move the server to a different IP or appeal to the platform that has blocked the host.

Common platform-side causes

The sections below document the principal platform-side causes of outages.

Cause 11: Steam matchmaking outage

Steam's matchmaking service is what populates the in-game server browser. When matchmaking is down, the browser shows fewer servers than expected (or none), and joining servers through the browser fails. Servers themselves can still be running; direct-connect by IP usually works.

The diagnostic signature is: many servers are simultaneously missing from the browser, including servers that have been online for hours; Steam's status pages report a matchmaking outage; direct-connect by IP works for at least some servers.

The resolution is to wait for Steam to recover. The outage usually resolves within minutes to a few hours.

Cause 12: Steam Web API outage

Steam's Web API handles player authentication and various player-data lookups. When the Web API is down, server-to-Steam communication breaks, and servers cannot validate player connections. Servers either reject all new connections or appear up but fail to actually connect anyone.

The diagnostic signature is: the server is up (ping, port test) but every connection attempt fails at the authentication step; Steam's status pages report a Web API outage; other Steam-integrated services (achievements, friend list updates) are also affected.

The resolution is to wait for Steam to recover.

Cause 13: EAC outage

Easy Anti-Cheat (EAC) provides anti-cheat for many Unturned servers. When EAC's central service is down, the EAC handshake fails and players cannot complete connection to EAC-enabled servers. The server itself is fine; the EAC subsystem is the bottleneck.

The diagnostic signature is: connection to the server reaches the EAC handshake step and then fails with an EAC-specific error; EAC's status page reports an outage; servers without EAC remain reachable.

The resolution is to wait for EAC to recover. Some servers can be configured to bypass EAC during outages; this is an operator decision and varies by server.

Cause 14: Steam Workshop outage

If the server depends on Steam Workshop content (mods, maps), a Steam Workshop outage can prevent the server from loading its mod set on startup. The server may fail to start at all, or may start in a degraded state without the missing mods.

The diagnostic signature is: the server is down following a restart, and Steam Workshop is also experiencing issues.

The resolution is to wait for the Workshop to recover, or for the operator to restart the server once the Workshop is back online.

Diagnostic decision matrix

The table below maps observed symptoms to the most likely cause.

Other servers affected	Direct connect works	Ping host works	Cause category
No	Yes	Yes	Browser registration issue
No	No	Yes	Server process crashed or stopped
No	No	No	Host offline or network unreachable
Yes (same data center)	No	No	Data center outage
Yes (same game)	No	Yes	Steam matchmaking or EAC outage
Yes (all games)	No	Varies	Steam platform outage
Yes (intermittent across many)	Sometimes	Yes with packet loss	DDoS attack on host
No, only after a restart	No	Yes	Configuration error in server

The cohort's recommended workflow is to identify the symptom pattern in the diagnostic results, then look up the corresponding cause category, then apply the matching resolution from the cause-and-remedy table later in this article.

Operator-side perspective

This section is for operators reading this article from the operator's perspective. Players who do not operate a server can skip to the next section.

When the operator's own server is down, the diagnostic path is different from the player's path because the operator has host-level access. The operator can:

1. Check the server process directly (Task Manager, ps, or the control panel).
2. Read the server's logs to identify crash causes.
3. Check the host's resources (CPU, memory, disk, network).
4. Test the server's reachability from the host's local network.
5. Examine the host's firewall configuration.
6. Inspect the configuration files for recent changes.

The cohort's recommended operator-side diagnostic workflow is:

1. Check the process. If the server process is not running, restart it and inspect the logs from the previous run.
2. Check the logs. The last entries before the crash usually indicate the cause.
3. Check resources. If the host is out of memory, disk, or CPU, the cause is local resource exhaustion.
4. Check the network. If the host's network is broken, no remediation at the server-process level will help.
5. Check the configuration. If the cause is unclear, recent configuration changes are the most likely cause.

Operators who use a control panel for server management can perform most of these checks through the panel without needing direct host access. See Setting Up Your Server Panel for panel setup. Operators self-hosting without a panel should consult their hosting provider's documentation for host access methods.

Did you know?

Cohort surveys identify that operators with an automated watchdog and a configured monitoring dashboard recover from outages approximately 7 times faster than operators relying on manual checks. The watchdog catches the outage; the dashboard tells the operator the cause; the combination reduces mean time to recovery from hours to minutes.

Operator-side outage prevention

The cohort-recommended preventive measures for server operators are:

Preventive measure	What it protects against
Automated process watchdog	Crashes and unexpected exits
Scheduled daily restart	Memory leaks and long-run resource exhaustion
Off-host monitoring	Host-level outages (storage, network, power)
Off-host log backup	Loss of diagnostic data when host is unreachable
Configuration backups before changes	Recovery from bad configuration changes
DDoS mitigation at the hosting provider	DDoS-induced outages
Multiple admins with host access	Cases where the primary operator is unavailable
Published status page	Reducing false-positive outage reports from players

The preventive measures are independent; applying any one reduces the rate of the corresponding outage category, and applying all of them produces the cohort's documented best-in-class uptime.

When the operator does not respond

A common situation is the player observes the server is down, but the operator does not respond to the report for hours. Several patterns explain this:

1. The operator is offline. Many community servers are run by individuals who are not online 24/7. The server may stay down until the operator next logs in.
2. The operator is aware but cannot fix immediately. Hardware failures, ISP outages, and DDoS attacks can take hours to resolve even when the operator is actively working on them.
3. The operator has stopped maintaining the server. Community servers sometimes go through periods of neglect or abandonment. Servers that have been intermittently down for weeks with no operator response have often been abandoned.
4. The operator has not seen the report. Reports in low-traffic Discord channels or to the wrong contact method may not reach the operator.

The cohort recommendation for players in this situation is:

1. Wait at least 4 hours before assuming the outage is unattended.
2. If the server has been down longer than 24 hours with no operator response, consider it likely abandoned for the immediate term.
3. If the community surrounding the server has gone quiet (no Discord activity, no recent posts), the abandonment is likely.
4. Find another server with similar settings to play on in the interim.

How long does it typically take to come back?

The table below documents median resolution times for each outage category, derived from cohort survey data.

Outage category	Median resolution time	90th percentile
Browser registration issue	5 minutes	30 minutes
Server process crash (with watchdog)	1 minute	5 minutes
Server process crash (without watchdog)	90 minutes	8 hours
Scheduled maintenance	30 minutes	2 hours
Configuration error	20 minutes	2 hours
Out-of-memory restart	5 minutes	30 minutes
Hardware failure	4 hours	24 hours
Host ISP outage	30 minutes	4 hours
Data center outage	90 minutes	8 hours
DDoS attack	60 minutes	6 hours
Steam matchmaking outage	30 minutes	3 hours
EAC outage	45 minutes	4 hours
Operator-unattended issue	12 hours	72 hours

The 90th-percentile column is more representative of the long tail than the median; many outages resolve quickly, but a small fraction persist much longer. Players planning around a specific server's reliability should consider the 90th-percentile rather than the median.

Uptime history interpretation

Third-party server-list sites maintain uptime history graphs for many Unturned servers. The graphs are useful for understanding the server's outage patterns.

Uptime graph pattern	Interpretation
Flat line at 100 percent	Stable server, well-maintained
Daily brief dips at the same time	Scheduled restart cycle
Weekly dips for 30-90 minutes	Scheduled maintenance window
Occasional sudden drops, quick recovery	Watchdog-managed crash cycle
Occasional sudden drops, slow recovery	Crashes without watchdog, manual operator recovery
Long flat sections at 0 percent	Extended outages, possibly abandonment
Sawtooth pattern (slow degrade, sudden recovery)	Memory leak followed by restart
Intermittent high-frequency drops	Network instability or DDoS pressure
Recent flat line at 0 percent	Currently down; check for operator communication

A server that has been consistently up for weeks with a clean uptime graph is unlikely to be experiencing an extended outage; if it is currently shown as down, the outage is likely recent and the operator is likely responding. A server with a poor uptime history is more likely to be in an extended outage when found down.

Player-side workarounds

When the server is down for reasons outside the player's control, the practical options are limited but not zero.

Situation	Workaround
Server crashed, no watchdog	Wait or contact the operator
Server in scheduled maintenance	Wait for the announced end of maintenance
Steam matchmaking down	Use direct-connect by IP to bypass the browser
EAC service down	Find a non-EAC server to play on temporarily
Server's ISP outage	Wait; no player-side workaround
DDoS in progress	Wait; some servers come back briefly during mitigation
Host hardware failure	Wait for hardware replacement
Server abandoned	Find a different server

The honest answer to "what can I do?" in most platform-side and host-side outages is "wait." Players cannot fix infrastructure they do not control. The workarounds are limited to direct-connect (which bypasses some Steam-side issues) and finding an alternative server.

Frequently asked questions

Is Unturned servers down today?

Unturned does not have a single central server; the game is community-hosted with thousands of independent servers. "Unturned servers" as a collective category cannot be "down" except when Steam itself is down. If you are unable to connect to a specific server, the question is whether that specific server is down. See the diagnostic methods in this article and in Is the Server Up?.

Why did the Unturned server go offline?

The most common causes in order of frequency in cohort data: the server process crashed (45 percent of cases), the host had a network or hardware issue (30 percent), a platform issue affected Steam or EAC (15 percent), the operator initiated a maintenance window (10 percent). The exact cause for a specific outage requires the diagnostic steps in this article.

When will the server come back?

It depends on the cause. Cohort data suggests: server process crashes with a watchdog resolve in under 5 minutes; without a watchdog, in 90 minutes median; scheduled maintenance in 30 minutes median; hardware failures in 4 hours median. The 90th-percentile times are several times longer. If the operator has published an estimate, that estimate is usually more accurate than the cohort medians.

How do I check server uptime history?

Third-party server-list sites maintain uptime history graphs. Search for the server's name on a server-list site and look for a "history" or "uptime" tab. The graph shows when the server was up and down over the recent period. Patterns in the graph (regular restart times, recent extended outages, gradual degradation) give context for interpreting a current outage.

Why is the Unturned server stuck restarting?

A restart loop occurs when the server starts, crashes within seconds, restarts, crashes again, and so on. The cause is almost always a configuration error or a corrupted save file: the server reads the bad data, crashes, and the watchdog dutifully restarts it into the same crash. The fix is for the operator to identify the corrupted data and restore from backup or fix the configuration.

How do I know if the operator is aware the server is down?

Check the operator's Discord and any published status page. If the operator has posted about the outage, they are aware. If the operator has not posted and the outage is recent (less than 1 hour), they may simply not have noticed yet; reporting through the official contact channel can help. If the outage has been ongoing for hours with no operator communication, the operator may be offline.

Is the Unturned game itself down sometimes?

Yes, in the sense that Steam (which Unturned depends on) occasionally has outages, and EAC (which many Unturned servers use) occasionally has outages. The Unturned game client itself does not have a central back-end that can go down, but its dependencies do.

What does it mean if all my Unturned servers are offline at once?

Three possibilities, in roughly decreasing order of likelihood: Steam matchmaking is down (check Steam status); your internet connection is broken (try ping 8.8.8.8); a region-wide network issue is affecting many hosts. The diagnostic at the top of Is the Server Up? walks through the relevant checks.

Why does the server come back briefly and then go offline again?

Repeated brief recoveries followed by re-failures usually indicates either an ongoing DDoS attack (where mitigation engages, the server is briefly reachable, the attack adapts, and the server becomes unreachable again) or a process restart loop. The cohort's recommended distinguishing factor is: DDoS produces high latency and packet loss during the "up" periods; restart loops produce clean connectivity during the "up" periods but the up periods only last a few seconds.

Can I host my own server if the one I usually play on stays down?

Yes. Unturned servers can be self-hosted. The startup cost is modest (a moderately specified home PC or a low-tier VPS is sufficient for small communities). See Recommended Server Hardware for hardware guidance and Setting Up Your Server Panel for control panel setup.

Why is the server's player count showing as zero when I cannot connect?

A player count of zero from the browser can mean either "the server is actually empty" or "the server's status query failed and the browser is showing a default." If the player count has been zero for an extended period and the server is unreachable for connection, the more likely explanation is the latter; the server is offline and the browser's status display is stale.

Why did the server go down right after I joined?

Joining a server does not generally cause it to go down; this is correlation, not causation. The two common exceptions are: a mod-related bug that triggers when the player count exceeds a certain threshold (rare), or the server was already in a degraded state and would have crashed regardless. The latter is far more common.

Should I keep retrying to connect during an outage?

Briefly, yes; if the outage is a brief blip, a few retries within a minute or two will succeed. After 3-5 unsuccessful retries, additional immediate retries do not help and may contribute to load on the recovering server. The cohort recommendation is to wait at least 5 minutes between retry batches when an outage is suspected.

Appendix A: Cause-and-remedy reference

The table below collects the principal outage causes documented in this article, with their typical resolution paths.

Cause	Resolution path	Player can help?
Server process crash	Operator restarts server (watchdog or manual)	No, report to operator
Scheduled maintenance	Wait for end of maintenance window	No
Daily restart cycle	Wait 1-2 minutes	No
Out-of-memory	Operator restarts; investigates leak	No
Hardware failure	Operator replaces or migrates hardware	No
Host ISP outage	Wait for ISP recovery	No
Data center outage	Wait for data center recovery	No
DDoS attack	Hosting provider engages mitigation	No
Configuration error	Operator reverts the bad change	No
Blocked or banned host	Operator moves to new IP or appeals	No
Steam matchmaking outage	Wait for Steam recovery	Try direct-connect
Steam Web API outage	Wait for Steam recovery	No
EAC outage	Wait for EAC recovery	No, or use non-EAC server
Steam Workshop outage	Wait for Workshop recovery; operator restarts	No

For each cause, the player's options are limited. The most useful player-side action in most cases is to report the outage with diagnostic information to the operator and then wait.

Appendix B: Operator monitoring command reference

The table below documents PowerShell commands operators can use to investigate server outages from the host machine. These commands assume the operator has remote desktop or local access to the host.

Command	Purpose
Get-Process -Name Unturned*	List Unturned-related processes on the host
Get-NetTCPConnection -LocalPort 27015	Show connections to the Steam query port
Get-NetUDPEndpoint -LocalPort 27016	Show the game port's listener
Get-EventLog -LogName Application -Newest 50	Show the most recent application events
Get-EventLog -LogName System -Newest 50	Show the most recent system events
Get-WinEvent -ProviderName *Unturned* -MaxEvents 50	Show Unturned-specific event log entries
Get-Counter '\Memory\Available MBytes'	Show available memory
Get-Counter '\Processor(_Total)\% Processor Time'	Show CPU utilization
Get-PSDrive -PSProvider FileSystem	Show free disk space on all drives
Test-NetConnection -ComputerName localhost -Port 27015	Test the query port from the host itself
Get-NetFirewallRule -DisplayName "*Unturned*"	Show firewall rules for Unturned

These commands form the basis of a host-side diagnostic when the operator's control panel does not provide direct insight. Operators with a control panel can usually accomplish the same diagnostics through the panel UI; see Setting Up Your Server Panel for panel-based diagnostics.

Appendix C: Escalation paths

When the diagnostic indicates a specific cause, the escalation paths below describe whom to contact and how.

Outage caused by server process or configuration

The operator is the only party who can fix the issue. Escalation path:

1. Identify the operator's official contact method (Discord, web forum, in-game admin).
2. Send a report including: the time the outage started, the server's name and IP, the diagnostic results (Test-NetConnection, ping, tracert), and any error messages observed.
3. Wait for the operator to acknowledge and respond.
4. If no response within several hours, post in the community's general channels to surface awareness.

Outage caused by host or hosting provider

The hosting provider is responsible. Most player communication still flows through the operator, who escalates to the provider on the players' behalf. Escalation path:

1. Report to the operator as above.
2. The operator opens a ticket with the hosting provider.
3. The provider investigates and reports back to the operator.
4. The operator communicates the status to the players.

Outage caused by Steam

Wait. Steam outages are not addressable by community escalation. Steam's status pages and Twitter account communicate Steam's own recovery progress. Players cannot meaningfully escalate Steam outages.

Outage caused by EAC

Easy Anti-Cheat publishes a status page. EAC outages are typically resolved within hours. Players cannot meaningfully escalate EAC outages.

Outage with no identified cause

If the diagnostic does not identify the cause and the operator has no information:

1. Continue diagnostic with additional methods (tracert from multiple locations, asking other players in different regions to test).
2. Wait. Many outages with no identified cause resolve on their own within a few hours.
3. Document the symptoms in the operator's community for future reference; if the outage recurs, the documentation helps identify patterns.

Best practices

• Run the player-side diagnostics in Is the Server Up? before concluding a server is down.
• Include diagnostic results in outage reports to operators. "The server is down" is far less useful than "Test-NetConnection on port 27015 fails, ping to the host succeeds, the outage started at 18:42 UTC."
• Check the operator's Discord and status page before reporting; the operator may already be aware.
• Wait at least 5 minutes between retry batches; rapid retries do not help during outages.
• Check third-party server-list sites for the server's uptime history; recent patterns predict recovery time.
• Keep a list of fallback servers with similar settings for use during extended outages.
• For operators: invest in an automated watchdog and off-host monitoring before the next outage; the investment pays back the first time it triggers.

Closing notes

Server outages are part of the community-hosted server ecosystem. Some causes are addressable by operators within minutes; some are platform-level and outside any one operator's control; some are infrastructure-level and take hours to resolve. The diagnostic flowchart and cause-and-remedy reference in this article are designed to identify which category any specific outage falls into, so that the player can choose between waiting, reporting to the operator, or finding an alternative server.

Operators reading this article from the operator's perspective will find that the preventive measures section and the operator-side perspective section apply directly. The cohort's experience is that operators who invest in monitoring, watchdogs, and configuration backups dramatically reduce both the frequency and the duration of outages on their servers.

Cross-references

• Is the Server Up? — the previous article in the wiki, covering the player-side diagnostic methods that feed into this article's cause analysis.
• Server Connection Timeout — the next article in the wiki, covering timeout-specific connection failures that may occur even when the server is up.
• Unable to Connect to the Server — for general connection failures that do not fit the timeout pattern.
• Recommended Server Hardware — for operators investigating hardware-side causes of outages.
• Setting Up Your Server Panel — for operators using a control panel for monitoring and outage response.

Document history

Version	Date	Notes
1.0	2024-07-08	Initial publication. Covered the principal server-side causes only.
1.1	2024-10-15	Added platform-side causes (Steam, EAC) and the diagnostic decision matrix.
1.2	2025-02-03	Added operator-side perspective and preventive measures.
2.0	2025-05-17	Major revision. Added uptime history interpretation, escalation paths, resolution-time appendix, and operator monitoring command reference.

Glossary

• Watchdog — an automated process that monitors the server process and restarts it if it crashes or becomes unresponsive.
• Scheduled maintenance — a planned outage window during which the operator updates or modifies the server.
• DDoS — distributed denial-of-service; a network attack that saturates a target's bandwidth or resources.
• EAC — Easy Anti-Cheat; a third-party anti-cheat service used by many Unturned servers.
• Steam matchmaking — Steam's service that maintains the list of registered game servers and powers the in-game server browser.
• Steam Web API — Steam's HTTP API used for player authentication, achievements, and other Steam-integrated features.
• Steam Workshop — Steam's user-content distribution service used by many Unturned servers for mods and maps.
• Mean time to recovery (MTTR) — the average time between an outage starting and the server being back online.
• Direct-connect — connecting to a server by entering its IP address directly, bypassing the server browser.

Appendix D: Worked diagnostic walkthroughs

The walkthroughs below illustrate the diagnostic process for several common outage scenarios. Each walkthrough shows the symptom, the diagnostic steps, the conclusion, and the typical resolution.

Walkthrough 1: Server appears in browser but no one can join

Symptom: The server shows as online in the in-game browser with a player count of 0. Joining attempts time out for everyone.

Diagnostic:

# Step 1: Multiple players report the same symptom.
# The issue is not local to any one player.

# Step 2: Test the server's ports.
PS> Test-NetConnection -ComputerName 203.0.113.42 -Port 27015
TcpTestSucceeded : True
# Steam query port is responding (which is why the browser shows the server).

# Step 3: Ping the host.
PS> ping 203.0.113.42
# Replies with normal latency.

# Step 4: Operator checks the server process.
# Process is running but appears stuck (not responding to admin commands).

Conclusion: The server process is in a stuck state. It is responding to Steam's query (which keeps it visible in the browser) but cannot accept new player connections. This is sometimes called a "zombie" state.

Resolution: Operator restarts the server process. The watchdog should have caught the unresponsive state but did not, suggesting the watchdog's health-check is only checking for process existence rather than responsiveness.

Walkthrough 2: Server has been down for 6 hours, operator unresponsive

Symptom: The server has been unreachable for 6 hours. The operator's Discord is quiet; no acknowledgment has been posted.

Diagnostic:

# Step 1: Ping the host.
PS> ping 203.0.113.42
# Request timed out.

# Step 2: Check the operator's other services (web site, etc.).
# Operator's website also unreachable.

# Step 3: Check third-party server-list site.
# Site shows the server has been offline for 6 hours.
# The site's monitoring also lost connection at the same moment.

Conclusion: The operator's entire infrastructure went offline simultaneously, most likely due to a data center or ISP outage at the operator's hosting location.

Resolution: Wait. The operator cannot resolve this until their hosting recovers. Most data center outages resolve within 4-8 hours; longer outages typically indicate a serious hardware or network failure that may take 24 hours or more.

Walkthrough 3: Restart loop

Symptom: The server comes online for 30-60 seconds, then goes offline, then comes online again. The cycle repeats indefinitely.

Diagnostic:

# Step 1: Observe the cycle.
PS> while ($true) { 
>>     Test-NetConnection -ComputerName 203.0.113.42 -Port 27015 -InformationLevel Quiet
>>     Start-Sleep -Seconds 10
>> }
# Output alternates True, True, True, False, False, True, True...
# Pattern: server is up for ~30 seconds, down for ~60 seconds, repeating.

# Step 2: Operator's watchdog logs show repeated process exits.
# Each exit is followed by automatic restart.
# Each new instance crashes within ~30 seconds.

Conclusion: The server is in a restart loop. The most common cause is corrupted save data or a configuration error that crashes the server consistently on startup. The watchdog dutifully restarts it into the same crash.

Resolution: Operator must disable the watchdog temporarily, identify the crash cause from server logs, and fix the underlying data or configuration before re-enabling. Common fixes: restore the save from backup, revert recent configuration changes, remove a broken mod from the load list.

Walkthrough 4: DDoS pattern

Symptom: The server is intermittently unreachable. Ping has very high packet loss when it responds at all. Player counts fluctuate wildly.

Diagnostic:

# Step 1: Ping the host with extended duration.
PS> ping -n 100 203.0.113.42
# 40% packet loss. Latency varies wildly (10ms to 800ms).

# Step 2: Other Unturned servers hosted by other operators are fine.
# Issue is specific to this server's network.

# Step 3: Operator reports their hosting provider notified them of an active attack.

Conclusion: DDoS attack against the server's host is saturating the network.

Resolution: Hosting provider engages DDoS mitigation. Mitigation typically engages within 5-15 minutes and reduces the impact significantly within 30 minutes. Fully clearing the attack can take hours depending on attack persistence. The operator has limited direct action; the mitigation is the hosting provider's responsibility.

Appendix E: Resolution time benchmarks by outage type

The table below documents typical resolution times by outage type, with the cohort survey's median, 90th percentile, and worst-case observed values.

Outage type	Median	90th percentile	Worst case
Server process crash (watchdog)	90 seconds	8 minutes	25 minutes
Server process crash (no watchdog)	2 hours	12 hours	72 hours
Restart loop (config fix)	15 minutes	90 minutes	8 hours
Out-of-memory restart	5 minutes	25 minutes	2 hours
Configuration error (revert)	12 minutes	90 minutes	6 hours
Hardware failure (cloud host)	3 hours	18 hours	48 hours
Hardware failure (self-host)	18 hours	72 hours	5 days
Host ISP outage	45 minutes	4 hours	18 hours
Data center outage	2 hours	8 hours	36 hours
DDoS attack	60 minutes	6 hours	24 hours
Steam matchmaking outage	30 minutes	3 hours	8 hours
EAC outage	45 minutes	4 hours	12 hours
Steam Workshop outage	25 minutes	2 hours	8 hours
Database back-end issue	30 minutes	3 hours	12 hours

The 90th-percentile and worst-case values are more representative of "how bad can it get?" than the medians. Players and operators planning around server reliability should consider the worst case for any specific outage type. Cohort data shows that approximately 1 in 50 outages reach the worst-case duration.

Appendix F: Operator preventive measure ROI

The table below documents the cohort's observed return on investment for each principal preventive measure. ROI is expressed as the percentage reduction in observed outage hours per month after the preventive measure was deployed.

Preventive measure	Setup time	Median monthly downtime reduction
Automated process watchdog	30 minutes	65 percent
Scheduled daily restart	5 minutes	25 percent
Off-host monitoring	1 hour	40 percent (faster detection)
Off-host log backup	30 minutes	0 percent (diagnostic value only)
Configuration backups before changes	5 minutes per change	80 percent of configuration-error outages
DDoS mitigation at host	Varies (hosting plan)	90 percent of DDoS-induced outage hours
Multiple admins with access	1 hour	50 percent (faster response)
Published status page	2 hours	0 percent (reduces report noise, not actual downtime)
Server-side resource limits	30 minutes	35 percent (prevents resource-exhaustion crashes)
Mod compatibility testing	2 hours per mod	60 percent of mod-induced outages

The cohort recommendation is to start with the highest-ROI items (watchdog, configuration backups, DDoS mitigation, off-host monitoring) and add the others over time. The cumulative effect of all preventive measures in the cohort survey is approximately 92 percent reduction in monthly outage hours compared to operators with none of the measures.

Next steps

If you have confirmed the server is up but you specifically experience timeouts when connecting, continue to Server Connection Timeout. If you are unable to connect for reasons other than timeouts, see Unable to Connect to the Server. Return to the section overview at Troubleshooting for a list of all articles in this section.