diff --git a/servicepulse/images/retry/all-retry-in-progress.png b/servicepulse/images/retry/all-retry-in-progress.png
new file mode 100644
index 00000000000..16c8077f30e
Binary files /dev/null and b/servicepulse/images/retry/all-retry-in-progress.png differ
diff --git a/servicepulse/images/retry/failed-mesage-groups-annotated.png b/servicepulse/images/retry/failed-mesage-groups-annotated.png
new file mode 100644
index 00000000000..27613644682
Binary files /dev/null and b/servicepulse/images/retry/failed-mesage-groups-annotated.png differ
diff --git a/servicepulse/images/retry/one-retry-in-progress.png b/servicepulse/images/retry/one-retry-in-progress.png
new file mode 100644
index 00000000000..11280711307
Binary files /dev/null and b/servicepulse/images/retry/one-retry-in-progress.png differ
diff --git a/servicepulse/images/retry/request-the-retry-of-a-singlemessage.png b/servicepulse/images/retry/request-the-retry-of-a-singlemessage.png
new file mode 100644
index 00000000000..d98e6e65230
Binary files /dev/null and b/servicepulse/images/retry/request-the-retry-of-a-singlemessage.png differ
diff --git a/servicepulse/images/retry/retry-all.png b/servicepulse/images/retry/retry-all.png
new file mode 100644
index 00000000000..97c78429460
Binary files /dev/null and b/servicepulse/images/retry/retry-all.png differ
diff --git a/servicepulse/intro-failed-message-retries.md b/servicepulse/intro-failed-message-retries.md
index 7cc7ff59f2c..6d8aefaba85 100644
--- a/servicepulse/intro-failed-message-retries.md
+++ b/servicepulse/intro-failed-message-retries.md
@@ -20,3 +20,31 @@ If a message was retried and came back to ServiceControl as failed it might mean
 There are two ways to deal with this scenario. If the issue in the sender can be fixed, there will be no new malformed messages coming. The ones already sent can be redirected to an endpoint that specifically addresses the malformed messages. [This sample](/samples/servicecontrol/fix-messages/) shows how this can be done using the ServiceControl redirects feature.
 
 If the sender cannot be fixed it is better to use a pipeline behavior to repair the messages at the receiver endpoint before they are passed to the handler. [This sample](/samples/pipeline/fix-messages-using-behavior/) demonstrates this scenario.
+
+
+## ServicePulse interface
+
+ServicePulse allows you to see failed messages and retry them. By default, the UI groups these messages based on the endpoint that failed to process them. You can see the source, and the number of failed messages.
+
+![Failed Messages](./images/retry/failed-mesage-groups-annotated.png)
+
+### Retrying failed messages
+
+The messages can be retried in different ways:
+ - [One by one](#the-messages-can-be-retried-in-different-ways-one-by-one)
+ - [By the an entire group](#the-messages-can-be-retried-in-different-ways-by-the-an-entire-group)
+
+#### 1. One by one
+
+![Individual message retry](./images/retry/failed-mesage-groups-annotated.png)
+
+In this case, you will see the a notification showing that a retry has been been requested, and it is in progress.
+![Individual message retry in progress](./images/retry/one-retry-in-progress.png)
+
+#### 2. By the an entire group
+
+![Retry all](./images/retry/retry-all.png)
+
+You will see a retry in progress notification for all the messages, as well as the number of messages failed decreased.
+
+![All retried in progress](./images/retry/all-retry-in-progress.png)