The ability to set the status of an error is our most commonly requested feature. Customers want to mark errors as fixed, or one team member wants to let the rest of the team know they are investigating an issue. There’s hundreds of reasons to set the status of an error, and until today it was something users couldn’t do in TrackJS.

One of our biggest challenges is helping customers make sense of their JavaScript errors. Web applications produce a staggering number of errors, but not all of them are relevant. We have great tools like ignore rules and error groupings to help curate the data, but some noisy errors still get through.

We’ve known for some time that a good free-form search is important to help our customer’s slice and dice error data, but until recently our search experience was mediocre at best. We had something that sort of worked, sometimes, but this was an area we needed to improve.

Four years ago, we launched TrackJS as A Better Way to Track JavaScript Errors and introduced developers to the Telemetry Timeline. Many JavaScript errors are difficult to understand without the context of prior events, and TrackJS continues to provide the best information available to help you fix bugs fast.

We recently launched a bunch of improvements to our error report UI that will make understanding JavaScript error stories even easier.

Redux is an amazing JavaScript library that has become mainstream because of its simplicity, tiny 2kb size, and excellent documentation. Redux assists developers to manage state in JavaScript applications and ensure it performs consistently, regardless of the environment.

However, despite Redux’s awesomeness and versatility, software will always have bugs. It is the responsibility of the careful developer to minimize them and their impact on the users. We’ve gathered five common sources of bugs using Redux, and some ideas to prevent them.

We recently took some time to take stock of our practices and procedures following the outage at GitLab. The GitLab outage started when a developer made the easy mistake of entering a command on the wrong server. Unfortunately, that server was part of their production environment. If this could happen to a company like GitLab, could it happen to us? What could we do to avoid falling into the same trap?

We’ve been hearing a lot about Elm lately, especially how it claims to prevent errors. Our newest contributor, Matt Granmoe, will explore it, how to get started, and some thoughts on error prevention and debugging. Matt will be exploring error handling and debugging in various JavaScript and web technologies with us. Matt is a JavaScript developer, progressive bassist, blogger, Filipino martial arts practitioner and active contributor to various libraries within the React/Redux ecosystem.