Luau Memory Leaks Are Killing Your Session Length
The bug that hits your best players hardest
Your most loyal players — the ones who've been in your game for 45 minutes, the ones the Roblox algorithm is actively watching to decide whether to recommend you — are the ones experiencing the worst performance. Not because they have bad hardware. Because your game is leaking memory linearly with time, and by minute 40 it's a different game than it was at minute 5. I've watched this pattern silently kill session length in more games than I can count, including one of my own that I spent two years trying to diagnose for other reasons entirely. The culprit, almost every time, is unconnected :Connect() calls that nobody ever cleaned up.
What's actually happening in memory
Luau's garbage collector cannot free an object if something still holds a reference to it. When you write RunService.Heartbeat:Connect(someFunction) and never store the returned RBXScriptConnection, you haven't lost it — it's still live. The event fires every frame. If the object that function closes over gets "destroyed" in your game logic but that connection still exists, the object can't be collected. Multiply this by UI components being rebuilt on respawn, by shop menus opening and closing, by ability systems that reconnect on every equip, and you get memory that climbs something like 2–5 MB per minute in a moderately complex game. That doesn't sound catastrophic until you realize a 45-minute session on a mid-range device has now consumed an extra 90–225 MB that was never released.
This isn't a theoretical concern. The Roblox DevForum has documented this class of problem repeatedly, and Roblox's own documentation explicitly notes that connections must be disconnected when they're no longer needed. Most developers read that sentence and nod. Almost nobody operationalizes it.
The three patterns that cause 90% of leaks
Let me be direct about this: the leak isn't usually in your core game loop. It's in three specific patterns that feel harmless when you write them.
- Reconnecting without disconnecting. Any system that calls
:Connect()inside a function that runs more than once — an ability equip handler, a UI refresh, a character respawn routine — is stacking connections. Each call returns a new connection. The old one doesn't go away. By the tenth respawn, you have ten Heartbeat listeners for a system that only needs one. - Connecting to events on objects that get destroyed. When you destroy a Part or a GUI, its events are cleaned up — but if you connected to a service event (Heartbeat, RenderStepped, a RemoteEvent) inside code that managed that object, that service connection persists. The object is gone. The callback referencing it is not. The GC can't collect either cleanly.
- Module-level connections in shared modules. A ModuleScript that connects to a service event at the top level will fire that connection for every require. In client-heavy architectures where modules get re-evaluated in different contexts, this compounds fast.
The fix for all three is the same pattern: store every connection, disconnect it explicitly when its owner is done. This is what the Maid or Janitor patterns exist to enforce — a cleanup object that collects connections and destroys them together when a component lifecycle ends.
Why this hits session length specifically
Session length is the metric Roblox weights heavily in its recommendation engine. A game with strong Day 1 retention and long average sessions gets surfaced. A game where average session length quietly drops as your playerbase ages — because the players who stay longest are the ones accumulating the most memory pressure — looks like a game people are leaving. Because they are. They're leaving because frame times have crept from 16ms to 40ms and the game feels sluggish in a way they can't articulate.
I've seen games in the 10k–50k concurrent range where the developer was convinced their retention problem was content — not enough updates, not enough to do. When we instrumented the client and looked at frame time by session age, the picture was different. Frame time at minute 5: fine. Frame time at minute 30: degraded by 30–40% for a meaningful portion of the playerbase. Those players weren't bored. They were playing on a progressively slower game.
This is the part that cargo-culting simulator mechanics or copying a popular game's UI won't fix. You can have the most polished game loop on the platform and lose players at minute 25 because a leak introduced in a patch six months ago never got caught.
How to find your leaks right now
Roblox's built-in MicroProfiler (Ctrl+F6 in-client) will show you frame time trends, but it won't directly surface memory growth. For that, use collectgarbage("count") — Luau exposes this — and log it to output or a DataStore at 5-minute intervals during a play session. If the number climbs monotonically without plateaus, you have a leak. A healthy session should see memory level off as the GC catches up. A leaking session shows a line with a positive slope that doesn't flatten.
Once you've confirmed the leak exists, the investigation is about finding which connections aren't being stored. Search your codebase for :Connect( and audit every call site: is the return value stored? Is there a corresponding :Disconnect() or Maid cleanup that fires when the owner dies? If you're using a framework like Knit or Fusion, check whether the framework's lifecycle hooks are actually being called — a component that never gets destroyed never cleans up.
Fix the leaks, then measure session length over the next two weeks. Use RoWatcher to track whether average session time actually moves after your changes — Roblox's native analytics can lag and the bucketing makes short-term changes hard to see. If the fix is real, you'll see it in the curve within 10–14 days of the patch going live. That's the feedback loop you want: instrument, fix, verify. Not guess, ship, hope.