## Summary Follow-up from the discussion in #587127 ([note thread](https://gitlab.com/gitlab-org/gitlab/-/issues/587127#note_3024401057)). Multiple customers have reported issues with foundational flows (especially Code Review) not working due to misconfiguration. Currently, users receive generic and cryptic error messages, and debugging often requires running commands in a Rails console (for self-managed instances), which is a poor experience. ## Problem - Foundational flow settings cascade to sub-groups and projects via long-running Sidekiq jobs, but there is no visibility into whether the configuration is healthy after cascading completes. - 90% of customer complaints about foundational flows not working are due to misconfiguration that could be surfaced proactively. - There is no in-UI feedback about configuration health at the group settings level. - Related customer complaints: gitlab-com/request-for-help#4223, gitlab-com/request-for-help#4084 ## Proposal Add a **health check widget** to the group-level Duo foundational flow settings page that: 1. **Runs health checks as background jobs** (not inline during HTTP requests) to avoid the same long-processing issues as the cascade itself. 2. **Surfaces results near each flow toggle** so users can immediately see per-flow configuration issues (e.g., missing service account, incorrect member lock settings, cascading not propagated). 3. **Shows cascading status** - when a cascading operation is in progress, display a status indicator near the affected flow toggle. 4. **Provides a "Refresh" option** so users can re-run health checks on demand to debug configuration issues. ### Proposed UX Per-flow health check results displayed inline near each flow toggle, showing whether the flow is properly configured, specific issues detected, and actionable guidance to resolve issues. This approach was preferred over a single overarching health check widget because issues can be flow-specific.  ### Technical considerations - Complex health check queries (e.g., counting consumers) may not complete within HTTP request timeframes for large groups, so background jobs are required. - Per-flow checks should not omit general checks (e.g., `member_lock` or service account issues). - The "Developer" role check is project-specific and cannot be shown in a group-level overview. - Existing spike in !222152 provides a starting point for the implementation. ## References - Parent issue: #587127 - Related MR (spike): !222152 - Related issue: #585524 - Customer impact examples referenced in #587127