diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md
index 3cbd427df5a8f336d7959ab0b99cb104d9a37e6c..15cbca16df5ed4eb500ddbb21e762e7f1ecc6d68 100644
--- a/doc/development/sidekiq/index.md
+++ b/doc/development/sidekiq/index.md
@@ -42,6 +42,21 @@ Sidekiq::Client.via(pool) do
 end
 ```
 
+Unrouted Sidekiq calls are caught by the validator in all API requests, Sidekiq jobs on the server-side and in tests.
+We recommend writing application logic with the use of the `Gitlab::SidekiqSharding::Router`. However, since sharding is an
+unreleased feature, if the component does not affect GitLab.com, it is acceptable run it within a `.allow_unrouted_sidekiq_calls` scope like so:
+
+```ruby
+# Add a comment explaining why it is safe to allow unrouted Sidekiq calls in this case
+Gitlab::SidekiqSharding::Validator.allow_unrouted_sidekiq_calls do
+  # your unrouted logic
+end
+```
+
+A past example is the use of `allow_unrouted_sidekiq_calls` in [Geo Rake tasks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149958#note_1906072228)
+as it does not affect GitLab.com. However, developer should write shard-aware code where possible since
+that is a pre-requisite for sharding to be [released as a feature to self-managed users](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/3430).
+
 ## Retries
 
 Sidekiq defaults to using [25 retries](https://github.com/mperham/sidekiq/wiki/Error-Handling#automatic-job-retry),