Audit device: Clarifications based on feedback (#16881)

- Update blocked audit device to use feedback from #6484
- This PR supersedes #6484

website/content/docs/audit/index.mdx

@@ -74,20 +74,15 @@ The existing logs that it did store are untouched.
 
 ## Blocked Audit Devices
 
-If there are any audit devices enabled, Vault requires that at least
-one be able to persist the log before completing a Vault request.
+Audit device logs are critically important and ignoring auditing failures opens an avenue for attack. Vault will not respond to requests when no enabled audit devices can record them.
 
-!> If you have only one audit device enabled, and it is blocking (network
-block, etc.), then Vault will be _unresponsive_. Vault **will not** complete
-any requests until the audit device can write.
+Vault can distinguish between two types of audit device failures.
 
-If you have more than one audit device, then Vault will complete the request
-as long as one audit device persists the log.
+- A blocking failure is one where an attempt to write to the audit device never completes. This is unlikely with a local disk device, but could occure with a network-based audit device.
 
-Vault will not respond to requests if audit devices are blocked because
-audit logs are critically important and ignoring blocked requests opens
-an avenue for attack. Be absolutely certain that your audit devices cannot
-block.
+- When multiple audit devices are enabled, if any of them fail in a non-blocking fashion, Vault requests can still complete successfully provided at least one audit device successfully writes the audit record. If any of the audit devices fail in a blocking fashion however, Vault requests will hang until the blocking is resolved.
+
+In other words, Vault will not complete any requests until the blocked audit device can write.
 
 ## Tutorial