--- a/xml/en/docs/http/ngx_http_upstream_hc_module.xml
+++ b/xml/en/docs/http/ngx_http_upstream_hc_module.xml
@@ -9,7 +9,7 @@
 <module name="Module ngx_http_upstream_hc_module"
         link="/en/docs/http/ngx_http_upstream_hc_module.html"
         lang="en"
-        rev="1">
+        rev="2">
 
 <section id="summary">
 
@@ -18,6 +18,25 @@ The <literal>ngx_http_upstream_hc_module
 allows enabling periodic health checks of the servers in a
 <link doc="ngx_http_upstream_module.xml" id="upstream">group</link>
 referenced in the surrounding location.
+The server group must reside in the
+<link doc="ngx_http_upstream_module.xml" id="zone">shared memory</link>.
+</para>
+
+<para>
+If a health check fails,
+the server will be considered unhealthy.
+If several health checks are defined for the same group of servers,
+a single failure of any check will make the corresponding server be
+considered unhealthy.
+Client requests are not passed to unhealthy servers
+and servers in the “checking” state.
+</para>
+
+<para>
+<note>
+Please note that most of the variables will have empty values
+when used with health checks.
+</note>
 </para>
 
 <para>
@@ -52,6 +71,41 @@ server {
     }
 }
 </example>
+With this configuration, nginx will send “<literal>/</literal>” requests to each
+server in the <literal>backend</literal> group every five seconds.
+If any communication error or timeout occurs, or a
+proxied server responds with the status code other than
+2xx or 3xx, the health check will fail, and the server will
+be considered unhealthy.
+</para>
+
+<para>
+Health checks can be configured to test the status code of a response,
+presence of certain header fields and their values,
+and the body contents.
+Tests are configured separately using the <link id="match"/> directive
+and referenced in the <literal>match</literal> parameter
+of the  <link id="health_check"/> directive:
+<example>
+http {
+    server {
+    ...
+        location / {
+            proxy_pass http://backend;
+            health_check match=welcome;
+        }
+    }
+
+    match welcome {
+        status 200;
+        header Content-Type = text/html;
+        body ~ "Welcome to nginx!";
+    }
+}
+</example>
+This configuration shows that in order for a health check to pass, the response
+to a health check request should succeed, have status 200,
+and contain “<literal>Welcome to nginx!</literal>” in the body.
 </para>
 
 </section>
@@ -149,72 +203,6 @@ By default, equals the
 </list>
 </para>
 
-<para>
-For example,
-<example>
-location / {
-    proxy_pass http://backend;
-    health_check;
-}
-</example>
-will send “<literal>/</literal>” requests to each
-server in the <literal>backend</literal> group every five seconds.
-If any communication error or timeout occurs, or a
-proxied server responds with the status code other than
-2xx or 3xx, the health check will fail, and the server will
-be considered unhealthy.
-Client requests are not passed to unhealthy servers
-and servers in the “checking” state.
-</para>
-
-<para>
-Health checks can be configured to test the status code of a response,
-presence of certain header fields and their values,
-and the body contents.
-Tests are configured separately using the <link id="match"/> directive
-and referenced in the <literal>match</literal> parameter.
-For example:
-<example>
-http {
-    server {
-    ...
-        location / {
-            proxy_pass http://backend;
-            health_check match=welcome;
-        }
-    }
-
-    match welcome {
-        status 200;
-        header Content-Type = text/html;
-        body ~ "Welcome to nginx!";
-    }
-}
-</example>
-This configuration shows that in order for a health check to pass, the response
-to a health check request should succeed,
-have status 200, content type “<literal>text/html</literal>”,
-and contain “<literal>Welcome to nginx!</literal>” in the body.
-</para>
-
-<para>
-The server group must reside in the
-<link doc="ngx_http_upstream_module.xml" id="zone">shared memory</link>.
-</para>
-
-<para>
-If several health checks are defined for the same group of servers,
-a single failure of any check will make the corresponding server be
-considered unhealthy.
-</para>
-
-<para>
-<note>
-Please note that most of the variables will have empty values
-when used with health checks.
-</note>
-</para>
-
 </directive>
 
 

--- a/xml/ru/docs/http/ngx_http_upstream_hc_module.xml
+++ b/xml/ru/docs/http/ngx_http_upstream_hc_module.xml
@@ -9,7 +9,7 @@
 <module name="Модуль ngx_http_upstream_hc_module"
         link="/ru/docs/http/ngx_http_upstream_hc_module.html"
         lang="ru"
