Cross link between server hooks, system hooks, and file hooks

doc/administration/file_hooks.md

@@ -7,10 +7,8 @@ type: reference
 
 # File hooks **(FREE SELF)**
 
-> Renamed feature from Plugins to File hooks in GitLab 12.8.
-
-With custom file hooks, GitLab administrators can introduce custom integrations
-without modifying the GitLab source code.
+Use custom file hooks (not to be confused with [server hooks](server_hooks.md) or [system hooks](system_hooks.md)),
+to introduce custom integrations without modifying the GitLab source code.
 
 A file hook runs on each event. You can filter events or projects
 in a file hook's code, and create many file hooks as you need. Each file hook is

doc/administration/server_hooks.md

@@ -9,7 +9,8 @@ disqus_identifier: 'https://docs.gitlab.com/ee/administration/custom_hooks.html'
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/196051) in GitLab 12.8 replacing Custom Hooks.
 
-Server hooks run custom logic on the GitLab server. Users can use them to run Git-related tasks such as:
+Server hooks (not to be confused with [system hooks](system_hooks.md) or [file hooks](file_hooks.md)) run custom logic
+on the GitLab server. You can use them to run Git-related tasks such as:
 
 - Enforcing specific commit policies.
 - Performing tasks based on the state of the repository.

doc/administration/system_hooks.md

@@ -7,7 +7,8 @@ type: reference
 
 # System hooks **(FREE SELF)**
 
-Your GitLab instance can perform HTTP POST requests on the following events:
+System hooks (not to be confused with [server hooks](server_hooks.md) or [file hooks](file_hooks.md)) perform HTTP POST
+requests and are triggered on the following events:
 
 - `group_create`
 - `group_destroy`
@@ -31,21 +32,18 @@ Your GitLab instance can perform HTTP POST requests on the following events:
 - `user_update_for_group`
 - `user_update_for_team`
 
-The triggers for most of these are self-explanatory, but `project_update` and
-`project_rename` deserve some clarification: `project_update` is fired any time
-an attribute of a project is changed (including name, description, and tags)
-_unless_ the `path` attribute is also changed. In that case, a `project_rename`
-is triggered instead (so that, for instance, if all you care about is the
-repository URL, you can just listen for `project_rename`).
+The triggers for most of these are self-explanatory, but `project_update` and `project_rename` require clarification:
 
-`user_failed_login` is sent whenever a _blocked_ user attempts to sign in and is
-denied access.
+- `project_update` triggers when an attribute of a project is changed (including name, description, and tags)
+  **except** when the `path` attribute is also changed.
+- `project_rename` triggers when an attribute of a project (including `path`) is changed. If you only care about the
+  repository URL, just listen for `project_rename`.
 
-System hooks can be used, for example, for logging or changing information in an
-LDAP server.
+`user_failed_login` is sent whenever a **blocked** user attempts to sign in and is denied access.
 
-In addition to these default events, you can enable triggers for other events,
-such as push events, and disable the `repository_update` event
+As an example, use system hooks for logging or changing information in an LDAP server.
+
+You can also enable triggers for other events, such as push events, and disable the `repository_update` event
 when you create a system hook.
 
 NOTE: