diff --git a/src/ripple/app/misc/FeeEscalation.md b/src/ripple/app/misc/FeeEscalation.md
index 30f4dc2784e..b86f8dab945 100644
--- a/src/ripple/app/misc/FeeEscalation.md
+++ b/src/ripple/app/misc/FeeEscalation.md
@@ -190,11 +190,27 @@ lower) fee to get into the same position as a reference transaction.
 
 ### Consensus Health
 
-For consensus to be considered healthy, the consensus process must take
-less than 5 seconds. This time limit was chosen based on observed past
-behavior of the network. Note that this is not necessarily the time between
-ledger closings, as consensus usually starts some amount of time after
-a ledger opens.
+For consensus to be considered healthy, the peers on the network
+should largely remain in sync with one another. It is particularly
+important for the validators to remain in sync, because that is required
+for participation in consensus. However, the network tolerates some
+validators being out of sync.  Fundamentally, network health is a
+function of validators reaching consensus on sets of recently submitted
+transactions.
+
+Another factor to consider is
+the duration of the consensus process itself. This generally takes
+under 5 seconds on the main network under low volume. This is based on
+historical observations. However factors such as transaction volume
+can increase consensus duration. This is because rippled performs
+more work as transaction volume increases. Under sufficient load this
+tends to increase consensus duration. It's possible that relatively high
+consensus duration indicates a problem, but it is not appropriate to
+conclude so without investigation. The upper limit for consensus
+duration should be roughly 20 seconds. That is far above the normal.
+If the network takes this long to close ledgers, then it is almost
+certain that there is a problem with the network. This circumstance
+often coincides with new ledgers with zero transactions.
 
 ### Other Constants