Honestly, their only job is to store stack traces. In about 20% of occurrences over the last 6 months, we've been told that our data "has been lost and is not recoverable." Thus we know that an exception has occurred, but we're lost as to why.
It's such a simple app that we've considered rolling our own. We believe we can achieve better than 80% uptime.
Btw, it is fairly simple to build a minimally-useful product like this -- I built our prototype in about 2 days. But there's an extremely vast array of really cool and useful functionality that we're working on that takes a lot longer :) We're currently at around 20k lines of code.
It only takes about a minute to set up on heroku, and it can store whatever you want, not just exceptions.
So, your uptime average is slowly creeping up again. Otherwise we're relatively happy with the service—it's just that there isn't much "otherwise" besides simply viewing the stack trace. Honestly there's not much to it.
Congrats on your achievement and all, but it's difficult for me to get excited about an app that any competent programmer could probably whip up in a day or two.
You must tread very, very carefully when using those words. Being programmers does not magically admit us to a complete understanding of every detail of a piece of software. If you’ve ever delivered a product, you should know that what the user sees is only a fraction of the whole—even if the user happens to be a competent programmer. And if you consider yourself such a programmer, why not try replicating their software from scratch, if it will really only take a day or two?
I envision most of the difficulty that exceptional.io has encountered has been related to scalability. If I wanted a small, simple, self-hosted application with this functionality, it will probably be simpler. I'm not guaranteeing this, but I'm making a good estimate based on my experience creating similar web apps and utilities throughout my career—this ain't no blind shot in the dark guess.
You're right, being programmers does not make us magically able to understand details of software. But being good software engineers does involve a lot of exactly that skill. They are separate and distinct skills, but most great programmers I know are also great software engineers, and also great estimaters of project complexity. In my experience, I am as well (in fact I am generally better at estimating project architecture, complexity and time than I am at programming itself). This is where my response comes from—not simply being a programmer. Apologies for the confusion.
The only downside I can figure is that it doesn't integrate with any ticketing system.