It’s become the nearly ubiquitous replacement for “Turn it off and back on” - but it shouldn’t be. Sure, it might work, but what value does it add to your users experience, and how are you helping your development team understand the issues if you are just giving it the modern equivalent of percussive maintenance.

What’s the big problem?

Telling customers to effectively reboot your app in their browser doesn’t help anybody in the long run. Whatever the issue was that precipitated the failed application state is more than likely going to occur again. If you aren’t trapping relevant data from the application, then you aren’t going to be able to see what could be fixed to prevent it happening again.

The biggest problem with training your support staff to use this as their first port of call means that your developers can’t possibly fix what they don’t know about. Sure, you might have crash or event reporting - but how do you know that it’s not impacted by the same failed state causing your user to have a problem?

It works, until it doesn’t.

The bigger problem with the default response being “clear your cookies” is that it won’t help server side issues. All wasting a users time with cookie clearing will do is frustrate them. They will be back with the same issue as soon as they are logged in again - and more than likely they are going to have to start the whole support journey again.

My experience will not be typical - every time I’ve had an issue that has meant I’ve had to resort to support has been because of a server side issue. This highlights another problem with (predominantly larger company) support - the assumption that users unable to facilitate the bug discovery process.

Instead of creating pages telling users how to clear their cookies - help your users to help you by teaching them how to generate a HAR and then provide a secure mechanism for them to send it to your developers*.

A last resort

Build the tools into your web application that allow users to completely terminate their session and destroy the local storage if you must - but don’t make them mess around in the browser just to fix your mistake with zero value in return.

Keep cookie destruction away from first level support - if that’s a problem for you, there’s a bigger problem with your application that you need to address first.

There are all sorts of options for monitoring, it’s now super easy with products like Raygun - but there is no guarantee that you are getting the data you need when users end up in the predicament that has them talking to your support team.

Do your users a favour, show how much you love your developers - stop telling people to delete their cookies.

* Don’t receive HAR files insecurely - that includes email. Only people with exceptional privilege within the organisation should have access to them. HAR files contain tokens, PII and all sorts of other things that you don’t want to get in trouble for holding incorrectly.