Identify issues faster with logs!

You are in the midst of exploring the mobile app when it suddenly crashes.

You don’t recollect what sequence of actions exactly made it crash. You try to remember and execute the same steps again but in vain. The app doesn’t crash anymore!

Things going on in your mind :

How would you identify what had caused the crash? What if it doesn’t crash anymore? What if you missed keeping track of the steps you performed on the system/app?

What should you decide?

Ignore the crash? Keep on trying to execute a similar behaviour on a different device or as a different user? Reinstall the app?

If you ignore it or consider that the crash was a rare one - you ignore the risk.

But what if 10% of the live customer base were to encounter this crash?

The app can still end up with bad ratings!

Looking into logs/logging :

Have you ever had a look at the log files for your application? Do you notice which events are mostly fired in the production environment? This is especially relevant if users are facing any issue very frequently in the production environment. Which errors or what exactly in the device is causing that crash - was it a camera or a biometric event or an API call or the network!? Was it an unhandled exception within that new version of a third-party library?

Did the system recover on its own after the exception occurred? Incidentally, that could be a root cause of a critical issue later on.

Logging/logs can be the saviour here. A Logfile helps you piece together this information.

Never miss the chance to review the logs and to monitor alerts.

What’s all the buzz about logging!?:

Logs point out the Problems or threats/suspicious activity if any.

As soon as the crash happens - you can check the space where logs get generated (if the user gave permission).

If written well and with the right planning, logs can give you the exact crash details, the steps you followed and the errors that the app may have gone through before crashing.

What Logs contain or should contain:

The debug/info/error logs, or the crash logs should give a clue about :

• What went wrong
• Which exact place the crash/error happened
• The network at that time
• The device, the OS,
• Browser
• The device language
• The country
• Error code, if any
• Request/Response JSON
• If it was an API error or whether the app failed
• Timestamp
• Backend error message/code/response
• Events before and after the error/crash.
• The start event and the end event.

Such information makes it easy to analyse the issue.

If your application’s logs are high level with just a crash message and no diagnostic info or messages being logged (this can be verified by changing the logging level to debug, error, info, warn), then you will be limited in what info you can provide to the devs. You can always ask Devs for extra logging and diagnostic information which will help you analyse the logs and speed up the root cause identification process. Nowadays, there are libraries, OS facilities as well as third-party tools that devs can leverage to log diagnostic data. E.g. Firebase, BugSnag, AppCenter for AzureDevOps, Google Analytics, Oracle Infinity and so on..

Benefits Log Files serve:

The sequence of steps that we follow in generating the crash is important and logs help us understand the same.

• You can check the timings between the events fired and the response received. This will help identify the minimum time required by all systems - whether the app, API based services, 3rd party services, other backend systems are responding successfully or not, and whether any of these is taking more time in some specific scenario. This is especially important when we need to ensure that the entire workflow completes within an agreed-upon SLA for a workload.
• Not only for crashes but for any sort of intermittent issues, logs help to make it easy to identify the issue’s root cause.
• This also helps avoid situations where Devs tell you that they cannot reproduce the issue… One can share logs and it becomes easy for devs to actually see the issue occurring, reproduce it and find the way to fix it.
• When the team has different environments, comparing logs between environments can give a clue about why an issue occurs only in a particular environment.
• In the Live env, even just monitoring production crashes and errors can give you a better insight on how users are really using the app and what’s causing the errors so you can take it up, fix it and provide users with an error-free experience on the app.
• Event logging can help to analyse the way users use a particular screen or journey in a certain way. A few events may not get logged ever, or a few may be very frequent.

With well-written logs you don’t have to remember what you did, logs capture it all for you. Logs help you find the root cause of the bugs. To understand the user in a real way. To get real-time feedback. To improve the testing.

Use logs as a tool to ease up the Testing and to work with users and devs to arrive at the root-cause and get a fix sooner!