Currently, there's no support for XE Trace events (Top SQL & Blocking SQL) for read-only replicas of Azure SQL Single Databases.
The following error shows up at the client:
SQL Server XEvent Trace Server Error: Database Cannot Be Read-Only
Message: The SentryOne database cannot be read-only.
1. Verify the target server is online and accessible
2. Verify Monitoring Service account has sysadmin permissions on the target SQL Server instance(s)
3. Check Error Log for related details
4. If the error persists, or if further assistance is needed, please contact SentryOne Support
Which is rather misleading since it's the watched target that's read-only, not the SentryOne database.
Regardless, the issue is due to the fact that XE database sessions cannot be created in read-only replicas.
However, XE event sessions are replicated from the primary database, if it is also being monitored, and can be utilized at the read-only replica.
More details from Microsoft Docs (https://docs.microsoft.com/en-us/azure/azure-sql/database/read-scale-out#monitoring-read-only-replicas-with-extended-events)
Monitoring read-only replicas with Extended Events
An extended event session cannot be created when connected to a read-only replica. However, in Azure SQL Database, the definitions of database-scoped Extended Event sessions created and altered on the primary replica replicate to read-only replicas, including geo-replicas, and capture events on read-only replicas.
An extended event session on a read-only replica that is based on a session definition from the primary replica can be started and stopped independently of the primary replica. When an extended event session is dropped on the primary replica, it is also dropped on all read-only replicas.
Therefore, SQL Sentry should still be able to use this XE session, if it knows to assume that such already exists at the primary node.