Posted by roywashere 4/18/2025
I respect the fact that the Sentry people are honest about their teetering tower.
For example, Firefox tries to connect
---
IMHO, the RUM tooling[1] is the worst offender, tracking mouse movement and keystrokes. At least Sentry is usually just trying to report JS kabooms
1: https://docs.datadoghq.com/real_user_monitoring/session_repl... and https://docs.newrelic.com/docs/browser/browser-monitoring/br... et al
I don't have servers like this but the author makes it easy to understand, and it applies to a lot of other things.
The Comparative Costs picture does tell it all.
The purpose of so much software is to reduce human and machine costs through time, and this apparently turned out to do just the opposite, apparently after long-term testing under real-world conditions.
Could be an unsurmountable fundamental structure of technical debt or something like that which metastasizes.
Then this, anyone could say about anything:
>I’m not going to run a piece of software that requires 16GB of RAM, has a complex installation script, and is known to be a pain to maintain. I’m not going to recommend it to anyone else either.
Easier said than done, sometimes it's the only option.
It's a "script". Maybe that's why you have to "rehearse" it more than once before you barely get it right, and then you might have to really go the extra mile (and have a bit of good fortune) before you can achieve a "command performance".
How do you think it feels these days to have to settle for this kind of thing in expensive proprietary software too?
maybe they should put in a system to monitor the docker containers.
I've been self-hosting Sentry for over 10 years: Sentry is installed by running `git clone`, editing one or two configuration files, and running ./install.sh. It requires 16GB RAM if you enable the full feature set. That includes automatically recording user sessions on web or mobile for replay, and support for end-to-end tracing (so seeing which database queries your api asks for in response to a button tap in your mobile app).
Sentry has a wonderful self-hosting team that's working hard to make Sentry's commercial feature set available, for free, to everyone that needs a mature error tracking solution. You can talk to them on discord and they listen and help.
Georg Hendrik = "George Henry", pretty common name. The fact that Google returned a result when you searched "Georg Hendrik Sentry" should not be considered weird.
OP built a product because they were frustrated by Sentry's seeming hostility toward self-hosting. It doesn't feel like OP decided to build a competing product and then thought it would be a good marketing strategy to falsely push the idea that Sentry is difficult to self-host.
FWIW I've never self-hosted Sentry, but poking around at their docs around it turns me off to the idea. (I do need a Sentry-like thing for a new project I'm building right now, but I doubt I'll be using Sentry itself for it.) Even if it's possible to run with significantly less than 16GB (like 1GB or so), just listing the requirements that way suggests to me that running in a bare-bones, low-memory configuration isn't well tested. Maybe it's all fine! But I don't feel confident about it, and that's all that matters, really.
this is indeed the timeline.
Regarding using the SDKs, I'm telling my users to take Sentry at their word when they wrote "Permission is hereby granted, free of charge [..] to deal in the Software without restriction, including without limitation the rights to use"
- save post body to folders (use uuid as folder name to avoid spam)
- dir listing, and count number of entries
- render posted json to html, highlight stacktrace with js
- download raw json
- rotate, compress old entries.
In my Django app I wrote a logging handler that stores the log records (including traceback) in a database table. I can inspect the log records through Django admin, and a cron job sends me daily emails saying "X new log records in the last 24 hours" so I know to check them out. And that's it :-)
Of course, this does a lot less than Sentry, and has various limitations (e.g. what if the error is about the database being down...), but it fits my needs.
BTW, IIUC, Sentry in its early beginnings was also doing just that – logging to database: https://github.com/dcramer/django-db-log
FWIW, we've been self-hosting 2 instances (and purchase a third hosted instance), for, it looks like 8 years now, and it's had a few small bumps but hasn't been too bad. Our instances are running with 20GB of RAM, so pretty small. ~90% of updates have gone smoothly, which leaves 10% of updates that have had some sort of problem. Solutions have been found in the issue tracker in all our cases. We are a little afraid of doing updates, but do them every couple of months.
Sentry is an amazing piece of software and it is fantastic that they offer a self-hosing version, and all things considered it is a fairly easy self-host.
I "gave up" from the perspective of returning to Sentry after a couple of years, and finding an entirely different beast from the tool I loved before. At that point I indeed didn't make it past Sentry's own FUD.