Edit Admin Area's *Health Check* content for SSOT

doc/user/admin_area/monitoring/health_check.md

-# Health Check
+---
+type: concepts, howto
+---
 
-> **Notes:**
+# Health Check
 
+> NOTE: **Note:**
+>
 >   - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1.
 >   - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and was
 >     be deprecated in GitLab 9.1.
 >   - [Access token](#access-token-deprecated) has been deprecated in GitLab 9.4
->     in favor of [IP whitelist](#ip-whitelist)
+>     in favor of [IP whitelist](#ip-whitelist).
 
 GitLab provides liveness and readiness probes to indicate service health and
 reachability to required services. These probes report on the status of the
@@ -17,8 +21,7 @@ traffic until the system is ready or restart the container as needed.
 ## IP whitelist
 
 To access monitoring resources, the requesting client IP needs to be included in a whitelist.
-
-[Read how to add IPs to a whitelist for the monitoring endpoints][admin].
+For details, see [how to add IPs to a whitelist for the monitoring endpoints](../../../administration/monitoring/ip_whitelist.md).
 
 ## Using the endpoints
 
@@ -87,9 +90,8 @@ will return a valid successful HTTP status code, and a `success` message.
 
 ## Access token (Deprecated)
 
->**Note:**
-Access token has been deprecated in GitLab 9.4
-in favor of [IP whitelist](#ip-whitelist)
+> NOTE: **Note:**
+> Access token has been deprecated in GitLab 9.4 in favor of [IP whitelist](#ip-whitelist).
 
 An access token needs to be provided while accessing the probe endpoints. The current
 accepted token can be found under the **Admin area ➔ Monitoring ➔ Health check**
@@ -103,10 +105,21 @@ The access token can be passed as a URL parameter:
 https://gitlab.example.com/-/readiness?token=ACCESS_TOKEN
 ```
 
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
+
 [ce-10416]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10416
 [ce-3888]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3888
 [pingdom]: https://www.pingdom.com
 [nagios-health]: https://nagios-plugins.org/doc/man/check_http.html
 [newrelic-health]: https://docs.newrelic.com/docs/alerts/alert-policies/downtime-alerts/availability-monitoring
 [kubernetes]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
\ No newline at end of file
-[admin]: ../../../administration/monitoring/ip_whitelist.md