Logging

A guide to SuprSend notification logs and how to navigate and troubleshoot log errors

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:

FieldDescription
WorkflowWorkflow name. You can click on it to see workflow configuration and summarized analytics on the workflow details page.
Distinct IDdistinct_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 TypeSend 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 channelTrigger 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
StatusSuccess 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:

StageStatusDescription
1RequestedNotification request is accepted by SuprSend.
2ProcessedSuprSend started processing the request.
3TriggeredNotification request is passed from SuprSend to channel vendor.
3Trigger FailedSuprSend 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.
3Failure by vendorVendor 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.
4DeliveredNotification is successfully delivered to the end user.
5SeenSeen is marked by different actions on each channel:
Email: opened
Whatsapp: read
Inbox: read (**on click of Mark all as read**) or clicked
push(android, iOS, web): clicked
chat(Slack, Microsoft teams): seen is not tracked for chat channels
6DismissedDismiss is marked when user clicks on clear all and removes push notification from the tray. Tracked for androidpush channel only.
7InteractedInteracted 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:

ChannelFailure by vendor / Trigger FailedDeliveredSeenDismissedInteracted (Clicked)
Emailyesyesyes-yes
SMSyesyes---
Whatsappyesyesyes--
Androidpushyesyesyesyesyes
iOSpushyesyesyes-yes
Webpushyesyesyes-yes
Inboxyesyes--yes
Slackyesyes---
MS Teamsyesyes---

👍

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 mins 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

Logs Date-time filter

Custom 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.


What’s Next

Check error guides for debugging workflow and broadcast failures.