diff --git a/src/content/docs/magic-transit/how-to/bgp-peering.mdx b/src/content/docs/magic-transit/how-to/bgp-peering.mdx
index f4e46a77b1532f8..654603ec16020e0 100644
--- a/src/content/docs/magic-transit/how-to/bgp-peering.mdx
+++ b/src/content/docs/magic-transit/how-to/bgp-peering.mdx
@@ -13,7 +13,7 @@ import { Render } from "~/components"
 	params={{
 		productName: "Magic Transit",
 		productPath: "/magic-transit/reference/tunnel-health-checks/",
-		legacyHCs: "/magic-transit/reference/tunnel-health-checks/#legacy-health-checks-system",
+		legacyHCs: "/magic-transit/reference/tunnel-health-checks/#legacy-bidirectional-health-checks",
 		asnProduct: "<br /> Magic Transit customers should also be aware of the following: <br /> <ul><li>The Cloudflare side ASN will never be exposed in <code>AS_PATH</code> of anycast announcements from the Cloudflare edge. In those announcements, Cloudflare will always use the Cloudflare ASN of <code>13335</code> optionally prepended with a bring-your-own ASN as described in [Cloudflare ASN vs. your own ASN](/magic-transit/how-to/advertise-prefixes/#cloudflare-asn-vs-your-own-asn)</li><li>The customer device ASN can be a private ASN or the ASN they are using for Magic Transit anycast announcements at the edge: this has no impact on the ASN for the anycast announced prefix at the edge of the Cloudflare global network.</li></ul>",
 		mtLimitations: "<br /> For Magic Transit customers, BGP with the Magic routing table is separated from the announcement of anycast prefixes at the Cloudflare edge. Anycast withdrawal must be controlled with existing methods documented in [Advertise prefixes](/magic-transit/how-to/advertise-prefixes/).",
 		productGatewayOrEgress: "Magic Transit with Egress"
diff --git a/src/content/docs/magic-transit/how-to/configure-tunnels.mdx b/src/content/docs/magic-transit/how-to/configure-tunnels.mdx
index 59fd946e03152c1..4eeb25352adce96 100644
--- a/src/content/docs/magic-transit/how-to/configure-tunnels.mdx
+++ b/src/content/docs/magic-transit/how-to/configure-tunnels.mdx
@@ -74,7 +74,7 @@ import { GlossaryTooltip, Render } from "~/components";
 
 <Render file="tunnel-endpoints/mt-egress" />
 
-### Legacy health checks system
+### Legacy bidirectional health checks
 
 <Render file="legacy-hc-system" />
 
diff --git a/src/content/docs/magic-wan/configuration/manually/how-to/bgp-peering.mdx b/src/content/docs/magic-wan/configuration/manually/how-to/bgp-peering.mdx
index 5553e3073e947db..9e7a129a572af3e 100644
--- a/src/content/docs/magic-wan/configuration/manually/how-to/bgp-peering.mdx
+++ b/src/content/docs/magic-wan/configuration/manually/how-to/bgp-peering.mdx
@@ -13,7 +13,7 @@ import { Render } from "~/components"
 	params={{
 		productName: "Magic WAN",
 		productPath: "/magic-wan/reference/tunnel-health-checks/",
-		legacyHCs: "/magic-wan/reference/tunnel-health-checks/#legacy-health-checks-system",
+		legacyHCs: "/magic-wan/reference/tunnel-health-checks/#legacy-bidirectional-health-checks",
 		asnProduct: "<br /> Magic WAN customers should also be aware of the following: <br /> <ul><li>The Cloudflare side ASN will be included in the <code>AS_PATH</code> of announced routes to any BGP enabled interconnect.</li><li>The customer chooses their device ASN, which should be different to the Cloudflare-side ASN.</li></ul>",
 		mtLimitations: " ",
 		productGatewayOrEgress: "Magic WAN with Gateway"
diff --git a/src/content/docs/magic-wan/configuration/manually/how-to/configure-tunnels.mdx b/src/content/docs/magic-wan/configuration/manually/how-to/configure-tunnels.mdx
index 638d0d0cfbdc633..4d60c5e8c555ad6 100644
--- a/src/content/docs/magic-wan/configuration/manually/how-to/configure-tunnels.mdx
+++ b/src/content/docs/magic-wan/configuration/manually/how-to/configure-tunnels.mdx
@@ -81,7 +81,7 @@ import { GlossaryTooltip, Render } from "~/components";
 	params={{ productPathProbe: "/magic-wan/reference/tunnel-health-checks/" }}
 />
 
-### Legacy health checks system
+### Legacy bidirectional health checks
 
 <Render file="legacy-hc-system" product="magic-transit" />
 
diff --git a/src/content/docs/magic-wan/network-interconnect.mdx b/src/content/docs/magic-wan/network-interconnect.mdx
index 12ffa7253cebeab..ef8a960719c9a83 100644
--- a/src/content/docs/magic-wan/network-interconnect.mdx
+++ b/src/content/docs/magic-wan/network-interconnect.mdx
@@ -22,7 +22,7 @@ With Direct CNI you can also setup BGP peering between your network and Cloudfla
 
 ### Bidirectional health checks
 
-Bidirectional health checks do not work when you use Direct CNI to onboard your traffic to Cloudflare. You will need to resort to the [legacy health check system](/magic-wan/configuration/manually/how-to/configure-tunnels/#legacy-health-checks-system).
+Bidirectional health checks do not work when you use Direct CNI to onboard your traffic to Cloudflare. You will need to resort to the [legacy health check system](/magic-wan/configuration/manually/how-to/configure-tunnels/#legacy-bidirectional-health-checks).
 
 :::note
 Do not use Magic WAN Connector with Direct CNI. You can use the Connector with a [Public Peering or a Private Network Interconnection (PNI)](/network-interconnect/pni-and-peering/) if needed.
diff --git a/src/content/partials/magic-transit/legacy-hc-system.mdx b/src/content/partials/magic-transit/legacy-hc-system.mdx
index 5b91584842f73cf..fd8729843f5f512 100644
--- a/src/content/partials/magic-transit/legacy-hc-system.mdx
+++ b/src/content/partials/magic-transit/legacy-hc-system.mdx
@@ -3,7 +3,7 @@
 
 ---
 
-For customers using the legacy health check system with a public IP range, Cloudflare recommends that:
+For customers using the legacy health check system with a public IP range, Cloudflare recommends:
 
-1. You configure the IP address for your tunnel health check target to be one from within the prefix range `172.64.240.252/30`.
-2. Apply a policy-based route that matches packets with source IP address equal to the configured tunnel health check target (for example  `172.64.240.253/32`), and route them over the tunnel back to Cloudflare.
+- Configuring the tunnel health check target IP address to one within the `172.64.240.252/30` prefix range.
+- Applying a policy-based route that matches packets with a source IP address equal to the configured tunnel health check target (for example `172.64.240.253/32`), and route them over the tunnel back to Cloudflare.