Struggling with running DQ Scans (Long queuing and Retry Count Error Issues)

lsims, I would extend Jamony's suggestion by measuring queue time separately from execution time. For each scan, record submission, start and completion times, asset, rule-set version and job ID. Fabric capacity appearing idle does not identify where the Purview job is waiting, and a retry-limit error alone does not prove a defective rule. Compare one previously successful rule on one unchanged asset with the larger rule set, keeping the connection and test window comparable.
If failure follows a particular rule group, narrow it in a test copy while preserving the original configuration. If the minimal scan also waits or fails, the evidence points toward a shared connection, service or orchestration issue worth escalating. Microsoft's troubleshooting page also distinguishes a skipped scan from a failed scan and lists source-format, connection and schema checks: https://learn.microsoft.com/en-us/purview/unified-catalog-data-quality-troubleshooting . I would not infer a supported concurrency limit or recommend a capacity upgrade from the symptoms alone.
The governance consequence is covered by the Measure and Prove stages in my published PALO Framework: https://paloframework.org/ . Report rule execution coverage, data quality results and evidence freshness separately. A failed assessment leaves quality unknown for the affected scope; it must not become a pass or a data defect. Keep the last successful result visibly dated, with an owner for the assessment gap. This makes the dashboard useful while the underlying scan issue is investigated.