<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=433072) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=433072) </details> <!--IssueSummary end--> ### About Imports can potentially cause, or exasperate, incidents relating to the database due to the high number of writes or reads they perform. Sidekiq workers can be [deferred if the database tables they use are unhealthy](https://docs.gitlab.com/ee/development/sidekiq/#deferring-sidekiq-workers). We implemented this for ~"Importer:Direct Transfer" in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/136137. ### Proposal In the case of GitHub, we probably only need to consider our writes (I think these workers are the ones that include `ObjectImporter`) to have the potential to be problematic and apply `defer_on_database_health_signal` to them. The workers could define which tables they write to, and `ObjectImporter` could hook that up to `defer_on_database_health_signal`. Ideally, this should be implemented change behind a feature flag so we can start working on the task even before https://gitlab.com/gitlab-org/gitlab/-/issues/433196 is completed. We will need to wait for https://gitlab.com/gitlab-org/gitlab/-/issues/433196 to be finished before we can enable the feature flag.