Add latest changes from gitlab-org/gitlab@13-5-stable-eev13.5.0-rc42

1 files changed, 6 insertions, 3 deletions

diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 099346b2b0b..ac972e2e33e 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 GitLab offers a way to view the changes made within the GitLab server for owners and administrators on a [paid plan](https://about.gitlab.com/pricing/).
 
 GitLab system administrators can also take advantage of the logs located on the
-filesystem. See [the logs system documentation](logs.md) for more details.
+file system. See [the logs system documentation](logs.md) for more details.
 
 ## Overview
 
@@ -108,7 +108,7 @@ Server-wide audit logging introduces the ability to observe user actions across
 the entire instance of your GitLab server, making it easy to understand who
 changed what and when for audit purposes.
 
-To view the server-wide admin log, visit **Admin Area > Monitoring > Audit Log**.
+To view the server-wide administrator log, visit **Admin Area > Monitoring > Audit Log**.
 
 In addition to the group and project events, the following user actions are also
 recorded:
@@ -126,6 +126,7 @@ recorded:
 - User was added ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/251) in GitLab 12.8)
 - User was blocked via Admin Area ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/251) in GitLab 12.8)
 - User was blocked via API ([introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25872) in GitLab 12.9)
+- Failed second-factor authentication attempt ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16826) in GitLab 13.5)
 
 It's possible to filter particular actions by choosing an audit data type from
 the filter dropdown box. You can further filter by specific group, project, or user
@@ -151,7 +152,7 @@ on adding these events into GitLab:
 
 The current architecture of audit events is not prepared to receive a very high amount of records.
 It may make the user interface for your project or audit logs very busy, and the disk space consumed by the
-`audit_events` PostgreSQL table will increase considerably. It's disabled by default
+`audit_events` PostgreSQL table may increase considerably. It's disabled by default
 to prevent performance degradations on GitLab instances with very high Git write traffic.
 
 In an upcoming release, Audit Logs for Git push events will be enabled
@@ -172,6 +173,7 @@ the steps bellow.
 
    ```ruby
    Feature.enable(:repository_push_audit_event)
+   ```
 
 ## Export to CSV **(PREMIUM ONLY)**
 
@@ -183,6 +185,7 @@ the steps bellow.
 
 CAUTION: **Warning:**
 This feature might not be available to you. Check the **version history** note above for details.
+If available, you can enable it with a [feature flag](#enable-or-disable-audit-log-export-to-csv).
 
 Export to CSV allows customers to export the current filter view of your audit log as a
 CSV file,