diff --git a/content/en/docs/14.0/user-guides/schema-changes/table-lifecycle.md b/content/en/docs/14.0/user-guides/schema-changes/table-lifecycle.md
index 710a3c1a7..dab161895 100644
--- a/content/en/docs/14.0/user-guides/schema-changes/table-lifecycle.md
+++ b/content/en/docs/14.0/user-guides/schema-changes/table-lifecycle.md
@@ -26,17 +26,17 @@ There are two locking aspects to dropping tables:
 The exact locking behavior and duration can vary depending on
 various factors:
 
-- Which filesystem is used
-- Whether the MySQL adaptive hash index is used
+- Which filesystem is used.
+- Whether the MySQL adaptive hash index is used.
 - Whether you are attempting to hack around some of the MySQL `DROP TABLE`
-  performance problems using hard links
+  performance problems using hard links.
 
 It is common practice to avoid direct `DROP TABLE` statements and to follow
 a more elaborate table lifecycle.
 
 ## Vitess table lifecycle
 
-The lifecycle offered by Vitess consists of the following stages or some subset:
+The lifecycle offered by Vitess consists of the following stages or some subset of them:
 
 > _in use_ -> hold -> purge -> evac -> drop -> _removed_
 
@@ -68,8 +68,8 @@ All subsets end with a `drop`, even if not explicitly mentioned. Thus, `"purge"`
 
 In MySQL **8.0.23** and later, table drops do not acquire locks on the InnoDB buffer pool, and are non-blocking for queries that do not reference the table being dropped. Vitess automatically identifies whether the underlying MySQL server is at that version or later and will:
 
-- Implicitly skip `purge` state, even if defined
-- Implicitly skip `hold` state, even if defined
+- Implicitly skip the `purge` stage, even if defined
+- Implicitly skip the `evac` stage, even if defined
 
 ## Stateless flow by table name hints
 
@@ -82,7 +82,7 @@ Vitess does not track the state of the table lifecycle. The process is stateless
 
 ## Automated lifecycle
 
-Vitess internally uses the above table lifecycle for [online, managed schema migrations](../../../user-guides/schema-changes/managed-online-schema-changes/). Online schema migration tools `gh-ost` and `pt-online-schema-change` create artifact tables or end with leftover tables: Vitess automatically collects those tables. The artifact or leftover tables are immediate moved to `purge` state. Depending on `--table_gc_lifecycle`, they may spend time in this state, getting purged, or immediately transitioned to the next state.
+Vitess internally uses the above table lifecycle for [online, managed schema migrations](../../../user-guides/schema-changes/managed-online-schema-changes/). All online strategies: `vitess`, `gh-ost`, and `pt-online-schema-change`, create artifact tables or end with leftover tables: Vitess automatically collects those tables. The artifact or leftover tables are immediate moved to `hold` state. Depending on `--table_gc_lifecycle`, they may spend time in this state, getting purged, or immediately transitioned to the next state.
 
 ## User-facing DROP TABLE lifecycle
 
diff --git a/content/en/docs/15.0/user-guides/schema-changes/table-lifecycle.md b/content/en/docs/15.0/user-guides/schema-changes/table-lifecycle.md
index 710a3c1a7..dab161895 100644
--- a/content/en/docs/15.0/user-guides/schema-changes/table-lifecycle.md
+++ b/content/en/docs/15.0/user-guides/schema-changes/table-lifecycle.md
@@ -26,17 +26,17 @@ There are two locking aspects to dropping tables:
 The exact locking behavior and duration can vary depending on
 various factors:
 
-- Which filesystem is used
-- Whether the MySQL adaptive hash index is used
+- Which filesystem is used.
+- Whether the MySQL adaptive hash index is used.
 - Whether you are attempting to hack around some of the MySQL `DROP TABLE`
-  performance problems using hard links
+  performance problems using hard links.
 
 It is common practice to avoid direct `DROP TABLE` statements and to follow
 a more elaborate table lifecycle.
 
 ## Vitess table lifecycle
 
-The lifecycle offered by Vitess consists of the following stages or some subset:
+The lifecycle offered by Vitess consists of the following stages or some subset of them:
 
 > _in use_ -> hold -> purge -> evac -> drop -> _removed_
 
@@ -68,8 +68,8 @@ All subsets end with a `drop`, even if not explicitly mentioned. Thus, `"purge"`
 
 In MySQL **8.0.23** and later, table drops do not acquire locks on the InnoDB buffer pool, and are non-blocking for queries that do not reference the table being dropped. Vitess automatically identifies whether the underlying MySQL server is at that version or later and will:
 
-- Implicitly skip `purge` state, even if defined
-- Implicitly skip `hold` state, even if defined
+- Implicitly skip the `purge` stage, even if defined
+- Implicitly skip the `evac` stage, even if defined
 
 ## Stateless flow by table name hints
 
@@ -82,7 +82,7 @@ Vitess does not track the state of the table lifecycle. The process is stateless
 
 ## Automated lifecycle
 
-Vitess internally uses the above table lifecycle for [online, managed schema migrations](../../../user-guides/schema-changes/managed-online-schema-changes/). Online schema migration tools `gh-ost` and `pt-online-schema-change` create artifact tables or end with leftover tables: Vitess automatically collects those tables. The artifact or leftover tables are immediate moved to `purge` state. Depending on `--table_gc_lifecycle`, they may spend time in this state, getting purged, or immediately transitioned to the next state.
+Vitess internally uses the above table lifecycle for [online, managed schema migrations](../../../user-guides/schema-changes/managed-online-schema-changes/). All online strategies: `vitess`, `gh-ost`, and `pt-online-schema-change`, create artifact tables or end with leftover tables: Vitess automatically collects those tables. The artifact or leftover tables are immediate moved to `hold` state. Depending on `--table_gc_lifecycle`, they may spend time in this state, getting purged, or immediately transitioned to the next state.
 
 ## User-facing DROP TABLE lifecycle
 
diff --git a/content/en/docs/16.0/reference/features/tablet-throttler.md b/content/en/docs/16.0/reference/features/tablet-throttler.md
index b29541f11..71578d6b6 100644
--- a/content/en/docs/16.0/reference/features/tablet-throttler.md
+++ b/content/en/docs/16.0/reference/features/tablet-throttler.md
@@ -233,6 +233,8 @@ This API call returns the following JSON object:
   "IsLeader": true,
   "IsOpen": true,
   "IsDormant": false,
+  "Query": "select unix_timestamp(now(6))-max(ts/1000000000) as replication_lag from _vt.heartbeat",
+  "Threshold": 1,
   "AggregatedMetrics": {
     "mysql/self": {
       "Value": 0.749837
@@ -279,6 +281,8 @@ This API call returns the following JSON object:
   "IsLeader": false,
   "IsOpen": true,
   "IsDormant": false,
+  "Query": "select unix_timestamp(now(6))-max(ts/1000000000) as replication_lag from _vt.heartbeat",
+  "Threshold": 1,
   "AggregatedMetrics": {
     "mysql/self": {
       "Value": 0.346409
diff --git a/content/en/docs/16.0/user-guides/schema-changes/table-lifecycle.md b/content/en/docs/16.0/user-guides/schema-changes/table-lifecycle.md
index f5a1ca79d..dab161895 100644
--- a/content/en/docs/16.0/user-guides/schema-changes/table-lifecycle.md
+++ b/content/en/docs/16.0/user-guides/schema-changes/table-lifecycle.md
@@ -68,8 +68,8 @@ All subsets end with a `drop`, even if not explicitly mentioned. Thus, `"purge"`
 
 In MySQL **8.0.23** and later, table drops do not acquire locks on the InnoDB buffer pool, and are non-blocking for queries that do not reference the table being dropped. Vitess automatically identifies whether the underlying MySQL server is at that version or later and will:
 
-- Implicitly skip `purge` state, even if defined
-- Implicitly skip `hold` state, even if defined
+- Implicitly skip the `purge` stage, even if defined
+- Implicitly skip the `evac` stage, even if defined
 
 ## Stateless flow by table name hints
 
diff --git a/content/en/docs/17.0/reference/features/tablet-throttler.md b/content/en/docs/17.0/reference/features/tablet-throttler.md
index b29541f11..71578d6b6 100644
--- a/content/en/docs/17.0/reference/features/tablet-throttler.md
+++ b/content/en/docs/17.0/reference/features/tablet-throttler.md
@@ -233,6 +233,8 @@ This API call returns the following JSON object:
   "IsLeader": true,
   "IsOpen": true,
   "IsDormant": false,
+  "Query": "select unix_timestamp(now(6))-max(ts/1000000000) as replication_lag from _vt.heartbeat",
+  "Threshold": 1,
   "AggregatedMetrics": {
     "mysql/self": {
       "Value": 0.749837
@@ -279,6 +281,8 @@ This API call returns the following JSON object:
   "IsLeader": false,
   "IsOpen": true,
   "IsDormant": false,
+  "Query": "select unix_timestamp(now(6))-max(ts/1000000000) as replication_lag from _vt.heartbeat",
+  "Threshold": 1,
   "AggregatedMetrics": {
     "mysql/self": {
       "Value": 0.346409
diff --git a/content/en/docs/17.0/user-guides/schema-changes/table-lifecycle.md b/content/en/docs/17.0/user-guides/schema-changes/table-lifecycle.md
index f5a1ca79d..dab161895 100644
--- a/content/en/docs/17.0/user-guides/schema-changes/table-lifecycle.md
+++ b/content/en/docs/17.0/user-guides/schema-changes/table-lifecycle.md
@@ -68,8 +68,8 @@ All subsets end with a `drop`, even if not explicitly mentioned. Thus, `"purge"`
 
 In MySQL **8.0.23** and later, table drops do not acquire locks on the InnoDB buffer pool, and are non-blocking for queries that do not reference the table being dropped. Vitess automatically identifies whether the underlying MySQL server is at that version or later and will:
 
-- Implicitly skip `purge` state, even if defined
-- Implicitly skip `hold` state, even if defined
+- Implicitly skip the `purge` stage, even if defined
+- Implicitly skip the `evac` stage, even if defined
 
 ## Stateless flow by table name hints