CritiMon - Crash and Error Reporting for Every Developer

Chris Board

May 23, 20199 min read
critimoncrash-reporting

We've launched a brand new crash and error reporting service available at https://critimon.boardiesitsolutions.com that works with any platform and programming language and provides real time crash notifications as they are received.

CritiMon is aimed at every developer from solo developers to small startup companies to receive crash and error reports from any projects you are working on whether its software, mobile apps and websites, whether its a frontend service or backend service, you can receive crash and error reports from anything and include information in the report to help you diagnose what happened.

The service provides real time notification, as soon as a crash happens, no waiting around for hours, or even a whole day to know that something has gone wrong. No more relying on your customers and users to tell you about a bug, find and fix issues quickly and new versions released sooner rather than later.

There are two types of crashes and errors that the platform can be reported on, handled and unhandled.

Unhandled crashes are the most critical of crash. These cause your apps to crash or your scripts to stop processing and either don't render on screen as expected or display a "something has gone wrong" type error to the user and the app is force closed.

These types of crashes can be captured with just a couple of lines of code

$critimon = new CritiMon("your_api_key", "your_app_id", "app_version");
$critimon->initialise();

The above code snippet is from PHP but its very similar from language to language. With just these 2 lines of code, you can receive unhandled crashes and errors from your apps and scripts straight away.

But unhandled crashes, although critical to know, aren't the only ones you should be concerned about.

Handled crashes should also be reported. Handled crashes are crashes and errors that you handle within your code, e.g. from within a try/catch statement. In this scenario, all it takes is one line of code to send these kind of errors as well and you can get a full picture of how your app or service behaves in production along with device specific information.

try
{
	//perform some action here that might cause an exception
}
catch (Exception $e)
{
	$critimon->reportCrash($e, CritiMonSeverity::Major);
}

But that's not all, what if you want to receive more information regarding a crash to provide what parameters were used by a method to help replicate and diagnose the problem you are seeing. This is done by creating a JSON object or a JSON array or a simple array depending on the platform such as below:

try
{
	//perform some action here that might cause an exception
}
catch (Exception $e)
{
	$debugData = array();
	$debugData["api_method"] = "getCustomerData";
	$debugData["customer_id"] = $customer_id;
	$critimon->reportCrash($e, CritiMonSeverity::Major, $debugData);
}

That's it, that's all you need to add to your project to start receiving crashes and get a full insight in to how your app or service behaves.

I've received crashes - now what?

Once you've registered your application and added the required code snippet to start sending crashes and errors. As soon as a new crash is detected you will receive a notification in near real time so you can start investigating and start working on a fix as soon as the first user hits a problem.

You can view the crash details which includes the following information (some information may be dependant on the platform)

  • Date and time of crash
  • Device manufacturer
  • Device model
  • Device screen resolution
  • Device operating system
  • Device kernel version
  • Class file
  • Line no
  • Exception message
  • Crash type (handled or unhandled)
  • Severity (Low, medium major, high, critical) (all unhandled crashes are marked as critical)
  • Affected users
  • App version
  • Stacktrace

When you view the crashes you can create notes about the individual crash or the crash group to keep your team informed and up to date on what is being worked on. You'll be able to @mention people within your team to send them a notification that you need to involve them in the investigation of a crash and you can assign crashes to users within your organisation.

From the dashboard you can see an overview on what apps are causing the most problem, how many crashes you've received over the course of your data retention period and view the activity stream which shows when crashes are updated, assigned, resolved and when new app versions are detected for an app.

Organisation Dashboard with Activity Stream

When you view the app details and crash data you will also be provided with an active user analysis chart. This shows you how many unique users have been using your app over the course of the last 24 hours, the past week and the past month. Not only that, but the platform will automatically detect when new app versions are first used and overlay this over the active user chart and the crash count. This will show a clear indication as to whether or not a new release is providing a positive or negative impact on your customers and users.

Active user analysis and crash counts with app release detection overlaid

Crash groups that have been detected by a particular app/service

You have complete control over what crashes are reported on and shown via the web site. Lets say a crash is received but there's nothing you can do about it as its hardware specific bug that you can't amend from your own code, or a user(s) is still using an old version and won't/can't update but you know you've fixed it on a newer release, you can tell CritiMon to not report on it anymore.

You can either choose not to report on a crash group or on a specific crash.

If filtering on a crash group you can choose to filter between the following:

Crash type, i.e. whether its a handled or unhandled crash or both and any version number, a specific version number, or a version number and below.

If your filtering on an individual crash group the following filtering options are available are to stop reporting against the line number, class file and/or the severity, all versions, the current version only or this version and older.

We plan on adding new features including an Android app so you can manage and view the crashes within your organisation from your Android mobile or tablet device.

All of our SDKs are Open Source via our GitHub account at https://github.com/BoardiesITSolutions prefixed with "CritiMonLib-". We currently have SDKs available for:

  • Android
  • Javascript
  • PHP

We plan on adding other languages soon such as C# and C++ and if you are running on another platform or programming language there is the option to create your own SDK to submit crashes for custom platforms. If you create one, be sure to let us know and we'll include you to our list on our website.

Why did we build CritiMon?

I've been developing in multiple languages and platforms for over 15 years doing side projects in my spare time around my full time job as a Support Manager/Engineer for a local Telecoms Software company. Being a solo developer for my side projects, I didn't have a lot of spare money to be able to afford crash monitoring and I found many of the available platforms only supported a particular platform, i.e. focused on mobile, or focused on web etc. Money wasn't the only factor however, as I found many services focused on a particular platform, I didn't want to manage multiple accounts as that would be impractical and hard to manage.

As I developed for Android, I then mostly relied on receiving crash data from the Play Store and relying on receiving customer feedback for anything else that might happen unexpectedly however things turned out to be a bit of a disaster.

We had an app on the Play Store, that was doing relatively well, it wasn't really advertised and just relied on people coming across it, but it had around 500-1000 users with our servers receiving around 2000 requests a day for the API. I noticed it was around a specific Android version but everytime I tried to test it I couldn't replicate any errors and everything seemed to work as expected. Eventually figured it was to do with a 3rd party library - that unfortunately didn't run if the device was an emulator and didn't run on my device as I had the pro unlock enabled for the app, when I turned this off it crashed. I discovered that at some point either this library was automatically upgraded via Google Play Services or a server side upgrade which affected this particular android version. We got around this problem and released a fix, but by this time the damage was done and the app never recovered.

This triggered the idea or CritiMon. I initially built this as an in house project to be used just by our apps and services. However, I thought back to the reasoning I wanted to build it in the first place - I wanted one central place to manage all crashes and errors from any platform and any programming language I use and ensure it is affordable. Therefore, due to this we decided to launch it publicly specifically focusing it for other solo developers or small start up companies.

We've been using it in house for around 6 months and have found it to be invaluable in getting a clear understanding of how our apps and services are working in production environments.

You can sign up for a free account today and upgrade later as needed to small or a pro plan depending on your requirements. Currently we're offering all paid plans to be 50% off, for the lifetime of your subscription fora limited time only.

For more information or to sign up, please visit https://critimon.boardiesitsolutions.com. If you have any questions, then please feel free to contact me at [email protected] or leave any comments below and we'll be happy to answer anything.

You can check out our screenshot gallery below

Screenshots of CritiMon

Test Track

Are you a developer or involved in Quality Assurance Testing or User Acceptance Testing, you might be interested in Test Track

A simple and affordable test planning and management solution.