- 28 Oct 2021
- 3 Minutes To Read
-
Print
-
DarkLight
-
PDF
Communications Log
- Updated On 28 Oct 2021
- 3 Minutes To Read
-
Print
-
DarkLight
-
PDF
Every notification sent to a client, user, or third party system is saved in Mambu for auditing and troubleshooting purposes. You can search your complete notification history by state, sender and date, which will make it easy for you to know which messages were delivered, when, to whom and what the contents of the message were. Manual notifications will indicate the name of the user who sent it while any automated notifications will all have the sender Mambu.
You can also apply filters on those messages, edit the displayed columns or export to Excel. If you chose to export the list to Excel it will include the full message text. The message subject is available if you click more in the Message column to view the full message.
You can also view a filtered communications log by accessing the detail pages for:
- Clients → you’ll see all the manual and automated notification messages sent to them.
- Groups → you'll see all the manual notifications sent to the general group contact address as well as automated Webhooks sent based on group activity.
- Users → you’ll see all the manual messages sent by that user as well as automated messages sent to them based on client activity.
Notification States
State | Description |
---|---|
QUEUED , WAITING , SENDING_ASYNC |
The notification is waiting to be sent. |
SENT |
The notification was sent successfully. |
FAILED |
The notification was not sent to the designated target. |
Resending Failed Messages
If your notification gateway was not available when the message was sent (SMTP server was down, SMS provider was offline etc.), you can resend a message to the client.
By clicking on the Failed State column or on the more button from the Message column, a dialog will be shown with the possibility to resend the message. If you resend the message you will not overwrite the entry for the initial failed message, Mambu will try to send the notification again and create a new entry with its own state and sent date, retaining the log entry of the original message for further investigation.
You can also use our APIs for checking the status of and resending notifications. For example, sending a POST request to the /api/communications/messages:search
endpoint with this body:
[
{
"field": "state",
"operator": "EQUALS",
"value": "FAILED"
},
{
"field":"type",
"operator":"EQUALS",
"value":"EMAIL"
}
]
will return an array of all failed email messages. The response can be used to create the body for a POST request to the /api/communications/messages:resend
endpoint to trigger a resend of these messages.
For more information on this or any other API, please consult our dedicated API documentation.
Automatic retry mechanism for failed communications
Mambu supports an auto-retry policy to resend all failed SMS, Email or Webhook notifications. With this mechanism we will mitigate potential communication outages by retrying any failed notification a number of times.
Field | Description |
---|---|
maxRetries |
The max number of retries to perform. -1 indicates to retry forever. |
backOffDelay |
The delay between retries, exponentially backing off to the maxDelay and multiplying successive delays by a factor. |
backOffMaxDelay |
The max delay between retries. |
delayFactor * backOffDelay |
Time to wait before retrying messages. |
By default the maximum number of retries to be performed is set to 4
. Between each retry there is a delay range configured (measured in seconds) using an exponential backoff strategy to permit the servers to wait for longer intervals of time for each retry attempt. Using the default values, a message will be retried after 2
, 6
, 18
and 54
seconds, after which it is considered failed.