Test Alert Logs

Test logs are populated for every request triggered for this alert using the Test Request Details. This helps you debug request failures faster and identify bottlenecks in the process. Once you’ve tested the Alert, test logs get generated and can be viewed in the Test Request Logs section.

Request Details

Every row in the logs section contains information about the request received for the Test Alert. The following information is available for every request in the logs:
test alert logs.png

Request Details	Description
Received Time	The timestamp that indicates when MoEngage received this request from you. This will show the exact time when the request was received, down to seconds.
Request ID	The unique identifier that is assigned to every request. This value is generated and stored by MoEngage.
Channel	This denotes the channel on which the request was sent. Requests may be sent on single or multiple channels. The sender icon beside the channel indicates which sender was automatically chosen to send the alert, as determined by the dynamic sender routing logic. For the Push channel, if the Message type for iOS is Live Activity Only or Live Activity with Push Fallback, the logs page displays specific statuses for Live Activity, including Start, Update, and End. These indicators are visible within the log entries when you view Push notification details. Live Activity consists of three distinct stages: Start: Initiates the notification for the first time. Update: Represents intermediate steps or data refreshes sent during the activity. End: The final call that signifies the completion of the transaction. For more information, refer to Transactional Live Activites.
Status	This denotes the request status and represents different milestones where the request/message can fail. The possible statuses are: Request Failed -When it is a duplicate request or an inactive alert (paused or dropped) was targeted Request Processing - When MoEngage takes an unusually long to process the request and send it to the vendors. Request Dropped - When the rate of requests is more than the rate limit set for alerts. MoEngage follows a rate-limiting of 10K requests per minute. Contact your account manager if you want to increase the API rate limit. Delivery Pending - When MoEngage is still waiting for the delivery callback from the vendor of a particular channel. Some of the vendors take up to 15 mins to update whether a message was delivered. Delivery Successful - When the vendor was able to deliver the message to the recipient. You can also check how quickly this message was delivered in the Time to Deliver column. Delivery Failed - When the vendor was not able to deliver the message. This could result due to various reasons like hard and soft bounces in email and errors like handset issues, incorrect mobile number, inbox full, and so on in SMS. Delivery info NA - When MoEngage has not received any callbacks in the desired format from the vendors. This is applicable in the case of custom connectors (service providers) and SMTP in SMS and Emails, respectively.
Recipient ID	This denotes the recipient information to whom the message was targeted. This field contains the push token for push notifications, email address for the email channel, and the mobile number for SMS.
Transaction ID	This is a unique identifier attached to every transaction for which the Alert is being sent. This value is used to support Idempotency in MoEngage. For more information, refer to idempotent requests.
Time to send	This denotes the time taken by MoEngage to send the message to the vendor from the moment MoEngage received a request.

You can click on the row to get more information about the request. The following information is available for every request:

Delivery info - The Delivery Info section contains the details about when the request was received, when the message was sent to the vendor for the specified channel, and the delivery time. In the case where the Alert is configured to be sent across multiple channels in a sequential manner, the following information is available:
- Attempted via First Backup - <channelname>
- Request received from Primary Channel - <channel name>
- Attempted via Second Backup - <channelname>
- Request received from First Backup - <channel name>
  For example, if the primary or default channel is Push, the first fallback is SMS, and the second fallback is Email, and the request fails for both Push and SMS and gets sent using the Email channel, the Delivery Info for these requests would appear as shown in the image below.
Request - The Request section contains the request payload for the specific channel for which the test log is being displayed.
Response - The Response section contains the response to the request generated by MoEngage.

Search Test Alert Logs

You can search and filter your test logs using the following filter conditions:

Search by Request ID or Transaction ID
Search by Channel
Search by Request Status
Search within a specified date range
Search with Recipient ID
Search with Time to send