Sentry, The (Now Profitable) Bug Tracker Gets A Huge Makeover
techcrunch.com
techcrunch.com
I wish...
- I could search w/ meaningful results
- I could group by exception type.
- I had a better method of seeing the different input data that caused the exception (without next/next/nexting).
- there were lots more information around my source code.
I could probably come up with a few more if I were pressed to. All that said, we'll continue to pay for the service b/c its useful to our business.As a side note, we also have a legacy internal log error application that we also use, but it is nice to not have to deal with any of that infrastructure :).
We're a Atlassian/JIRA shop internally, and the JIRA plugin. It's not better than having a bug free product, but it is amazingly reassuring to the customer when they contact us with an error and we're already looking at the stack trace and fixing the problem.
Thank you for this incredible product.
To whoever is interested, I am maintaining this repo, that allows you to install sentry on heroku in a couple of steps https://github.com/dmishe/sentry-on-heroku
I love everything about it, looking forward to having a poke around the new design!
> "The cost of running and deploying your own server just to monitor the errors maintenance in your application for a lot of users isn’t really practical – there’s a lot of and cost involved with maintenance and upkeep"
I don't really understand this, we just stick it on our app/db servers alongside our other applications. The cost is $0 and it takes about 5 mins to set up, it's just a Django app.
Disqus has two physical servers dedicated to it. Both of them are larger than any of the web/worker machines getsentry.com runs. On top of those costs, they also have the upkeep cost of running those servers, doing software upgrades, and, if anything goes wrong, debugging things.
Obviously Disqus isn't a great example, since we built the software and know how to run it, but companies much smaller than Disqus don't really have the reason to invest the money or time into setting up infrastructure to support it.
Delicious is using Sentry on their new JavaScript-centric site, and for the amount of data they're sending, they'd be spending a lot more on hosting costs and infrastructure maintenance. It's not ideal for everyone (some companies push a lot of data through Sentry), and we don't necessarily aim to serve someone who may be sending millions of events in a day.
What we typically see is that most people are sending somewhere between 5,000 and 50,000 events, which is right about the size where it's not practical to host the instance yourself. It definitely beats maintaining RabbitMQ, Redis, Memcache, Celery, WSGI, Postgres, and soon, Elastic Search.
Is there something obvious I was missing?
This all being said, I'm very impressed with exception reporting at getsentry.com!
I'm not sure what the best term for this other kind of "bug tracking", but almost certainly it should be something else.
Maybe something like "live bug analytics"?
We'd also rename service to platform, as an example
https://app.getsentry.com/sentry/sentry-js-test/group/323091...
(This was recorded before we annotated sourcemap data, but the original error here was actually in a minified javascript file)
Also, of note, there's some things that don't fully function when you're viewing a public event without full access. One of those things happens to be the graph on that link.