Post

If you use the string “try again later” in an error message you should go straight to jail. It should be a standard rule in all linters.

I'd be curious to know what your standard solution has been to handle that scenario; everybody seems to have a slightly different approach. My general approach is to give them a message saying that an unknown error occurred and a link in the notif to an incident page, pre-filled with details.

When would you not know what the problem is?

0 reposts0 likes

I don't know about others but for me, generally it's an integration point with a 3rd party API of some kind. It might not give a meaningful response header or it might itself be broken somehow.

I’m being a little bit facetious but you _always_ know something. If this is because you made some API call and got a 503 or whatever you know that you can’t currently talk to the backend and you should hopefully be able to link the user to more information (status page, support email, etc)

I agree from a technical standpoint. But from a non-technical user perspective, referring them to more technical information is rarely helpful to them. Even if the status is 'not available; that doesn't help them know when the problem is resolved or even how serious it is. 1/4

That assumes the API makers themselves have meaningful status information that includes fatal/non-fatal error rates. I agree I can log it and get to the problem quickly. I thought your point was that in the case of an error just telling people to sit on their hands wasn't respectful of the user. 2/4

You mentioned a support email option. I've never found that completion of those forms is helpful to me or my devs because all the user can say is it's broken. That's why I try to give them a pre-filled form that they can just click. That helps us by giving us an actual severity. 3/4

If you don’t have a status page, or you don’t have any way to communicate with your users when you have an outage, that’s a separate problem you need to fix.

I agree with that. Let me ask you though, if my app is up and the issue is say one endpoint in an API and not the entire integration, how would I meaningfully report expectations and resolution to the end user?

I don’t see how that changes anything. You would have a separate status page that reports that that endpoint is having problems. The error message can direct users to the status page. From there it’s the same playbook as before.