Why I Built Telebugs | Self-Hosted Error Tracking Story

I built the first Telebugs on my birthday in 2024.

I registered the domain that night and could not sleep. The idea felt obvious: error tracking inside Telegram.

I had used Telegram for years. I had also spent years around error tracking: first as an intern at Bugsnag, then through most of my career at Airbrake. Telegram had channels, topics, notifications, teams, and discussion. Error trackers had projects, groups, alerts, teams, and comments. The mapping looked almost too good.

It was too good.

I tried to avoid building a web dashboard. That meant a CLI. The CLI had to create channels, invite people, set up project tokens, talk to Telegram APIs, talk to a bot, and somehow make setup feel normal. It did not feel normal.

So I did what developers do when a simple idea becomes hard: I made it bigger.

I built a SaaS version. Rails dashboard. Telegram login. Bot. API. SDKs. PostgreSQL. ClickHouse. NATS. All the serious-looking machinery.

Then I launched it. People were polite. The product did not work.

The painful part was not that it failed. The painful part was realizing I had built away from the thing I liked in the first place. I wanted simple software for developers who know exactly what they need. Instead I had another SaaS with accounts, plans, billing, and a quiet little voice saying: please trust me with your production errors.

Then ONCE happened

When 37signals launched ONCE, it hit a nerve. Pay once. Run it yourself. Keep the thing. No usage meter breathing down your neck.

I could not switch immediately. I was still stuck in my SaaS mess. But the idea stayed in my head. Eventually it became too annoying to ignore.

The version I wanted

So I stripped Telebugs down to the shape it should have had all along: self-hosted error tracking, compatible with the Sentry SDK, installed on your server, paid once, source code included.

No Telebugs event quotas. No hosted usage bill because one customer found a weird loop. No giant data pipeline to operate. No third-party server holding your stack traces and environment data.

The job is boring on purpose: collect errors, group them, show the context, notify you, help you fix the bug, and get out of the way.

That is the Telebugs I wanted to buy. So I built it.

For the maintained, non-narrative version of the product scope, licensing, compatibility, requirements, and limitations, see Telebugs product facts.