← Dev Log
Crash reports without the cloud: GlitchTip
When the game crashes on a player's machine, we want it to tell us what happened — automatically, with enough detail to fix it.
In plain words
When the game crashes on a player's machine, we want it to tell us what happened — automatically, with enough detail to fix it. The popular service for this is Sentry, but self-hosting the full product needs a beefier server than our one shared PC. So we run GlitchTip, a lighter lookalike that speaks the same language. The game phones home to our machine, and the first test crash report arrived within the hour.
Under the hood
- Why not full self-hosted Sentry: it wants ~16 GB and can't share the 10 GB WSL box with GitLab. GlitchTip is the design-sanctioned MIT swap — same SDK wire protocol, so the vendored sentry-godot addon doesn't care. Known limit, accepted and recorded: no native minidump symbolication; event-level reports only.
- Pinned like everything else: compose stack (GlitchTip 6.2.0,
postgres 18, valkey 9 by digest);
SECRET_KEYgenerated to an uncommitted env file; org/project bootstrapped via the Django shell. - DSN never touches the repo: it lives as a CI variable and is injected
into
project.godotat export time. Fun trap: you must guard on the key, because the addon writes its own[sentry]section header during editor runs, so naive "append the section" logic would duplicate it. - End-to-end proof:
capture_messagefrom the built editor landed as issue #1 in GlitchTip.
Foreshadowing: having a crash reporter wired in means the crash reporter itself can be the thing that crashes. That story is two posts away.