Show HN: I built a self-hosted error tracker in Rails

10 days ago (telebugs.com)

This project is inspired by 37signals’ ONCE idea. I replicated the whole process and have already sold a few copies (the testimonials are real).

I think this is a great idea with the wrong pricing model. Look at all the one off payment products that involve code, they're all dead. Just charge a lower but recurring price so I can be sure that you make enough money that you keep working on it. $20/month flat price to keep the license working and source available if you shut down. If people like it and want the barebones Sentry then charge them $40 a month to provide code and host it. Wishing you the best of luck.

  • > Look at all the one off payment products that involve code, they're all dead.

    Could you share some examples? I can’t think of any off the top of my head.

    --

    I really went all-in with the ONCE philosophy because it resonated with me deeply. It felt more like a passion project than cold business strategy.

    • I think all of the boilerplate projects you can find.

      Are ONCE projects getting updates? We will find a year or two?

      Your model is a subscription, we just don’t get to know when you decide to have a new major version and plan pricing / spend as a result.

      5 replies →

    • The problem with ONCE is that software is never finished. This is why most ONCE software that is still available today is charging a one off licensing fee + update fee (e.g. charge yearly for major updates or 10% of the one off fee per year). This is sustainable, but your model isn't. You will notice down the road in 2-4 years that it's no fun to work for free for users that expect an update because it requires patching or there are breaking changes.

      1 reply →

  • He is selling updates. You pay once for 1.x. That's a fine and okay business model that has been functioning for very long.

    • https://www.reaper.fm/ uses that pricing and has... let's say fanatical following. You pay once for version X and X+1 just in case you miss out on an update coming in a month. Then you pay again for a big upgrade.

I know you said inspired, but it still feels a bit wrong to just copy paste the exact same landing page style and replace some words on it (https://once.com/campfire)

  • Yeah, I used it as a starting template. But beyond the layout, the copy and product are completely different. It just helped me get started faster, and I’ve always been open about that. Everything else (including the installer) is fully self-made.

> Wherever you can host something like WordPress, you can host Campfire

I’m going to be pedantic here, but this statement is not true. I host a website on a provider that allows WordPress (PHP) along with MySQL, but

> System requirements & installation

> Campfire is packed as a Docker container image

the web host provider does not allow Docker (it runs on BSD).

I’d suggest improving the system requirements section by actually stating the system requirements. To me the mention of Docker without other details is a black box that I cannot have any intuition for.

  • I appreciate the feedback. I’ve updated the information to remove the WordPress reference and clarified that the OS must support containerization. Thanks!

Their docs show throughput limits (e.g., 4 CPU = 60 errors/sec), but what happens during error spikes?

If my app crashes and blasts hundreds of errors in seconds, does Telebugs have built-in rate limiting or backpressure? Or do I need to overprovision hardware/implement throttling myself?

With SaaS tools, spike protection is their problem. With self-hosted, I’m worried about overwhelming my own infrastructure without adding complexity.

Anyone running this in production?

  • Hey, Telebugs creator here. Great questions! Right now, Telebugs doesn’t have built-in throttling, so during error spikes, you’d either need to handle it manually or overprovision. I do plan to add throttling in the future, similar to what Sentry does, to protect your infrastructure automatically.

    Curious: for those running self-hosted error trackers in production, how do you currently handle sudden error spikes? Any clever tricks or patterns you swear by?

  • The company I work for runs self hosted sentry. Sentry has something that tells you that events are being dropped due to pressure. I think every engineer in the company knows that this is happening but no one fixes it because no one has the time to look into it.

    • Thanks for your answer! Would you mind sharing your error volume? I’m also curious, how often do dropped events happen, and how does it impact your workflow? Any workarounds you’ve tried, or features you wish were available? This will help me make sure the feature is implemented in a way that’s actually useful.

Interesting pricing model, and it seems the pain of Sentry is getting real those days. Many folks need something simpler, that just works. Totally support the idea. The alternative starting with a G has been mentioned a few times already, so I'll also mention that's been operating in the space and that I happily use : https://www.bugsink.com/. It's trying to solve the exact same pain.

Disclaimer : I know the owner :), so I may be biased. But generally I like to see more niche alternatives to the massive players in the field

  • And I am the owner... in "the spirit of Hacker News" let me hijack this thread to answer some of the questions about Telebugs as they apply to Bugsink.

    High throughput: Bugsink has at least 2 layers of spike-protection: ingestion (storing) and digestion (dealing with) events are separated out; also: you can set rate limits. Ingestion-wise it can deal

    The pricing model has been mentioned a few times already: I wonder how that will work out for them. In any case, Bugsink is free to use if you host it yourself and cheaper than Sentry if you go hosted/SaaS.

    It's interesting to say that the "drop in replacement for Sentry" is a model that is gaining popularity.

