When your error tracking starts throwing its own errors, you have a problem. We recently encountered a series of stability issues with our GlitchTip deployment that pointed toward memory allocation and container drift.
For those unfamiliar, GlitchTip is an open-source alternative to Sentry. While it’s powerful, managing the worker processes–where the heavy lifting of event processing happens–can lead to resource contention if your configuration isn’t locked down.
The Drift Problem: Image Mismatches
Before diving into memory limits, you have to ensure your environment is actually running what you think it is. We caught a recurring issue in our system where the glitchtip-worker was experiencing “compose drift.”
Our audit logs showed a persistent mismatch between our YAML configuration and the live container. Specifically, our configuration called for glitchtip/glitchtip:v6.1.6, but the live environment was running glitchtip/glitchtip:latest.
Using :latest is a gamble in production. It introduces non-deterministic behavior where a background pull can update your image to a version with different memory profiles or breaking changes without you changing a single line of code. When we saw this drift across multiple probes, it became clear that our worker wasn’t aligned with our tested baseline.
Tuning the Worker for Memory Stability
Memory allocation errors in GlitchTip typically stem from the worker processes consuming more RAM than the container limit allows, leading to OOM (Out of Memory) kills.
To resolve this, you need to focus on two areas: explicit versioning and resource constraints. First, pin your images to a specific version–like v6.1.6–to ensure consistency across all nodes. Second, define hard memory limits in your Compose file.
If you are seeing spikes during heavy event bursts, it’s often a sign that the worker is trying to process too many events in parallel for the available heap space. Reducing the number of concurrent workers or increasing the allocated memory ceiling is the primary fix here.
This mirrors a broader challenge we’ve seen when dealing with agentic workflows and large-scale data recall. Just as we discussed in our piece on Breaking the Memory Wall, managing how a system recalls and processes information is often less about raw capacity and more about how that memory is structured and constrained.
Hardware Considerations for Self-Hosters
If you’re running GlitchTip on your own hardware, the underlying memory architecture matters. While we usually focus on software config, the physical throughput of your RAM can impact how quickly workers clear their queues.
We’ve explored this in depth regarding, and the lesson applies here: stability is better than peak theoretical speed. For a monitoring tool like GlitchTip, consistent latency and reliable allocation are more valuable than overclocked memory that might introduce instability into your error logs.
Final Checklist for Stability
To stop the cycle of memory errors and container drift:
- Pin Your Versions: Replace
:latestwith a specific tag (e.g.,v6.1.6) in your Docker Compose file to prevent unexpected updates. - Audit for Drift: Regularly check that your live containers match your YAML definitions to avoid “ghost” bugs caused by image mismatches.
- Set Resource Limits: Define
mem_limitandmem_reservationin your worker configuration to prevent a single runaway process from crashing your entire host.
By locking down the versioning and aligning your resource limits with actual usage, you can turn GlitchTip from a source of instability into a reliable window into your application’s health.
