Logs
Learn how to track, debug, & audit notification logs on SuprSend.
SuprSend provides real-time notification logs of sent notifications for quick debugging and auditing. Navigate to the Logs tab on the SuprSend dashboard to access notification logs.
Data Structure of Logs
Every workflow request generates a common entry in the log, allowing developers to gain a holistic view of notifications sent across all channels. You can expand the log to track the entire notification flow of each channel, from request to user delivery and engagement (open, seen, and click).
📘 Set Callback URL in vendor account:
To track notification failure, delivery, seen and click response in your logs, configure SuprSend tracking URL https://hub.suprsend.com/webhook/* in your vendor dashboard.
This enables SuprSend to get delivery and failure response from your vendor and show the same in dashboard logs. You’ll find details of the callback URL in individual vendor integration documentation.
You can also configure your outbound webhook to get the normalized vendor response back to your application.
Notification log conveys all necessary information in a summarized view for easy debugging:
| Field | Description |
|---|---|
| Workflow | Workflow name. You can click on it to see workflow configuration and summarized analytics on the workflow details page. |
| Distinct ID | distinct_id of the user receiving the message. Clicking on it provides direct access to the subscriber details page, where you can review user channels and profile properties. This will come in handy to debug notification failures caused by missing channel information on a user. |
| Delivery Type | Send to All Channels -will send notification on all available channels in user profile defined in workflow call.Smart Delivery -sequential sending of notifications on available channels one after the other with a delay where delivery stops if the success metric is achieved. Read more |
| User channel | Trigger summary of all channels. (1) Sent count- notifications successfully sent by SuprSend to end vendor. This would also mean successful notification delivery to end user if callback URL tracking is set in vendor account. (2) failed count- SuprSend failed to send the notifications or if we got delivery failure error from vendor. (3) in progress count- Notifications in progress during Smart Delivery |
| Status | Success if at least one of the notifications is sent in workflow.Failed if all notifications fail in the workflow. |
Notification Status
You can see notification status in real-time as they are being sent by expanding the log. These are all the stages we track:
| Stage | Status | Description |
|---|---|---|
| 1 | Requested | Notification request is accepted by SuprSend. |
| 2 | Processed | SuprSend started processing the request. |
| 3 | Triggered | Notification request is passed from SuprSend to channel vendor. |
| 3 | Trigger Failed | SuprSend encountered error in forwarding the notification request to the vendor. To understand the cause of the failure, simply hover over the ‘i’ icon within the failed log chip. Failures can be categorized into two types: 1. SuprSend was unable to process the request due to issues like template rendering failure or the user missing the relevant channel information. 2. SuprSend attempted to call vendor API, but vendor didn’t accept the request. This can result from errors in the notification payload, such as template mismatches in WhatsApp, invalid vendor credentials, or incorrect channel values like an invalid mobile number or email. |
| 3 | Failure by vendor | Vendor accepted the request but failed to deliver the notification to end user. To understand the cause of the failure, simply hover over the ‘i’ icon within the failed log chip. These errors originate from vendor’s end, and for detailed insights into the reason for failure, refer the error guides of individual vendor. |
| 4 | Delivered | Notification is successfully delivered to the end user. |
| 5 | Seen | Seen is marked by different actions on each channel:Email: openedWhatsapp: readInbox: read (**on click of Mark all as read**) or clickedpush(android, iOS, web): clickedchat(Slack, Microsoft teams): seen is not tracked for chat channels |
| 6 | Dismissed | Dismiss is marked when user clicks on clear all and removes push notification from the tray. Tracked for androidpush channel only. |
| 7 | Interacted | Interacted is marked when someone clicks on the notification |
Notification Statuses Tracked Per Channel
Requested, Processed, Triggered is internal to SuprSend and tracked for all channels. Here is a list of all statuses tracked across channels from delivery onwards:
| Channel | Failure by vendor / Trigger Failed | Delivered | Seen | Dismissed | Interacted (Clicked) |
|---|---|---|---|---|---|
| yes | yes | yes | - | yes | |
| SMS | yes | yes | - | - | - |
| yes | yes | yes | - | - | |
| Androidpush | yes | yes | yes | yes | yes |
| iOSpush | yes | yes | yes | - | yes |
| Webpush | yes | yes | yes | - | yes |
| Inbox | yes | yes | - | - | yes |
| Slack | yes | yes | - | - | - |
| MS Teams | yes | yes | - | - | - |
👍 Set Callback URL in vendor account:
To track notification status post-trigger, like trigger failure, delivery, seen and click response in your logs, configure SuprSend tracking URL https://hub.suprsend.com/webhook/* in your vendor portal. You’ll find details of the callback URL in respective vendor integration documentation.
Getting Logs and Notification Status Back to your Database
You can either configure outbound webhook to get instant alert of all notification statuses in a URL endpoint. You can use it for logging on a third party platform and internal alerting of failure cases.
Setup S3 sync for internal analytics or showing notification status to your customers within your product. With this, you can get a consolidated entry of each notification sent and their statues in your database. You can directly query on this data using Athena or import it to data warehouses like Redshift, Snowflake, ClickHouse etc. for analysis.
** Trouble debugging? Reach out to Support **
You can click on **i** icon at the end of logs to see more details related to workflow execution like brand_id, idempotency_key, execution ID. If you have trouble debugging the error, just copy the execution ID and share with us either through in-product chat or slack community. We’ll be happy to help you debug the issue.
Filtering Logs
Pinpoint the required log faster with filters. You can narrow down your logs based on specific criteria such as user distinct_id, worklow name, brand_id, idempotency_key, status and date-time. To filter logs, click on filter icon in the top right side options on logs page. Select Failure logs to just filter records with errors.
Date Time Filter
Date Time filter allows you to filter logs for a given time period. By default, logs for last 30 minutes is shown. You can change the filter to see logs for longer time span or select custom filter to see logs older than 2 days.
Please note that logs retention depends on pricing plan. Check pricing page to see log retention timeframe applicable for your plan.
Logs Date Time filter
Custom date-time filter
Subscriber Logs
You can also get easy reference of workflow logs on subscriber details page. This can be used for user level auditing and compliance checks, allowing you to reference all notifications sent to a user within a specified time period. You can also access subscriber specific logs directly on logs page by filtering on distinct_id.