diff --git a/docs/dcc-options.md b/docs/dcc-options.md
index 87a3805..50d06f0 100644
--- a/docs/dcc-options.md
+++ b/docs/dcc-options.md
@@ -23,6 +23,8 @@ Set to YES or NO to enable email alerts. This requires email options to be preco
 ### DC_MAXCELLS_WEBEDIT
 By default, a maximum of 200,000 cells (observations multiplied by variables) can be edited in the browser at one time.  This limit is applied together with [DC_MAXOBS_WEBEDIT](#dc_maxobs_webedit) - whichever is reached first.
 
+A selection over either limit is served truncated: the grid carries the rows that fit, and a warning triangle next to the table name names the limit that was reached.  Filter the table to see the rest.
+
 The cell count matters because the cost of an EDIT screen load tracks the number of cells, not the number of rows.  A 10 column table is comfortable at 250 rows, but 250 rows of a 1000 column table is 250,000 cells.
 
 ### DC_MAXOBS_WEBEDIT
diff --git a/docs/developer-guide/filter-pre-edit-hook.md b/docs/developer-guide/filter-pre-edit-hook.md
index 2ee4a59..5d48f94 100644
--- a/docs/developer-guide/filter-pre-edit-hook.md
+++ b/docs/developer-guide/filter-pre-edit-hook.md
@@ -144,9 +144,9 @@ The captures below are the editor for a table with an `ORDER_DATE` column, opene
 
 The user's clause and Data Controller's clause have to be kept apart, because Row Level Security lives in the second one. Combining them as `( user OR previous-quarter ) AND ( validity + RLS )` keeps RLS applied to both branches. Wrapping the whole existing filter instead - `( existing OR previous-quarter )` - would let the previous-quarter rows through without their RLS condition, so do not take that shortcut.
 
-## The row cap
+## The row and cell caps
 
-`getdata` refuses a result larger than `DC_MAXOBS_WEBEDIT` (500 by default) with *Table is too big*. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap. Check the count before handing the data back, or raise the option for that table in `MPE_CONFIG`.
+`getdata` truncates a result over either `DC_MAXOBS_WEBEDIT` or `DC_MAXCELLS_WEBEDIT`, whichever binds first - a wide table runs out of cells before rows, at floor(cells / columns) rows - and warns against the table name. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap: the rows past the limit never reach the browser. Check both counts before handing the data back, or raise the options for that table in `MPE_CONFIG`.
 
 ## Matching the filter chips
 
diff --git a/docs/developer-guide/two-rule-sets-one-table.md b/docs/developer-guide/two-rule-sets-one-table.md
index e42ef8a..ebc3196 100644
--- a/docs/developer-guide/two-rule-sets-one-table.md
+++ b/docs/developer-guide/two-rule-sets-one-table.md
@@ -109,7 +109,7 @@ From that moment the changeset is an approval against `ORDERS.ORDERS`. The appro
 ### Other things to watch
 
 - Concurrency behaves correctly here. Both mirrors route their submit to the same base table, so every approval locks, loads and logs against one identity - unlike the two-libref route above.
-- The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` cap will stop the edit screen with "Table is too big". [Updating the Filter in a Pre-Edit Hook](/developer-guide/filter-pre-edit-hook/) works through extending that filter.
+- The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` or `DC_MAXCELLS_WEBEDIT` cap truncates the edit screen, with a warning against the table name. [Updating the Filter in a Pre-Edit Hook](/developer-guide/filter-pre-edit-hook/) works through extending that filter.
 - The hook's output must have the same columns the editor expects - the real table, minus any transaction or processing columns that Data Controller drops on load.
 - The real table must itself be registered in `MPE_TABLES`. The approval screen resolves the table's audit settings from that row, so a changeset routed to a table with no registration cannot be reviewed - the submit is refused up front, naming the table.
 - The mirror's `MPE_TABLES` row is read for the edit screen and the real table's for the load, so keep their `buskey`, `loadtype` and temporal column settings identical.