diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 1f73ccbe3ff99..d2c7f962e79f0 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -164,7 +164,7 @@ through which the Pod has or has not passed. Kubelet manages the following
 PodConditions:
 
 * `PodScheduled`: the Pod has been scheduled to a node.
-* `PodReadyToStartContainers`: (alpha feature; must be [enabled explicitly](#pod-has-network)) the
+* `PodReadyToStartContainers`: (beta feature; enabled by [default](#pod-has-network)) the
   Pod sandbox has been successfully created and networking configured.
 * `ContainersReady`: all containers in the Pod are ready.
 * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
@@ -242,19 +242,21 @@ When a Pod's containers are Ready but at least one custom condition is missing o
 
 ### Pod network readiness {#pod-has-network}
 
-{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.29" state="beta" >}}
 
 {{< note >}}
-This condition was renamed from PodHasNetwork to PodReadyToStartContainers.
+During its early development, this condition was named `PodHasNetwork`.
 {{< /note >}}
 
-After a Pod gets scheduled on a node, it needs to be admitted by the Kubelet and
-have any volumes mounted. Once these phases are complete, the Kubelet works with
+After a Pod gets scheduled on a node, it needs to be admitted by the kubelet and
+to have any required storage volumes mounted. Once these phases are complete,
+the kubelet works with
 a container runtime (using {{< glossary_tooltip term_id="cri" >}}) to set up a
 runtime sandbox and configure networking for the Pod. If the
-`PodReadyToStartContainersCondition` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
-Kubelet reports whether a pod has reached this initialization milestone through
-the `PodReadyToStartContainers` condition in the `status.conditions` field of a Pod.
+`PodReadyToStartContainersCondition`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled
+(it is enabled by default for Kubernetes {{< skew currentVersion >}}), the
+`PodReadyToStartContainers` condition will be added to the `status.conditions` field of a Pod.
 
 The `PodReadyToStartContainers` condition is set to `False` by the Kubelet when it detects a
 Pod does not have a runtime sandbox with networking configured. This occurs in
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
index 6fd45b731d477..32201947ef62b 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -169,7 +169,8 @@ For a reference to old feature gates that are removed, please refer to
 | `PodHostIPs` | `false` | Alpha | 1.28 | |
 | `PodIndexLabel` | `true` | Beta | 1.28 | |
 | `PodLifecycleSleepAction` | `false` | Alpha | 1.29 | |
-| `PodReadyToStartContainersCondition` | `false` | Alpha | 1.28 | |
+| `PodReadyToStartContainersCondition` | `false` | Alpha | 1.28 | 1.28 |
+| `PodReadyToStartContainersCondition` | `true` | Beta | 1.29 | |
 | `PodSchedulingReadiness` | `false` | Alpha | 1.26 | 1.26 |
 | `PodSchedulingReadiness` | `true` | Beta | 1.27 | |
 | `ProcMountType` | `false` | Alpha | 1.12 | |