How to Add Crash Reporting to a Unity or Godot Game in Under 10 Minutes

This guide covers add crash reporting Unity Godot 10 minutes in detail. Your game crashes on a player’s machine. You get a one-star review that says "keeps crashing." No stack trace. No device info. No way to reproduce it. This is the default experience for indie developers who ship without crash reporting. The good news: adding it takes less time than reading a long tutorial. This guide walks through both Unity and Godot, start to finish.

Why You Need Crash Reporting Before Launch

Players do not file bug reports. Studies consistently show that fewer than 1 in 100 players who encounter a crash will take any action beyond closing the game. Many will refund or uninstall without a word. A crash reporting SDK changes the equation entirely: every crash is captured automatically, with the full stack trace, device specs, OS version, and game state attached. You go from "someone said it crashes" to "here is the exact line of code that failed on 47 different NVIDIA GTX 1650 machines running Windows 11."

The integration takes minutes, not days. Here is how to do it for both major indie-friendly engines.

Unity: Step-by-Step

Step 1: Install the SDK.

Open the Unity Package Manager (Window > Package Manager), click the + button, and select "Add package from git URL." Enter the Bugnet Unity SDK URL. Alternatively, download the .unitypackage file from the Bugnet dashboard and import it via Assets > Import Package > Custom Package.

Step 2: Add BugnetManager to your first scene.

Create an empty GameObject in your boot or splash scene, name it BugnetManager, and add the BugnetManager component. Enter your project key from the Bugnet dashboard. Enable "Don’t Destroy On Load" so it persists across scene changes.

using UnityEngine;
using Bugnet;

public class CrashReportingSetup : MonoBehaviour
{
    [SerializeField] private string projectKey = "your-project-key";

    void Awake()
    {
        BugnetSDK.Init(projectKey);
        DontDestroyOnLoad(gameObject);

        // Optional: attach player context
        BugnetSDK.SetUser(PlayerPrefs.GetString("player_id", "anonymous"));
        BugnetSDK.SetContext("build", Application.version);
    }
}

That is the entire integration. The SDK automatically hooks into Application.logMessageReceived and AppDomain.CurrentDomain.UnhandledException to capture both logged errors and unhandled exceptions.

Step 3: Add custom context (optional but valuable).

The more context you attach, the faster you can diagnose crashes. Add the current scene, player level, and any relevant game state:

using UnityEngine;
using UnityEngine.SceneManagement;
using Bugnet;

public class BugnetContext : MonoBehaviour
{
    void OnEnable()
    {
        SceneManager.sceneLoaded += OnSceneLoaded;
    }

    void OnSceneLoaded(Scene scene, LoadSceneMode mode)
    {
        BugnetSDK.SetContext("scene", scene.name);
    }

    public void OnLevelComplete(int level)
    {
        BugnetSDK.SetContext("level", level.ToString());
    }
}

Step 4: Test it.

Add a temporary test crash to verify everything works:

void Update()
{
    if (Input.GetKeyDown(KeyCode.F12))
    {
        throw new System.Exception("Test crash from Bugnet integration");
    }
}

Press F12 in Play mode, then check your Bugnet dashboard. The crash report should appear within seconds, complete with the stack trace pointing to this exact line, your Unity version, OS, GPU, and any custom context you attached.

Godot: Step-by-Step

Step 1: Install the addon.

Download the Bugnet Godot addon from the dashboard or the Godot Asset Library. Extract it into your project’s addons/bugnet/ folder. Go to Project > Project Settings > Plugins and enable "Bugnet."

Step 2: Add the autoload.

Go to Project > Project Settings > Autoload and add addons/bugnet/bugnet_manager.gd with the name Bugnet. This ensures the crash reporter initializes before any scene loads and persists throughout the game.

# addons/bugnet/bugnet_config.gd — edit with your project key
extends Node

const PROJECT_KEY := "your-project-key"

func _ready() -> void:
    Bugnet.init(PROJECT_KEY)

    # Optional: attach player context
    var player_id := load_player_id()
    Bugnet.set_user(player_id)
    Bugnet.set_context("engine", "Godot %s" % Engine.get_version_info().string)

func load_player_id() -> String:
    var config := ConfigFile.new()
    if config.load("user://player.cfg") == OK:
        return config.get_value("player", "id", "anonymous")
    return "anonymous"

Step 3: Add scene-level context.

# Add to your scene transition manager
func change_scene(scene_path: String) -> void:
    Bugnet.set_context("scene", scene_path.get_file().get_basename())
    get_tree().change_scene_to_file(scene_path)

func on_level_complete(level: int) -> void:
    Bugnet.set_context("level", str(level))

Step 4: Test it.

func _input(event: InputEvent) -> void:
    if event.is_action_pressed("ui_end"):
        # Deliberate test crash
        var x: Node = null
        x.get_name()  # Will crash with null reference

Run the project, press End, and check the Bugnet dashboard. You should see the crash report with the GDScript stack trace, the null reference error, Godot version, and OS info.

What Gets Captured Automatically

Without writing any additional code, the SDK captures:

Stack trace — the full call chain at the moment of the crash, with file names and line numbers. Device info — CPU model, GPU model and driver version, total and available RAM. OS — operating system name and version. Game version — the build number or version string you set during initialization. Screenshot — a screenshot of the game at the exact frame of the crash. Log tail — the last 50 log messages before the crash, which often contain the breadcrumb trail leading to the failure.

What to Leave Out: Privacy Considerations

Crash reporting should never capture personally identifiable information unless you have explicit consent. By default, the Bugnet SDK does not capture IP addresses, chat messages, or any text input fields. If your game has a login system, use an opaque player ID rather than an email address. If you operate in the EU, make sure your privacy policy mentions crash reporting and that your cookie consent flow covers the SDK initialization.

"The best crash report is the one that arrives before the player even thinks about writing a Steam review. By the time they alt-tab to complain, you should already have the stack trace."

Verifying in the Dashboard

After triggering your test crash, open the Bugnet dashboard. You should see a new entry in the bug list with the crash type, the first line of the stack trace as the title, and all the device context attached. Click into it to see the full stack trace, the screenshot, and the log tail. If the entry does not appear within 30 seconds, check your project key and ensure your game has network access.

Once verified, remove the test crash code and ship with confidence. Every real crash your players encounter will now appear in the dashboard automatically, grouped by stack trace, sortable by occurrence count, and actionable from the moment it arrives.

Related Issues

For a deeper understanding of what stack traces tell you and how to read them, see our beginner’s guide to reading game stack traces. If you want to go beyond crash reporting and build a full post-launch QA workflow, our guide on building a post-launch QA pipeline covers triage, reproduction, and hotfix deployment. For understanding how crash reports get deduplicated, see stack trace grouping.

Ship the SDK before launch day. Your future self will thank you when the first crash report arrives with a full stack trace instead of a one-star review.