Quick answer: Disconnect signals when a node leaves the tree, null out references you store to other nodes, and use queue_free plus weak references to avoid holding objects past their life.

Memory that climbs as you load and unload scenes usually means something is holding references that should have been released — often a signal connected across scenes. Here is how to find and break those links.

How to fix it

1. Disconnect signals on exit

If node A connected to node B's signal and A persists while B is recreated, the stale connection holds B. Disconnect in _exit_tree, or use one-shot connections, so freed nodes are not retained.

2. Drop stored cross-node references

A long-lived autoload or manager that stores references to scene nodes keeps them alive after the scene unloads. Clear those references on scene change.

3. Use queue_free and check with the monitor

queue_free removes a node safely at frame end. Watch the Monitor tab's object and node counts across scene loads — a steadily rising count points straight at what is not being freed.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Godot error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

A crash you can name from its stack trace is a crash you can usually fix in minutes.