I am the author of this article and I just wanted to drop my thoughts and design notes on how I came to build a smaller and easier-to-host error tracker. The main goal was being able to run it on a VPS.
I've tested it on an Alibaba 2vCPU / 800MiB CentOS machine and it successfully ran, so I am happy.
Another thing I wanted to do was make the integration and migration from Sentry easy, so you just have to modify the DSN line. You can even send data to both Sentry and Epure so you can compare which one you prefer to use.
It's completely free and open source, btw. I am always willing to improve the product as it's an early release. I thought it would be interesting to share with you guys how I came up with this.
This comment makes 1000 times more sense than the blog post intro itself. I’m not one of those people who thinks LLMs should never be used to write blog posts, however it’s up to you to tell the model what audience and tone of voice you’re aiming for - maybe try explicitly saying this is aimed at external developers who’ve never heard of your product and don’t know what you’re trying to achieve… makes me wonder if somewhere out there is a blogger’s equivalent of Matt Pocock skills?
completely agreed. Regardless of AI or not, the blog post completely lacks any kind of introduction and context at the start. I had to stop after the first two paragraphs because I just didn't understand anything.
I understand, and I also don't like to read AI slop.
But the goal of using an LLM here was to provide an article where I can express my own thoughts, reflections, and building notes while making the speech clearer, easier to read, and more structured, as I am not a professional writer.
Anyway, I understand the frustration.
Thanks for letting me know, and have a good day !
> Sentry's self-hosted RAM floor is the cost of a full suite. Design notes on an exception-only path: two containers, a DSN swap, and a dated RSS receipt.
This is the article's description. What is an exception-only path? I don't believe I've ever thought about designing one, and I don't understand its significant wrt the title whatsoever.
It's a really odd way to phrase a concept like "If you only care about logging errors, you can build 80% of Sentry for 20% of the engineering and infra costs."
> If you self-host on a small VPS and only need the next grouped exception, Sentry's RAM warning means the official install is a full suite. That suite is the undesired alternative.
This really reads like something a markov chain chatbot would write. Sentry's warning has nothing to do with installing a full suite. "That suite is the undesired alternative" is a really obtuse way to say bloated.
> A different job is narrower. When production throws, show a grouped issue with a stack you can read, and keep a crash loop from melting the box or the invoice. The rest of this note is that job.
A human would have written 'You don't need all of Sentry if you only need to log exceptions and stack traces.'
Reads like classic Opus slop from before 5.5 - the first few paragraphs are absolutely impenetrable to someone who hasn’t read the prompt used to generate it, there’s nothing to introduce the context or background and it’s full of invented jargon summarising concepts that are never actually described.
13 comments
[ 0.27 ms ] story [ 4.1 ms ] threadI am the author of this article and I just wanted to drop my thoughts and design notes on how I came to build a smaller and easier-to-host error tracker. The main goal was being able to run it on a VPS.
I've tested it on an Alibaba 2vCPU / 800MiB CentOS machine and it successfully ran, so I am happy.
Another thing I wanted to do was make the integration and migration from Sentry easy, so you just have to modify the DSN line. You can even send data to both Sentry and Epure so you can compare which one you prefer to use.
It's completely free and open source, btw. I am always willing to improve the product as it's an early release. I thought it would be interesting to share with you guys how I came up with this.
Hope you appreciate it and happy reading.
I am definitely going to work on this and make my articles better
But the goal of using an LLM here was to provide an article where I can express my own thoughts, reflections, and building notes while making the speech clearer, easier to read, and more structured, as I am not a professional writer.
Anyway, I understand the frustration. Thanks for letting me know, and have a good day !
> Sentry's self-hosted RAM floor is the cost of a full suite. Design notes on an exception-only path: two containers, a DSN swap, and a dated RSS receipt.
This is the article's description. What is an exception-only path? I don't believe I've ever thought about designing one, and I don't understand its significant wrt the title whatsoever.
It's a really odd way to phrase a concept like "If you only care about logging errors, you can build 80% of Sentry for 20% of the engineering and infra costs."
> If you self-host on a small VPS and only need the next grouped exception, Sentry's RAM warning means the official install is a full suite. That suite is the undesired alternative.
This really reads like something a markov chain chatbot would write. Sentry's warning has nothing to do with installing a full suite. "That suite is the undesired alternative" is a really obtuse way to say bloated.
> A different job is narrower. When production throws, show a grouped issue with a stack you can read, and keep a crash loop from melting the box or the invoice. The rest of this note is that job.
A human would have written 'You don't need all of Sentry if you only need to log exceptions and stack traces.'
What I was trying to say is that if you only want grouped exceptions and a stack you can read, Sentry's default self-host is the wrong machine.
Their docs ask for almost 16 GB RAM.
And I just wanted a tool that runs on my VPS while keeping the official Sentry SDK (which is quite good).