Nice. I’m curious about what kind of customers are buying your product and where did you find them. It’s difficult to compete with someone like Sentry, and even though you have a better pay model, you don’t have the reputation, so I am rather curious about your customers and why they prefer your product. Are they indie devs looking for a cheaper solution?

  • Thanks! I’m not really competing with Sentry itself. I’m competing with self-hosted Sentry, which is notoriously hard to install and maintain (and has steeper hardware requirements).

    I'd say my customers prefer my product because:

    - They want self-hosting without the maintenance burden.

    - They work in regulated or internal networks.

    - They’re tired of subscription pricing.

    - I build it in public and post regular updates on my social media.

    - They value direct support from the creator.

    P.S. I’ve personally worked for a Sentry competitor, so I know the pain points firsthand.

As much as I like the ONCE idea, even 37signals have found it hard to be sustainable. I think they intend to have an improved version of ONCE idea coming out later.

Other than that I hope this project succeed. May be another idea is that you offer paid hosted model as well as the ONCE product. This is similar to a lot of OSS web analytics. People are happy to pay for subscription / services as long as they know they are not locked in. i.e They are happy to pay for $20 - even $2K per month due to Opex rather than Capex reason or saving the manual labour hassle. And they have the choice to move their data to ONCE product when they see fit.

All the best I hope this work out.

  • I follow 37signals updates on ONCE, but I don’t recall them mentioning sustainability issues. Could you share a link?

    Thanks for the suggestion! A hosted solution could definitely be an option. That said, some people have mentioned that having an indie dev behind it can be a turn-off. I’ll keep exploring ideas that make sense, though.

    • I want to vaguely recall that they had like 4 products in planning stages for ONCE, released Campfire, then released Writebook for free, and then made Campfire free.

      Lately on the podcast I only hear about Fizzy and one other unannounced SAAS that they're putting dev energy behind, nothing about other ONCE products.

      I suspect that without a critical mass of usage driving word of mouth the long tail of sales was basically nil, and long-term even fairly small products weren't looking to recoup dev costs any time soon.

      1 reply →

How does it compare to GlitchTip which is in the same space?

  • Telebugs creator here. GlitchTip is solid, but Telebugs is built for devs who want something lighter and faster to self-host.

    It runs on plain Rails, sets up in about 5 minutes (one command), and stays snappy even on small servers. The UI is modern, minimal, and actively maintained. I keep refining it to stay fast and clean.

    The biggest difference is in philosophy. GlitchTip was built by an agency. Telebugs is a solo passion project. I’ve worked on error tracking tools professionally before, and built Telebugs to reflect how I wish those tools worked.

    If you’re curious, here’s a short write-up on why I built it: https://telebugs.com/why

    Happy to answer any specific questions!

Is there a license for FOSS projects?

  • Not at the moment, but I’m open to it! If you have something in mind, feel free to email me at kyrylo@telebugs.com and we can work something out.

Does Telebugs support SQLite3 query performance tracking? E.G. top slowest queries, etc. I don't believe Sentry supports this

  • Nope, there are no APM features in Telebugs: https://telebugs.com/#okay-but-sentry-offers-apm

    Fun fact: Telebugs itself runs on SQLite3!

    • Would love to see it added. I’m running a Flask app using raw SQLite3 without a ORM. I believe I could hack up a Span solution in Sentry to query track like:

          import sqlite3
          from sentry_sdk import start_span
      
          def execute_query(conn:   sqlite3.Connection, sql: str, params: tuple = ()):
              with start_span(op="db", description=sql) as span:
                  span.set_data("db.system", "sqlite")
                  cursor = conn.execute(sql, params)
                  return cursor

      1 reply →

It looks like it was built on macOS and not Omarchy, is that even allowed these days? /s

  • Haha, true. I used to rock Arch Linux back in 2012–2015, so no need for Omarchy for me