I personally use Crash Catch for my own projects to identify issues in other products and services that I create and in doing so I found some issues, some of which are bugs, some are usability issues and realised that the user interface is a bit clunky and disorganised.

Therefore, I’ve been hard at work doing a complete redesign of the user interface making it simpler and cleaner.

Before I get onto the visible changes, lets talk a little bit about the background changes. The web interface and API has been restructured significantly, this makes it much easier for me to be able to maintain and add features and fix further bugs as they are found as time goes on.

Background Changes

Some of the Crash Catch libraries have also been fixed (ReachJS, PHP and Flutter) have been fixed as some bugs were identified where it meant a crash might not get successfully sent. There’s also been some significant changes to the React JS crash processing as it was identified crashes could fail to be resolved and then cause the backend systems to get stuck for further ReactJS crashes.

If you aren’t aware, ReactJS crashes are sent in a minified state, so they are not human readable, at least not without manual work to decode it. When you create a new version for your project, you need to upload a new source map and when Crash Catch receives the crash, it uses the uploaded source map to decode the incoming stack and provide something meaningful that you can use to work out why your project through an error.

The way Crash Catch does this is two apps. One is the engine which hosts the crash submission API, validates the account details, submits the crash, does some other housekeeping jobs etc. There’s a second app called Stack Resolver which is a NodeJS server where the engine can receive the crash and then submit it to stack resolver which uses a third party library to decode the stack. There was nothing wrong with the 3rd party library, but I was fairly new to creating a NodeJS server and it was that, that was causing the problem. For example, if a crash was received but there was no source map, the stack resolver would get stuck and the thread within the engine waiting for a response from Stack Resolver which then meant further processing of ReactJS crashes got stuck and they would just end up in a decode queue and wouldn’t get processed.

To get round this, the Stack Resolver app was completely rewritten and retested to ensure failures within stack resolver don’t affect the engine.

Visible Changes

The entire frontend has been completely rewritten, making it simpler, easier to follow and the page being less cluttered.

Lets start off with the dashboard you were shown after the login. This page was probably the most cluttered and complicated layout. Instead you are now shown the project dashboard. A screenshot of this is shown below:

Project Dashboard

The project dashboard, as the name imples, shows you all of your projects in a card view. This shows you the number of errors that have occurred in the last 24 hours for a project along with a bar chart to show you how many crashes have been received through different time intervals within the 24 hour period.

When you click on a project you are taken to the project dashboard, this is a little bit like the original dashboard on the old version, but specific to your project and simplified layout. An example of this is shown below:

Project Details

This page shows you the number of crashes, how many different users have been affected, a breakdown of the different statuses as well as a line graph showing you the crashes received, and how many active users your project has received over the selected time period.

Under this is a breakdown of the handled vs unhandled crash counts along with a breakdown of the different severities of issues that your project has received.

Under this is also a table of all the different issues that your project has, this is the same as under the issues page as shown below.

On the left hand side is a link to the issues page, this shows you all of the crashes groups that have been received by Crash Catch for all of your projects as shown below.

Issues

From this page you can filter the issues for a particular project and through a particular time period. You can see the number of incidents each crash group has received, and the number of affected users of the crash group as well as who it was assigned to and the ability to assign a crash group to a member of your team.

When you click on an issue title, you are then taken to the details page, where you can view all of the information relating to the crash as shown below:

Issue Details

At the top of this page, you can view the exception group, the exception message, whether the issue was handle or not and the severity.

Under this you can see when the issue first occurred and the issue last occurred, the total number of times the issue has been raised, the number of affected, the current status and who it is assigned to.

Under this is the ability to mark the issue as resolved or change to another state such as in progress, under review etc and another option to ignore this crash group. This allows you to stop receiving notifications for a particular crash group for all future occurrences, or stop receiving notifications on crashes for the current project version or below.

Following this are the individual incidents, when that particular incident occurred, the version number and the stacktrace along with the device details of this particular incident.

I hope that you find these changes to be a big improvement to the previous version. Crash Catch is still running as 50% off while in beta, when signing up you receive a 14 day trial no credit card required you can cancel at any time.

If you have any feedback, good or bad, then please let me know, either in the comments, or feel free to drop me an email at [email protected].