Skip to main content

​
Introduction

Novu provides a notification activity feed that monitors every outgoing message associated with its relevant metadata. This can be used to monitor activity and discover potential issues with a specific provider or channel type.

​
Viewing a specific subscriber’s activity

To use a subscriber’s activity feed you can filter the feed by using the subscriberId or email. This will show only the relevant data for this particular subscriber. To do this, just enter the subscriberId or the ‘email’ of the subscriber you want to get info of and then click the ‘search’ button on the right-hand side as shown in the image below:

​
Filter by workflow or channel

The activity feed allows you to filter messages based on the associated workflow or channel. This is helpful when you want to assess or debug a particular workflow and its behaviour. Filtering by workflow or channel is quite simple. Just go to the Workflow dropdown (if you want to filter by workflow) or the channel tab (if you want to filter by channel) and select the corresponding workflow or channel and click the ‘search’ button on the right-hand side as shown in the image below:

​
Troubleshooting with the activity feed

The activity feed also shows if a transaction is failing. You can see why a transaction is failing and rectify it. For example, take a look at the following image:
You can see that an SMS notification has failed to get delivered. Clicking on it opens the execution details and the reason why that transaction failed
This can help troubleshoot the problem and comes in handy at the time of distress.

​
Digest info in the activity feed

If you’re using our digest notifications functionality, you’ll be able to see all the digest-related information in the activity feed.
Some of the information related to digest present in the activity feed is:
  • Digest step delay
  • Digesting start time
  • Digest triggered events details
  • More digest execution details
From here, you can see the details of ‘digest triggered events’ to see exactly which events were digested and the content of the notification you sent, as shown below:

​
Trigger Event Lifecycle

​
Trigger request

The request contains details such as the identifier for the template, the list of subscribers who will receive the notification, the payload of the notification, and any overrides that need to be applied.

​
Trigger endpoint

After the request is sent to the /event/trigger endpoint, the initial step involves mapping and validating the subscribers for that event. Following that, we validate the template and steps based on the active status or draft template flag. Once the validation process is complete, the attachments are uploaded to the storage service. Next, the trigger event with mapped subscribers and attachment links is appended to the trigger event queue. By queuing the events, we can achieve faster response times.

​
Trigger event processing

When the event is picked up by the trigger queue worker we process it. For every subscriber listed in the trigger event, we create a notification entity and the corresponding jobs based on the notification template steps. The notification contains data related to the organization, template, subscriber, and event payload. It is updated with a channels field that is generated from the steps.

​
Jobs

Every job is created according to the steps outlined in the template. If the template contains a digest step, the filtering logic is applied to produce the appropriate jobs array depending on the type of digesting: regular or backoff.