{"id":460,"date":"2026-01-30T09:55:34","date_gmt":"2026-01-30T09:55:34","guid":{"rendered":"https:\/\/productive.io\/engineering\/?p=460"},"modified":"2026-01-30T09:55:34","modified_gmt":"2026-01-30T09:55:34","slug":"so-youve-started-tracking-errors-now-what","status":"publish","type":"post","link":"https:\/\/productive.io\/engineering\/so-youve-started-tracking-errors-now-what\/","title":{"rendered":"So, You\u2019ve Started Tracking Errors. Now What?"},"content":{"rendered":"

Workflow<\/a><\/p> –

{{minutes}} min read<\/p>

So, You\u2019ve Started Tracking Errors. Now What?<\/h1> \"\" <\/a>

Davor Tvori\u0107<\/p><\/a> Frontend Engineer at Productive. Excited about anything related to computer science. I spend most of my personal time reading and playing video games.

January 30, 2026<\/p> <\/a> <\/a> <\/a> \"\"

Let me start off with a little exercise. Just sit back, close your eyes and let me know if this sounds familiar. Well, maybe you shouldn\u2019t close your eyes<\/strong>.<\/p>

Anyway, you\u2019ve been working on a project for some time now. Some bugs are reported to you now and then, but you feel something\u2019s off.\u00a0

You suddenly remember that it would be a good idea to set up some kind of an error tracking system. There are a few choices, like Sentry, Bugsnag, Rollbar and some more. After choosing wisely, you install everything necessary and, lo and behold, some errors are starting to show up!\u00a0

And now comes the critical part. You promise<\/strong> <\/em>yourself that you\u2019ll check the error reports periodically and fix them as they come in. If that sounds familiar, chances are that these error reports aren\u2019t getting fixed as diligently as you\u2019d expect.<\/p>

Now What?<\/strong><\/h2>

What I just described is the current situation at Productive. Bugs are getting fixed, but the ones that don\u2019t \u201cstand out\u201d are kind of getting overlooked. Another issue is that the error reports are in Bugsnag, so they\u2019re not in your face when you start working on your tasks for the day. As a consequence, our product managers aren\u2019t always aware of the error reports so they can\u2019t plan accordingly.

As part of our team\u2019s internal initiative, for some time now, we\u2019ve been aware that it just isn\u2019t enough to set up an error tracking system. A process around it must exist. Just like with tasks, someone has to be responsible, the level of priority must be evaluated, and the error reports must be considered part of the workload. And now, with more people in our team, we can finally make things right.

In this post, I\u2019ll show you an overview of all the things we\u2019re trying to improve to really get a grip on bugs and errors.\u00a0

Since we\u2019re currently working on this whole process, some things might change or some new points might get added, but the general idea will still stand.<\/p>

Defining the Pain Points<\/strong><\/h2>

First of all, I\u2019ll let you in on a small glimpse into the current state of our Bugsnag:<\/p> \"\"

I\u2019m sure this might come as a surprise to some of you, but when you have a lot of users doing all sorts of things in your app, things are bound to go wrong.\u00a0

Even though this will be improved, as it is\u2014this still gives a lot of information on how to organize a seemingly unrelated bunch of errors.

I\u2019ve briefly mentioned which issues bothered us the most. There were a couple of issues on top of that, which we found out about after running a quick poll between our team members:<\/p>