diff --git a/docs/release/release-team-onboarding.md b/docs/release/release-team-onboarding.md
index a20c583543fe..33b0d07545d2 100644
--- a/docs/release/release-team-onboarding.md
+++ b/docs/release/release-team-onboarding.md
@@ -55,7 +55,7 @@ Now, let's dive into the specific onboarding notes for each sub-team below.
- Start by gaining a general understanding of GitHub labels and how to find issues and pull requests for the current milestone.
- Familiarize yourself with Prow commands: The Cluster API project utilizes [Prow](https://docs.prow.k8s.io/docs/overview/) to manage CI automation. Issues and PRs are categorized by applying specific list of area labels, which helps in prioritization of that specific issue/PR during the release cycle or release process. Learn more about the available [labels](https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md#labels-that-apply-to-kubernetes-sigscluster-api-for-both-issues-and-prs) and prow [commands](https://prow.k8s.io/command-help).
-- Take a look at [TestGrid](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api#Summary), an interactive dashboard for visualizing the CI job results of the project in a grid format!
+- Take a look at [TestGrid](https://testgrid.k8s.io/cluster-api-core) for a high level overview of `main` and the supported release branches' testing status. Drill into one of the links for an interactive dashboard visualizing the CI job results of that branch in a grid format!
- Examine the [CI jobs](https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes-sigs/cluster-api) in the test-infra repository. These jobs are defined in YAML and represent various job types, such as periodics and presubmits, that we run in the project.
- Explore [k8s-triage](https://storage.googleapis.com/k8s-triage/index.html?job=periodic-cluster-api-*), a tool that identifies groups of similar test failures across all jobs.
- Experiment with running [end-to-end tests](https://cluster-api.sigs.k8s.io/developer/core/testing#running-the-end-to-end-tests-locally) on your local machine to gain a better understanding of the tests and build a confidence debugging CI issues.
\ No newline at end of file
diff --git a/docs/release/role-handbooks/ci-signal/README.md b/docs/release/role-handbooks/ci-signal/README.md
index 3808d23ce724..6c6512ae5dec 100644
--- a/docs/release/role-handbooks/ci-signal/README.md
+++ b/docs/release/role-handbooks/ci-signal/README.md
@@ -45,7 +45,7 @@ While we add test coverage for the new release branch we will also drop the test
```sh
TEST_INFRA_DIR=../../k8s.io/test-infra make generate-test-infra-prowjobs
```
-6. Verify the jobs and dashboards a day later by taking a look at: `https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api-1.8`
+6. Verify the jobs and dashboards a day later by taking a look at the relevant release branch: `https://testgrid.k8s.io/cluster-api-core`
Prior art:
@@ -58,7 +58,7 @@ The goal of this task is to keep our tests running in CI stable.
**Note**: To be very clear, this is not meant to be an on-call role for Cluster API tests.
1. Add yourself to the [Cluster API alert mailing list](https://github.com/kubernetes/k8s.io/blob/151899b2de933e58a4dfd1bfc2c133ce5a8bbe22/groups/sig-cluster-lifecycle/groups.yaml#L20-L35)
-
**Note**: An alternative to the alert mailing list is manually monitoring the [testgrid dashboards](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api)
+
**Note**: An alternative to the alert mailing list is manually monitoring the [testgrid dashboards](https://testgrid.k8s.io/cluster-api-core)
(also dashboards of previous releases). Using the alert mailing list has proven to be a lot less effort though.
2. Subscribe to `CI Activity` notifications for the Cluster API repo.
3. Check the existing **failing-test** and **flaking-test** issue templates under `.github/ISSUE_TEMPLATE/` folder of the repo, used to create an issue for failing or flaking tests respectively. Please make sure they are up-to-date and if not, send a PR to update or improve them.