New in Yeller: How Many Users were Affected?

This is a blog about the development of Yeller, The Exception Tracker with Answers

Read more about Yeller here

“Damn, there are like 500 exceptions happening all the time. It’s hard to make sense of it all”

I hear this frequently from customers. When you run a busy site, it’s hard to prioritize what to do.

Running a popular app, with thousands to millions of users means exceptions show up all the time. Some of them are minor issues, some are weird bots crawling your site, and some are really damn important. How do you prioritize what to fix, or determine if you should even be fixing an exception?

Most users won’t report an error to you at all - they are so used to computers breaking, they either just give up on their current task or try and find another site to help them solve their problem (via clicking the back button).

So, as of today, if you send the right kind of information to Yeller, it’ll track how many users were affected by each error, as well as the count of how many times it happened in total.

This gives you a much better criteria for if you should fix an error: if it’s affecting a lot of your users, then you should consider fixing that error first.

This is especially important if you have an API - it’s entirely possible that a lot of errors could come from one user trying something out - and that’s definitely less important than an error that’s affecting a large percentage of your customer base.

So, to use this feature, Yeller requires that your custom-data in the json payload includes a “user” with a positive numeric id field (so auto-incrementing ids, or Datomic entity ids all work great here):

  "custom-data" : {
    "user" : {"id" : 123456}
  # rest of error here

If your data doesn’t include this field, then Yeller won’t track the number of users affected. Simple enough.

Ids have to be positive numbers, and can’t exceed the maximum value of JavaScript’s float (because Yeller uses JSON over the wire).

If you’re using Yeller on a Ruby on Rails app, and the controller the exception was thrown in has a current_user method, and that user responds to id with a numeric value, this feature will be on automatically when you upgrade to the new gem version (0.1.0).

This is a blog about the development of Yeller, the Exception Tracker with Answers.

Read more about Yeller here

Looking for more about running production applications, debugging, Clojure development and distributed systems? Subscribe to our newsletter: