diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index f0be3a6b141119aa2b7b927f63cd679138d430b2..e41d258bec6777d820007a8ce630fa9a88698f52 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -12,6 +12,7 @@ status of the migration.
 Gitaly makes heavy use of [feature flags](feature_flags.md).
 
 Each Rugged-to-Gitaly migration goes through a [series of phases](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/MIGRATION_PROCESS.md):
+
 * **Opt-In**: by default the Rugged implementation is used.
   * Production instances can choose to enable the Gitaly endpoint by enabling the feature flag.
   * For testing purposes, you may wish to enable all feature flags by default. This can be done by exporting the following
@@ -19,7 +20,7 @@ Each Rugged-to-Gitaly migration goes through a [series of phases](https://gitlab
   * On developer instances (ie, when `Rails.env.development?` is true), the Gitaly endpoint
     is enabled by default, but can be _disabled_ using feature flags.
 * **Opt-Out**: by default, the Gitaly endpoint is used, but the feature can be explicitly disabled using the feature flag.
-* **Madatory**: The migration is complete and cannot be disabled. The old codepath is removed.
+* **Mandatory**: The migration is complete and cannot be disabled. The old codepath is removed.
 
 ### Enabling and Disabling Feature
 
@@ -49,6 +50,35 @@ If your test-suite is failing with Gitaly issues, as a first step, try running:
 rm -rf tmp/tests/gitaly
 ```
 
+## `TooManyInvocationsError` errors
+
+During development and testing, you may experience `Gitlab::GitalyClient::TooManyInvocationsError` failures. 
+The `GitalyClient` will attempt to block against potential n+1 issues by raising this error 
+when Gitaly is called more than 30 times in a single Rails request or Sidekiq execution.
+
+As a temporary measure, export `GITALY_DISABLE_REQUEST_LIMITS=1` to suppress the error. This will disable the n+1 detection
+in your development environment.
+
+Please raise an issue in the GitLab CE or EE repositories to report the issue. Include the labels ~Gitaly
+~performance ~"technical debt". Please ensure that the issue contains the full stack trace and error message of the
+`TooManyInvocationsError`. Also include any known failing tests if possible.
+
+Isolate the source of the n+1 problem. This will normally be a loop that results in Gitaly being called for each
+element in an array. If you are unable to isolate the problem, please contact a member 
+of the [Gitaly Team](https://gitlab.com/groups/gl-gitaly/group_members) for assistance.
+
+Once the source has been found, wrap it in an `allow_n_plus_1_calls` block, as follows:
+
+```ruby
+# n+1: link to n+1 issue
+Gitlab::GitalyClient.allow_n_plus_1_calls do
+  # original code
+  commits.each { |commit| ... }
+end
+```
+
+Once the code is wrapped in this block, this code-path will be excluded from n+1 detection.
+
 ---
 
 [Return to Development documentation](README.md)
diff --git a/lib/gitlab/gitaly_client.rb b/lib/gitlab/gitaly_client.rb
index 955d2307f88bf8584293010170e072ed3337bc1b..e75e0500ed84489f52c05fcae8ac2c01dababb31 100644
--- a/lib/gitlab/gitaly_client.rb
+++ b/lib/gitlab/gitaly_client.rb
@@ -151,7 +151,7 @@ module Gitlab
       actual_call_count = increment_call_count("gitaly_#{call_site}_actual")
 
       # Do no enforce limits in production
-      return if Rails.env.production?
+      return if Rails.env.production? || ENV["GITALY_DISABLE_REQUEST_LIMITS"]
 
       # Check if this call is nested within a allow_n_plus_1_calls
       # block and skip check if it is