3 ms·

Yeah, I came in here to call out the error tracking use case...a good error tracker needs to do a _lot_ more than that.

• anderspitman 7y ago
  Good for all projects, but how much does the project at hand actually require? And adding dependencies later is a lot easier than removing them.
• volument 7y ago
  I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.
  • cpfohl 7y ago
    Yeah it needs to do that, but that likely means that deploying a particularly egregious bug will fill your inbox with repetitive and useless data. It should also give you information on the current user, the browser, locale, etc. None of that extra stuff is really extra, it's critical for quick debugging. It's also hard to get right, and doesn't preclude inbox zero in any way.
    • volument 7y ago
      Internally we use Redis sorted sets to merge the errors into one entry on the inbox. We get the browser info from server HTTP headers. It's a cute list of errors that we regularly run trough.
      • buremba 7y ago
        Well, your error tracking solution is not simple as a javascript snippet then.