diff --git a/docs/contrib.rst b/docs/contrib.rst
index 7332f155..af649404 100644
--- a/docs/contrib.rst
+++ b/docs/contrib.rst
@@ -56,9 +56,3 @@ all the time.
 
 You may also use both of them. To use these checks add them to `INSTALLED_APPS` in your
 Django settings module.
-
-`cache`
--------
-
-The key `djangohealtcheck_test` will be written to the cache backend to validate that the cache is working.  
-The name of the key can be customized by setting `HEALTHCHECK_CACHE_KEY` to another value.
diff --git a/docs/settings.rst b/docs/settings.rst
index f17c1dbc..43f3eb24 100644
--- a/docs/settings.rst
+++ b/docs/settings.rst
@@ -42,6 +42,24 @@ You can still use any uptime bot that is URL based while enjoying token protecti
     Do NOT use Django's `SECRET_KEY` setting. This should never be exposed,
     to any third party. Not even your trusted uptime bot.
 
+`cache`
+-------
+
+The cache backend uses the following setting:
+
+.. list-table::
+   :widths: 25 10 10 55
+   :header-rows: 1
+
+   * - Name
+     - Type
+     - Default
+     - Description
+   * - `HEALTHCHECK_CACHE_KEY`
+     - String
+     - `djangohealthcheck_test`
+     - Specifies the name of the key to write to and read from to validate that the cache is working.
+
 `psutil`
 --------
 
@@ -83,10 +101,6 @@ Using `django.settings` you may exert more fine-grained control over the behavio
      - Type
      - Default
      - Description
-   * - `HEALTHCHECK_CACHE_KEY`
-     - String
-     - `djangohealtcheck_test`
-     - Specifies the name of the key to write to and read from to validate that the cache is working.
    * - `HEALTHCHECK_CELERY_QUEUE_TIMEOUT`
      - Number
      - `3`