We approach it a bit different: we blur the lines between E2E testing and production monitoring. You run an E2E test and promote it to a monitor that runs around the clock.
It's quite powerful. Just an E2E test that logs into your production environment after deploy and then every 10 minutes will catch a ton of catastrophic bugs.
You can also trigger them in CI or right after production deployment.
Big fat disclaimer: I'm a founder and CTO.
Many classes of automated test ("regression", "smoke", "e2e", etc.) are the same test and the difference is that values like the application location or maybe the expected data are different. To your point, iirc New Relic's synthetic monitoring was using Selenium under the hood. If you take this approach and you're tagging tests, you can have the [CI/CD system] use the tags to run specific sets of them at specific steps or times with the desired inputs.
But, some of that requires a coherent strategy for test data, which seems to be a common pain point for orgs.
[Edit: To be extra clear, not all types of tests fit this. You obviously don't need to run unit tests against your prod app. And, writing/managing things like API tests in a tool like Cypress isn't necessarily a good idea.]