Merge pull request #229160 from spelluru/egridretry0301

Fixed an issue and freshness review & update

Author: American-Dipper

articles/event-grid/delivery-and-retry.md

@@ -2,11 +2,11 @@
 title: Azure Event Grid delivery and retry
 description: Describes how Azure Event Grid delivers events and how it handles undelivered messages.
 ms.topic: conceptual
-ms.date: 01/12/2022
+ms.date: 03/01/2023
 ---
 
 # Event Grid message delivery and retry
-Event Grid provides durable delivery. It tries to deliver each message **at least once** for each matching subscription immediately. If a subscriber's endpoint doesn't acknowledge receipt of an event or if there's a failure, Event Grid retries delivery based on a fixed [retry schedule](#retry-schedule) and [retry policy](#retry-policy). By default, the Event Grid module delivers one event at a time to the subscriber. The payload is however an array with a single event.
+Event Grid provides durable delivery. It tries to deliver each message **at least once** for each matching subscription immediately. If a subscriber's endpoint doesn't acknowledge receipt of an event or if there's a failure, Event Grid retries delivery based on a fixed [retry schedule](#retry-schedule) and [retry policy](#retry-policy). By default, Event Grid delivers one event at a time to the subscriber. The payload is however an array with a single event.
 
 > [!NOTE]
 > Event Grid doesn't guarantee order for event delivery, so subscribers may receive them out of order. 
@@ -20,13 +20,13 @@ The following table describes the types of endpoints and errors for which retry
 
 | Endpoint Type | Error codes |
 | --------------| -----------|
-| Azure Resources | 400 Bad Request, 413 Request Entity Too Large, 403 Forbidden, 404 Not Found | 
-| Webhook | 400 Bad Request, 413 Request Entity Too Large, 403 Forbidden, 404 Not Found, 401 Unauthorized |
+| Azure Resources | 400 (Bad request), 413 (Request entity is too large) | 
+| Webhook | 400 (Bad request), 413 (Request entity is too large), 401 (Unauthorized) |
 
 > [!NOTE]
-> If dead-letter isn't configured for an endpoint, events will be dropped when the above errors happen. Consider configuring dead-letter if you don't want these kinds of events to be dropped. Dead lettered events will be dropped when the dead dead-letter destination is not found.
+> If dead-letter isn't configured for an endpoint, events will be dropped when the above errors happen. Consider configuring dead-letter if you don't want these kinds of events to be dropped. Dead lettered events will be dropped when the dead-letter destination isn't found.
 
-If the error returned by the subscribed endpoint isn't among the above list, Event Grid performs the retry using policies described below:
+If the error returned by the subscribed endpoint isn't among the above list, Event Grid performs the retry using the policy described below:
 
 Event Grid waits 30 seconds for a response after delivering a message. After 30 seconds, if the endpoint hasn’t responded, the message is queued for retry. Event Grid uses an exponential backoff retry policy for event delivery. Event Grid retries delivery on the following schedule on a best effort basis:
 
@@ -42,12 +42,12 @@ Event Grid waits 30 seconds for a response after delivering a message. After 30
 - Every 12 hours up to 24 hours
 
 
-If the endpoint responds within 3 minutes, Event Grid will attempt to remove the event from the retry queue on a best effort basis but duplicates may still be received.
+If the endpoint responds within 3 minutes, Event Grid attempts to remove the event from the retry queue on a best effort basis, but duplicates may still be received.
 
 Event Grid adds a small randomization to all retry steps and may opportunistically skip certain retries if an endpoint is consistently unhealthy, down for a long period, or appears to be overwhelmed.
 
 ## Retry policy
-You can customize the retry policy when creating an event subscription by using the following two configurations. An event will be dropped if either of the limits of the retry policy is reached. 
+You can customize the retry policy when creating an event subscription by using the following two configurations. An event is dropped if either of the limits of the retry policy is reached. 
 
 - **Maximum number of attempts** - The value must be an integer between 1 and 30. The default value is 30.
 - **Event time-to-live (TTL)** -  The value must be an integer between 1 and 1440. The default value is 1440 minutes
@@ -60,7 +60,7 @@ Event Grid defaults to sending each event individually to subscribers. The subsc
 ### Batching policy
 Batched delivery has two settings:
 
-* **Max events per batch** - Maximum number of events Event Grid will deliver per batch. This number will never be exceeded, however fewer events may be delivered if no other events are available at the time of publish. Event Grid doesn't delay events to create a batch if fewer events are available. Must be between 1 and 5,000.
+* **Max events per batch** - Maximum number of events Event Grid delivers per batch. This number will never be exceeded, however fewer events may be delivered if no other events are available at the time of publish. Event Grid doesn't delay events to create a batch if fewer events are available. Must be between 1 and 5,000.
 * **Preferred batch size in kilobytes** - Target ceiling for batch size in kilobytes. Similar to max events, the batch size may be smaller if more events aren't available at the time of publish. It's possible that a batch is larger than the preferred batch size *if* a single event is larger than the preferred size. For example, if the preferred size is 4 KB and a 10-KB event is pushed to Event Grid, the 10-KB event will still be delivered in its own batch rather than being dropped.
 
 Batched delivery in configured on a per-event subscription basis via the portal, CLI, PowerShell, or SDKs.
@@ -84,7 +84,9 @@ Batched delivery in configured on a per-event subscription basis via the portal,
   It isn't necessary to specify both the settings (Maximum events per batch and Approximate batch size in kilo bytes) when creating an event subscription. If only one setting is set, Event Grid uses (configurable) default values. See the following sections for the default values, and how to override them.
 
 ### Azure portal: 
-![Batch delivery settings](./media/delivery-and-retry/batch-settings.png)
+You see these settings on the **Additional Features** tab of the **Event Subscription** page. 
+
+:::image type="content" source="./media/delivery-and-retry/batch-settings.png" alt-text="Screenshot sowing the Additional Features tab of Event Subscription page with Batching section highlighted. ":::
 
 ### Azure CLI
 When creating an event subscription, use the following parameters: 
@@ -108,7 +110,7 @@ For more information on using Azure CLI with Event Grid, see [Route storage even
 
 
 ## Delayed Delivery
-As an endpoint experiences delivery failures, Event Grid will begin to delay the delivery and retry of events to that endpoint. For example, if the first 10 events published to an endpoint fail, Event Grid will assume that the endpoint is experiencing issues and will delay all subsequent retries *and new* deliveries for some time - in some cases up to several hours.
+As an endpoint experiences delivery failures, Event Grid begins to delay the delivery and retry of events to that endpoint. For example, if the first 10 events published to an endpoint fail, Event Grid assumes that the endpoint is experiencing issues and will delay all subsequent retries *and new* deliveries for some time - in some cases up to several hours.
 
 The functional purpose of delayed delivery is to protect unhealthy endpoints and the Event Grid system. Without back-off and delay of delivery to unhealthy endpoints, Event Grid's retry policy and volume capabilities can easily overwhelm a system.