-        rev="1">
+        rev="2">
 
 <section id="summary">
 
@@ -18,6 +18,25 @@
 позволяет активировать периодические проверки работоспособности серверов в
 <link doc="ngx_http_upstream_module.xml" id="upstream">группе</link>,
 указанной в содержащем location.
+Группа должна находиться в
+<link doc="ngx_http_upstream_module.xml" id="zone">зоне разделяемой памяти</link>.
+</para>
+
+<para>
+Если проверка работоспособности была неуспешной,
+то сервер признаётся неработоспособным.
+Если для группы задано несколько проверок,
+то при любой неуспешной проверке соответствующий сервер будет
+считаться неработоспособным.
+На неработоспособные серверы и серверы в состоянии “checking”
+клиентские запросы передаваться не будут.
+</para>
+
+<para>
+<note>
+Обратите внимание, что при использовании проверок
+большинство переменных имеют пустые значения.
+</note>
 </para>
 
 <para>
@@ -52,6 +71,41 @@ server {
     }
 }
 </example>
+Каждому серверу группы <literal>backend</literal>
+с интервалом в 5 секунд посылаются запросы “<literal>/</literal>”.
+Если происходит ошибка или таймаут при работе с сервером, или
+код ответа проксируемого сервера не равен
+2xx или 3xx, проверка считается неуспешной и сервер
+признаётся неработоспособным.
+</para>
+
+<para>
+Проверки работоспособности могут тестировать код ответа,
+наличие или отсутствие определённых полей заголовка и их значений,
+а также содержимое тела ответа.
+Тесты настраиваются отдельно при помощи директивы <link id="match"/>
+и указываются в параметре <literal>match</literal>.
+Например:
+<example>
+http {
+    server {
+    ...
+        location / {
+            proxy_pass http://backend;
+            health_check match=welcome;
+        }
+    }
+
+    match welcome {
+        status 200;
+        header Content-Type = text/html;
+        body ~ "Welcome to nginx!";
+    }
+}
+</example>
+В такой конфигурации успешный ответ на проверочный запрос
+должен иметь код 200, тип содержимого “<literal>text/html</literal>”
+и “<literal>Welcome to nginx!</literal>” в теле ответа.
 </para>
 
 </section>
@@ -149,71 +203,6 @@ server {
 </list>
 </para>
 
-<para>
-В примере
-<example>
-location / {
-    proxy_pass http://backend;
-    health_check;
-}
-</example>
-каждому серверу группы <literal>backend</literal>
-с интервалом в 5 секунд посылаются запросы “<literal>/</literal>”.
-Если происходит ошибка или таймаут при работе с сервером, или
-код ответа проксируемого сервера не равен
-2xx или 3xx, проверка считается неуспешной и сервер
-признаётся неработоспособным.
-На неработоспособные серверы и серверы в состоянии “checking”
-клиентские запросы передаваться не будут.
-</para>
-
-<para>
-Проверки работоспособности могут тестировать код ответа,
-наличие или отсутствие определённых полей заголовка и их значений,
-а также содержимое тела ответа.
-Тесты настраиваются отдельно при помощи директивы <link id="match"/>
-и указываются в параметре <literal>match</literal>.
-Например:
-<example>
-http {
-    server {
-    ...
-        location / {
-            proxy_pass http://backend;
-            health_check match=welcome;
-        }
-    }
-
-    match welcome {
-        status 200;
-        header Content-Type = text/html;
-        body ~ "Welcome to nginx!";
-    }
-}
-</example>
-В такой конфигурации успешный ответ на проверочный запрос
-должен иметь код 200, тип содержимого “<literal>text/html</literal>”
-и “<literal>Welcome to nginx!</literal>” в теле ответа.
-</para>
-
-<para>
-Группа должна находиться в
-<link doc="ngx_http_upstream_module.xml" id="zone">зоне разделяемой памяти</link>.
-</para>
-
-<para>
-Если для группы задано несколько проверок,
-то при любой неуспешной проверке соответствующий сервер будет
-считаться неработоспособным.
-</para>
-
-<para>
-<note>
-Обратите внимание, что при использовании проверок
-большинство переменных имеют пустые значения.
-</note>
-</para>
-
 </directive>