I Built My Own Error Tracker

Every production application crashes. I don’t mind runtime errors. I mind spending hours figuring out what broke. Plenty of tools can help. Most of them grew into heavy platforms I did not want to operate for a small product.

As a senior engineer I care about convenience, performance, security, and privacy. That pushed me to build my own error tracker.

The challenge

I can invent a long feature list for any new project. I wanted something useful shipped soon, and I refused another raw event firehose. I asked one question:

What do I actually need right now?

The answer was clear:

Catch production errors without digging through raw events. Group identical crashes into one issue. When different issues share a surface, treat that cluster as one incident I can triage.

Solution

I kept the SDK tiny: TypeScript, zero dependencies. The backend runs on Kotlin and Spring Boot. The dashboard uses SolidJS.

An issue is one fingerprint: the same crash type counted many times. Each event carries the stack, metadata, and URL (no sensitive fields). The system fingerprints the error, opens a new issue or finds an existing one, and attaches the event.

An incident is the next layer. When several different issues share a surface, RetraceKit opens one incident so I triage the outage once instead of a pile of tickets. Issues stay the building blocks. The incident is the unit of work.

I still needed a readable brief. AI summaries cover the issue or the incident: what happened, the likely impact, and a probable fix. You get the technical detail and a short explanation managers can follow.

Opening the dashboard just to check status still felt wrong. I added a generic integration module for Telegram and our internal messenger. New and regressed issues, and incident alerts, land with AI summaries in tools the team already uses.

Trade-offs

I had a tracker built around issues and incidents. I decided to share it publicly, then hit a hard limit.

Database boundaries

Storage is finite. I keep only recent events. If a crash goes quiet, the issue is fixed or gone. FIFO retention caps each project at 100,000 stored events over a rolling 7-day window on Free. That kept ingest open after spikes without an unbounded table.

Instead of a conclusion

RetraceKit is still evolving. Today it already solves the problem that made me build it. If you try it, tell me what helps, what gets in the way, and what you would change.

• Platform: retracekit.cloud
• How incidents work: docs
• RetraceKit vs Sentry for indie builders: blog
• Product Hunt: RetraceKit