Troubleshooting

Palworld’s dedicated server writes no log file of its own, only stdout/stderr, so PalCommand’s supervisor captures that output for you. The Console tab on each server’s page is that capture, live.

“Restart did nothing”

You’ll see a toast: “Server wasn’t running, so there was nothing to restart.” Restart only makes sense on a running server. If it had already stopped (or an explicit Stop you triggered separately won a race against the restart), PalCommand reports the honest no-op instead of pretending something happened.

“Update dispatched for fewer servers than were pending”

Update all skips servers that are busy or already crash-looping rather than forcing them. The success toast is worded off how many actually got dispatched: “Update dispatched for 3 of 5 servers” means two were skipped, not that two failed. Dispatch the skipped ones individually once they’re free.

Crash card actions did nothing useful

View crash log opens the log folder in File Explorer. On Windows, that folder is frequently empty. Palworld’s server doesn’t always leave a diagnostic trail behind a crash. An empty folder after clicking View crash log is expected, not a sign PalCommand failed to do anything; the Console tab’s history up to the crash is usually the more useful source.

Disable auto-restart stops PalCommand from relaunching a crash-looping server on its own. Once it’s off, the card shows “Auto-restart disabled” in place of the button. There’s no in-app switch to turn it back on yet, so treat this as a deliberate one-way action for a server you’re about to sit down and diagnose.

The Network tab’s connection check says it’s fine, but players still can’t connect

Run check on the Network tab checks this machine only. It cannot confirm reachability from the internet. A green result means something is listening on the right ports, the firewall rule exists, and (if you mapped it) the UPnP lease is current. It does not mean the outside world can reach your router. If players still can’t connect, check your router’s port forwarding or UPnP support next. That’s outside what PalCommand can see from here.

Starting a server fails immediately, naming a port already in use

Before it launches anything, PalCommand checks the server’s game, query, and REST ports itself. If another process already holds one, the start refuses right away and says which port and which role, for example “port 8211 (game, UDP) is already in use”. Free that port, or give the server different ports on its Settings tab, then start it again. Before this check existed, a taken port only surfaced after the full 180-second boot timeout ran out, with nothing pointing at the cause.

PalCommand used to start slowly, or not close right away, with a lot of metrics history

A large metrics.db used to slow PalCommand’s own startup: old samples were pruned inline before the window could open, and because that pruning ran before Windows message handling started, a close request during that window went unanswered too. Pruning now runs on its own thread instead, so startup and closing both stay responsive no matter how much metrics history has built up. A failed prune is logged and skipped rather than blocking the app; see “Metrics retention (days)” on App settings to control how much history accumulates in the first place.

Where are the logs?

PalCommand keeps its own diagnostic log at logs/palcommand.log inside its data folder (find that folder’s path on the App settings page’s “Data folder” row), separate from any server’s crash log above. Only the current run and the one before it are kept: each launch renames the previous log to palcommand.log.old before starting a fresh one. If PalCommand itself ever shows a “ran into a problem” recovery screen instead of the normal window, that screen shows the same data folder path so you can attach the log when contacting support.

“Agent offline” in the sidebar footer

This means the basic request PalCommand makes to list your servers failed, not that any one server crashed. It usually clears on its own; if it doesn’t, restarting PalCommand is the next step.

Account sign-in returns to the browser but the app stays signed out

Keep PalCommand open while completing the browser flow. The loopback callback expires after ten minutes and can be used only once. Retry from Account; do not copy a callback URL between machines. If the app reports secure storage unavailable, follow the Credential Manager steps in Account, Trial & Subscription.

PalCommand is in Safety Mode

Safety Mode preserves observation, save, graceful stop, verified backup, export/deletion, billing, and read-only MCP. It deliberately blocks mutations without stopping a running server. Reconnect, open Account, and refresh the signed entitlement. A trial has no offline grace; an established paid subscription can work offline only through the signed grace date shown by the app.

The MCP bridge says unavailable or authentication failed

The bridge requires the same Windows user’s already-running PalCommand desktop, MCP enabled, and a valid pairing credential in Windows Credential Manager. It never starts the app or accepts a token from a file or environment variable. Disable and re-enable MCP to rotate pairing, then update the host configuration to the installed palcommand-mcp.exe path if needed.