docs(fix): high-availability broken link (spinnaker#107)

Fix broken link for igor `pollingSafeguard.itemUpperThreshold`
prophen · Jul 8, 2021 · aae6712 · aae6712
1 parent bd0359b
commit aae6712
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/content/en/docs/reference/halyard/high-availability.md b/content/en/docs/reference/halyard/high-availability.md
@@ -175,7 +175,7 @@ class clouddriver-caching,clouddriver-ro,clouddriver-ro-deck,clouddriver-rw,echo
 
 ## Recoverability
 
-If you've [configured an external Redis](/docs/setup/productionize/caching/externalize-redis/), Spinnaker can recover from failure events. Igor is responsible for polling the state store (Redis) and recreating state. During a recovery, numerous old pipelines may be re-triggered. To protect against this scenario, Igor has a setting called `pollingSafeguard.itemUpperThreshold`, which is the max number of pipeline triggers to accept before recognizing the scenario of numerous old re-triggers and stopping the state update. [Read the inline documentation for this setting](https://github.com/spinnaker/igor/blob/master/igor-web/src/main/groovy/com/netflix/spinnaker/igor/IgorConfigurationProperties.groovy#L47).
+If you've [configured an external Redis](/docs/setup/productionize/caching/externalize-redis/), Spinnaker can recover from failure events. Igor is responsible for polling the state store (Redis) and recreating state. During a recovery, numerous old pipelines may be re-triggered. To protect against this scenario, Igor has a setting called `pollingSafeguard.itemUpperThreshold`, which is the max number of pipeline triggers to accept before recognizing the scenario of numerous old re-triggers and stopping the state update. [Read the inline documentation for this setting](https://github.com/spinnaker/igor/blob/22106ca4efb36d32d65650877c98425fcab77395/igor-core/src/main/java/com/netflix/spinnaker/igor/IgorConfigurationProperties.java#L86).
 
 Although it's possible, it is not recommended to use spot instances on AWS or preemtible nodes to lower cost in production, as outages in your continuous deployment tool will likely cost more than any savings. Also consider hosting Spinnaker on isolated infrastructure to reduce the possibility that other applications or teams will affect your Spinnaker instance.