Not every bug results in an error being thrown or any other signal that you could automatically detect. From my experience most of them are way more subtle.

While parent’s point is for devs, any kind of support situation falls into the same issues.

Grand-parents/friends/org users not being sure to be on the right site after a redesign, not seeing amazon in the right language, etc. There’s countless of questions that can be solved faster by looking at the URL.

Sentry only capture software exceptions. It doesn't tell you a page is rendering badly in the user's browser.

You can send your own events to Sentry. It's not just for exceptions.

How do you make an event for rending looks weird, or text is unreadable or ?

Have a "report issue" button which leverages Sentry's (or your own, or some other service's) metadata collection and sends a report to you.

My QA team sends me URLs and screenshots sometimes. Often the first thing I look for on a screenshot is the URL.

How can I tell you don't work in IT? Almost all companies including mine have ONE site to choose from to do any one thing. If it doesn't work, they either ask their colleagues (which only works if it's not the first time someone is using this around them) or create a ticket for IT.

I've been a web developer for about 25 years. I can assure you if something doesn't work the users usually won't raise a ticket. They'll work around the problem. On the occasions when they do raise a ticket it'll usually contain minimal information. Having a telemetry system to correlate it against gives you some information to use to debug the problem. That's helpful.

Understanding that users have more important things to do than spend time on bug reports is an important lesson to learn. If you can gather data without relying on someone whose job is to worry about other things then you will make everyone's life easier.