> this message doesn't provide much actionable information Even if it did, you'd likely not be able to do anything with that information (i.e., a web app retur

> this message doesn't provide much actionable information Even if it did, you'd likely not be able to do anything with that information (i.e., a web app returning an HTTP 500). Details potentially leaks information the developer doesn't want out there. For example, in SharePoint Online you wouldn't want the correlation log provided to the end user -- it's not useful to the end user, it isn't necessarily limited to just what they did, and it may contain PII. > unhelpful to the developers who presumably implemented that error messaging In my example above, the user would relay to a technical support individual the date/time/<other information>, and the support individual could then correlate within the logs, potentially passing it back to the developer. Now, if the developer did a poor job of correlating "friendly" error messages to something that can be diagnosed on the backend, that's on them.