You might think of errors as those pesky reminders that your app is not perfect (and who wants to be reminded of that?!?) but they’re also proof that your app is being used by actual real live people, actual real live people who are doing more than just skimming the surface. They’re digging in and wanting to get the most from it.
That’s great news!
Not everyone loves those error logs though (not yet at least!) Maybe there are some people in your company who find them too boring or too many to bother with and they just ignore them? That’s tragic! Carry on ignoring them and your plan for avoiding disaster will disappear and, before you know it, it’ll be too late to do anything about it.
We can not let that happen so, without further ado, here are six ways to bring the love back to those error logs so you can start treating them like the secret weapon that they actually are:
1. Don’t treat all errors the same
You might have heard it said, “All errors are equal, but some errors are more equal than others.”
Serve all of your error logs on a single plate and offer it to every person on your team and you’re in danger of giving them indigestion! Too much of it will be totally irrelevant to most of them.
What is irrelevant to one developer can be the next person’s golden nugget but there are so many different types of errors, having them all treated in the same way is the quickest route to having them all ignored.
Imagine a scenario where the support team receives notification about a synchronization issue that causes a few milliseconds delay to the users of your app. Imagine they receive several hundred such notifications every ten minutes while the developers are looking for a solution.
At the same time, a user is having a hard time submitting payment because of an invalidated field in his form. An error notification is sent each time he tries but, because of the huge volume of notifications coming in via the sync issue, the support team misses it.
For every customer who bothers to complain, 26 other customers remain silent, according to White House Office of Consumer Affairs.
More about the cost of bad customer service from Helpscout.
The user might try a few times, but he eventually decides to abandon the process without contacting support. He’s frustrated and a payment is lost but all that could have been avoided with a proactive support email to the user to help him out.
Having all errors treated in exactly the same way is a surefire way to make sure they will all be ignored in exactly the same way.
At InnerTrends we developed a system where errors are filtered out for each department based on content and context. By excluding errors that are not of interest (instead of including the ones that are of interest) we also make sure that new errors that have never been logged before reach the right people.
2. Make sure each error log provides context
Receiving an error that just tells you that “an error occurred master” can only cause panic.
A good error log answers these questions:
- Who did it happen to?
- Where did it happen?
- When did it happen?
- What variables were involved?
While it’s true that sometimes your system can not answer all of these questions, having as many of the answers logged as possible will make the error log what it actually is: the most actionable metric in your app. It will help you fix it and fix it now.
A big advantage of knowing whom the error happened to is that you can contact that person and let them know that an error happened and that it’s been fixed. Proactive support can be a great sales channel for your web or mobile application.
Here is how we log errors at InnerTrends:
3. Monitor frequency next to the context
Just like the earlier synchronization example, some errors will happen only one time so it’s not usually worth fixing them. Other errors will happen with a more regular frequency but have no visible impact on user experience.
By way of example, think of 404 pages. The more you grow the more they will happen and there will be almost nothing that you can do about them. The resources needed to fix them would be much higher than the benefit from doing so.
However, that doesn’t mean you should ignore 404 pages and stop logging them. In such situations it’s worth monitoring the frequency of the error because if a change in your application causes them to increase ten fold, you want to know about it so you can investigate and make any necessary fixes.
Monitoring the frequency of some errors is sometimes just as valuable as monitoring the context of the errors because it will allow you to act in real time to fix the error. We chart each error in time at Innertrends so spikes are very easy to spot:
4. Make error log history easy to search
Trends allow you to check the history of a specific error. Being able to search this history for the context of the error each time it occurred can be a gold mine.
Each time a user contacts support about something not going right, the first thing we do is try to replicate the error so we can isolate the problem and fix it. Having access to the history of the user, the errors he got and the history of that specific error with other users will make the job of every tester or support team member easier and much quicker.
The quicker they finish a task the more money we save. Have we mentioned that errors are the most actionable metrics? ?
5. Critical Errors need real time alerts
There are certain errors that have a big impact on your web application bottom line so, even if they happen at 3am, you want them fixed as soon as possible.
Servers going down, broken database connections and hacking attacks are all examples of the type of error that will not wait for you to finish your coffee before starting to work on them. You want to know about them and you want to know right now.
Incidentally, having the error log system on the same server that just broke down is a recipe for disaster. If the server is down, how will it notify you about the error?
At InnerTrends, a quick and sudden drop in error reporting is treated as an error in and of itself and we make sure the whole team is alerted any time such spike occurs.
6. Use the right channel to monitor error logs
On the different setups we have worked with for different customers, the system administrator usually has their own error tracking which might look scary to everyone else, but it helps them a lot. Everyone else either does not receive logs or simply receives them in their email.
Thousands of unread email logs stay in a dedicated folder or label so they don’t fill in the inbox. The error emails are only accessed when somebody realizes something went wrong and everybody is going through them to discover what the problem is. As usual, it’s a bit too late and that time will become a big cost and interruption for the whole team.
Does that sound all too familiar? Here is how we like to fix this issue:
- split the content of each error log in valuable chunks on which we apply custom tags
- forward those emails to our log tracking system which parses them and converts them into readable logs
- let each department apply filters on error logs
- notify users about their filtered logs through native browser notifications
- set alerts for critical errors via email and/or SMS
Whether or not you’ve been giving your error logs the loving they deserve, there’s no getting away from the fact that, used well, they are a valuable tool in your business decision making arsenal.
