Improved Per Message Telemetry and device expiry for Notification Hubs

We are announcing some updates to our Per Message Telemetry feature and device expiry.

Per Message Telemetry

Per Message Telemetry is now available for scheduled notifications and is improved to understand additional push request processing statuses. On top of the existing Enqueued, Processing, Completed, and Abandoned states, we added:

• Scheduled (for scheduled notifications): Message is in queue and will be sent on the scheduled time
• Cancelled (for scheduled notifications): The scheduled message was cancelled by user
• NoTargetFound: No targeting device was found for the push request

You can use Per Message Telemetry through our REST or .NET SDK's GetNotificationOutcomeDetailsAsync API:

//Notification will be sent after an hour
NotificationHubClient notificationHubClient;
DateTimeOffset scheduledTime = new DateTimeOffset(DateTime.UtcNow).AddHours(1);
var scheduledNotification = notificationHubClient.ScheduleNotificationAsync(, scheduledTime);

//Query the status of this send request
var outcome = notificationHubClient.GetNotificationOutcomeDetailsAsync(scheduledNotification.NotificationId);

Time To Live (device expiry)

Many of our customers have come to us in the past with this scenario: What if my end users rarely open the app but depend heavily on notifications provided by it? Since Notification Hubs had a max of 90-day device Time To Live and devices register with hubs on app startup, the solution used to be a customer initiated export-update-import process to keep each device up-to-date – tedious to say the least. That’s why we decided to extend the allowed device expiry on both our device models, registration and installation (recommended), to infinity (or 9999-12-31T23:59:59 to be precise).

We still recommend updating registrations and installations for devices on app startup, but we won’t initiate deletion of registrations or installations unless the devices reach your customized Time To Live, or if our service gets a “token expired” error from Platform Notification Systems on an attempted send. Unless customized, we default the hub Time To Live to the system max DateTime value. So it is correct to be seeing a “Registrations Time To Live” display in the classic Azure portal of 10M+ days if you created that notification hub recently.

To take advantage of this expiry change, simply update your notification hub’s Time To Live property. This can be done through REST or our .NET SDK:

var namespaceManager = NamespaceManager.CreateFromConnectionString("connectionstring");
NotificationHubDescription hub = namespaceManager.GetNotificationHub("foo");
hub.RegistrationTtl = TimeSpan.MaxValue;
namespaceManager.UpdateNotificationHub(hub);

Please try it out and let us know what you think in the comments section below.