Reading logs and debugging an S&Box server

Where S&Box logs live, how to read them, how to identify a crash cause (.NET stack trace, Source 2 assert, package mismatch), and how to enable verbose mode when things go sideways.

Introduction

S&Box logs heavily, and that's a good thing. The .NET runtime emits clean stack traces, Source 2 outputs identifiable asserts, and the package system clearly reports download issues. Still, you have to know where to look.

Prerequisites

• An S&Box server (crashing or misbehaving)
• Access to the Wisp panel (Console + Files)

Step 1: The real-time console

Your first tool. Wisp panel → Console, you see everything the server logs live:

• Steam Update boot / package downloads
• .NET runtime errors
• Source 2 asserts
• Print from gamemode code

💡 Keep a Console tab open all the time when testing a change.

Step 2: Persistent log files

Logs are also written to disk. Go to Files and look for the logs/ folder at the container root.

Typical files:

logs/
├── server.log           # current main log
├── server.log.1         # previous day rotation
├── crash-2026-05-17.log # crash dumps if applicable

You can download for offline analysis. For live tail, Console is enough.

Step 3: Read a .NET stack trace

When the gamemode crashes, you'll see something like:

System.NullReferenceException: Object reference not set to an instance of an object
  at MyGamemode.PlayerComponent.OnUpdate() in /path/PlayerComponent.cs:line 42
  at Sandbox.GameObject.Update()
  ...

Read top to bottom:

1. Exception type: NullReferenceException, IndexOutOfRangeException, InvalidOperationException, etc.
2. Message: provides context
3. Stack trace: the first line (PlayerComponent.cs:line 42) is generally your code — look here first

Step 4: Identify common errors

Failed to resolve package → Wrong ident in +game. Strict org.name lowercase format.

SteamCMD failed: app 1892930 not found → Steam mismatch or temporary unavailability. Force a Reinstall or wait 5 min.

Cannot bind port 27015: address already in use → Another service occupies the port, or a previous S&Box server didn't release it after a crash. Full instance restart.

Roslyn compilation failed → C# compilation error in your local gamemode (.sbproj). The message specifies file and line.

Assertion failed: ... at engine/... → Source 2 bug (rare). Note the full message and report to Facepunch via their tracker, or open a VeryCloud ticket with the log.

Step 5: Enable verbose

Depending on what you want to debug, several levers:

Gamemode logging (C#)

In your code, multiply Log.Info("..."), Log.Warning("..."), Log.Error("..."). These appear in console and log files.

Network trace (if gamemode supports it)

Some gamemodes expose debug ConVars. Check their docs. S&Box base doesn't provide a standard server-side net_graph.

Step 6: Analyze a crash dump

If the server fully crashes (process killed):

1. Go to Files → logs/
2. Look for a crash-*.log or coredump-* file
3. Download and open in an editor

If you have the gamemode source, load the corresponding .pdb in a .NET debugger (dotPeek, ILSpy) to resolve addresses.

Step 7: Keep clean history

On a public server, logs grow quickly. Some practices:

• Logrotate from the gamemode: limit size (Wisp doesn't auto-prune)
• Wisp Schedule to download + delete logs > 30 days
• Don't export full SteamIDs in your public logs (GDPR)

Step 8: Logs to Discord (alerting)

To get notified without watching the console all day, many gamemodes integrate a Discord webhook. If yours doesn't, you can code it in C#:

using System.Net.Http;

static async void NotifyDiscord(string message)
{
    using var http = new HttpClient();
    await http.PostAsJsonAsync(
        "https://discord.com/api/webhooks/...",
        new { content = message }
    );
}

Hook into Log.OnMessage to relay critical errors.

Troubleshooting

Console shows nothing

• Server didn't start (check START button)
• Wisp-side buffer full — refresh page
• Gamemode logs to stderr? Also check Log Viewer if available

Truncated stack trace

• Gamemode uses Exception.Message instead of Exception.ToString(): not much to do server-side
• Grab build .pdb if you have code access

Crash dump is binary

• Normal for a Linux coredump. Use gdb or a .NET crash analysis tool
• If too painful, open a VeryCloud support ticket with the file

Useful commands

# View latest log
# -> Files / logs / server.log (right-click Edit)

# Download a log for offline analysis
# -> Files / logs / [file] / right-click Download

# Live tail = panel Console tab

Conclusion

S&Box logs clearly, as long as you look in the right place: Console for live, Files → logs/ for history. Very readable .NET stack traces, cryptic but identifiable Source 2 asserts, chatty packages. Once familiar, you spot a crash cause in 30 seconds instead of restarting 10 times.

Going further: Discord webhooks for critical errors, .NET APM integration, auto-dump via cron when memory exceeds a threshold.

Resources

• .NET Exception Handling Best Practices
• S&Box Docs — Debugging
• Source 2 — Valve Developer Wiki
• JetBrains dotPeek