diff --git a/docs/archival/run-archival-node-without-nearup.md b/docs/archival/run-archival-node-without-nearup.md
index 5bc9a33..2df84ff 100644
--- a/docs/archival/run-archival-node-without-nearup.md
+++ b/docs/archival/run-archival-node-without-nearup.md
@@ -25,7 +25,7 @@ Running an archival node is very similar to running a [validator node](/validato
 
 ## Prerequisites {#prerequisites}
 
-- [Rust](https://www.rust-lang.org/). If not already installed, please [follow these instructions](https://docs.near.org/sdk/rust/introduction#install-rust-and-wasm-toolchain).
+- [Rust](https://www.rust-lang.org/)
 - [Git](https://git-scm.com/)
 - Installed developer tools:
   - MacOS
diff --git a/docs/troubleshooting/resharding.md b/docs/troubleshooting/resharding.md
index 7a5001a..51e57f9 100644
--- a/docs/troubleshooting/resharding.md
+++ b/docs/troubleshooting/resharding.md
@@ -54,11 +54,11 @@ You can find instructions on how to migrate to split storage on [Split Storage p
 
 #### Monitoring {#monitoring 1.37}
 To monitor resharding you can use metrics `near_resharding_status`, `near_resharding_batch_size`, and `near_resharding_batch_prepare_time_bucket`.
-You can read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding.md#monitoring).
+You can read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding_v2.md#monitoring).
 
 If you observe problems with block production or resharding performance, you can adjust resharding throttling configuration.
 This does not require a node restart, you can send a signal to the neard process to load the new config.
-Read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding.md#monitoring).
+Read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding_v2.md#monitoring).
 
 ### After resharding {#after 1.37}
 If your node failed to reshard or is not able to sync with the network after the protocol upgrade, you will need to download the latest DB snapshot provided by Pagoda from s3
diff --git a/docs/validator/running-a-node-macos-linux.md b/docs/validator/running-a-node-macos-linux.md
index 9bc31d4..6347247 100644
--- a/docs/validator/running-a-node-macos-linux.md
+++ b/docs/validator/running-a-node-macos-linux.md
@@ -179,8 +179,7 @@ Enter your account ID (leave empty if not going to be a validator):
 
 ## Running a Node on the Cloud {#running-a-node-on-the-cloud}
 
-Create a new instance following the [Hardware
-requirements](hardware-validator).
+Create a new instance following the [Hardware requirements](hardware-validator.md).
 
 Add firewall rules to allow traffic to port 24567 from all IPs
 (0.0.0.0/0).
diff --git a/docs/validator/validator-bootcamp.md b/docs/validator/validator-bootcamp.md
index f037a90..0dc97d5 100644
--- a/docs/validator/validator-bootcamp.md
+++ b/docs/validator/validator-bootcamp.md
@@ -869,7 +869,7 @@ near call {pool_id}.{staking_pool_factory} update_staking_key '{"stake_public_ke
 
 In order to get a validator seat you must first submit a proposal with an appropriate amount of stake. Proposals are sent for epoch +2. Meaning if you send a proposal now, if approved, you would get the seat in 3 epochs. You should submit a proposal every epoch to ensure your seat. To send a proposal we use the ping command. A proposal is also sent if a stake or unstake command is sent to the staking pool contract.
 
-To note, a ping also updates the staking balances for your delegators. A ping should be issued each epoch to keep reported rewards current on the pool contract. You could set up a ping using a cron job or use [Cron Cat](https://cron.cat/).
+To note, a ping also updates the staking balances for your delegators. A ping should be issued each epoch to keep reported rewards current on the pool contract. You could set up a ping using a cron job.
 
 
 Staking Pools Factories for each network: