Every production application eventually crashes. I don’t mind runtime errors. What I do mind is spending hours trying to understand what actually happened. There are many different tools, services, and SaaS platforms that can help with it. The problem is that many of them have become incredibly complex.
As a senior engineer, I care not only about convenience, but also about performance, security, and privacy. That motivated me to explore the idea of building my own error-tracking platform.
The challenge
Every engineer can imagine dozens of features for a new project. I
didn’t want to drown in an endless feature loop. I wanted to ship something useful as quickly as possible. And I didn’t want another endless stream of events. Then I asked myself one simple question:
What do I actually need right now?
The answer was easy:
I want to catch production errors without digging through a stream of raw events. There should be an entity that groups related events into a single issue.
Solution
I decided to keep the SDK tiny. It is written in TypeScript and has zero dependencies. The backend runs on Kotlin + Spring Boot, while the dashboard is built with SolidJS.
Everything revolves around issues. An issue is an entity built from related events. Each event contains information about the error and its environment: stack trace, metadata, URL, etc. (without collecting sensitive information). The system calculates the fingerprint of the error and either creates a new issue or finds an existing one, then attaches the event to it. That’s it.
The magic happens later. Once the system has collected the data, it needs to present it in a useful way. I solved this with AI summaries. The AI agent knows everything about the issue and generates a human-readable summary that helps not only developers but also managers understand the problem. The result is an issue page with all the technical details and a concise summary that helps explain what happened and what impact it may have on the product.
After implementing this, I discovered another problem: having to open the dashboard just to check the project status. The solution was simple, I created a generic integration module for Telegram and our internal company messenger. Now it pushes new and regressed issues, along with AI summaries, directly to the tools the team already uses, so you know about problems instantly.
Trade-offs
At this point, the project had become an issue-centric tracking platform. I decided to share it publicly, but soon faced one serious problem. Let’s deep dive.
Database boundaries
Unfortunately, a database doesn’t have infinite storage. I had to decide how to keep the event stream clean and fresh. The idea was simple: keep only recent events. If an event hasn’t appeared for a while, the issue has probably been fixed or no longer occurs. I chose a simple FIFO retention strategy: no more than 100,000 events per project over a rolling 7-day window. It solved the problem.
Instead of a conclusion. RetraceKit is still evolving. There are many things I want to improve, but today it already solves the problem that made me build it in the first place. If you decide to give it a try, I’d genuinely love to hear your feedback: what feels useful, what doesn’t, and what you’d improve.
Platform: https://retracekit.cloud
Support on ProductHunt: https://www.producthunt.com/products/retracekit-error-tracking-platform