Notifications

Developers can subscribe to be notified for health check or status changes to their applications. Additionally, it is possible for end users to be notified of changes to an application’s status.

Health Check Change

Developers can subscribe to be notified whenever the health of a tenant’s application changes, by logging in to the Tenant Admin Webapp) and navigating to the Status page / Applications tab:

When the I want to subscribe and receive notifications box is checked, you will be notified of changes to any application your tenant is monitoring, including those not publicly displayed on the tenant’s public status page (at https://status.adsp.alberta.ca/{tenant-name}).

Status Update

End Users can subscribe to be notified whenever the status of a tenant’s application changes. Each application can display a public status page that lists the tenant’s monitored applications and their current status. If a user enters their email address on the page, they will receive an email whenever a developer updates an application’s status.

The email contains a link so that the users can unsubscribe if they wish, which brings them to their personal ADSP Subscription Management Page. Users will see something like this on the page

Custom Email Templates

The above notifications are managed by the ADSP Notification Service, which provides email templates that you can customize to suit your application’s needs. Simply log in to the Tenant Management Webapp and navigate to the Notification Service / Notifications Type tab, where you will see a list of notifications. In particular, you will see the Application Health Check Change, and the Application Status Update notification types.

Each Notification Type consists of a set of Events, and a notification is triggered when one of the events is triggered. The Application Health Check Change type, for example, responds to four events

  • health-check-started
  • health-check-stopped
  • application-unhealthy
  • application-healthy

You can customize the message sent for each of these events.

Email templates are built using HTML/CSS and a template language called Handlebars, which is used for mapping a set of keys into the event properties. You would use a template key to represent the application name, for example, like this

Health check has been started for {{event.payload.application.name}}

The following properties are available, depending on Event Type:

All

  • event.payload.application.id
  • event.payload.application.name
  • event.payload.application.description
  • event.payload.application.url
  • event.payload.application.monitorOnly

In addition to the properties above, the individual, unique event types have:

Health Check Started

  • event.payload.startedBy

Health Check Stopped

  • event.payload.stoppedBy

Application Unhealthy

  • event.payload.error

Application Healthy

  • N/A

Application Status Changed

  • event.payload.application.originalStatus
  • event.payload.application.newStatus
  • event.payload.application.updatedBy.userId
  • event.payload.application.updatedBy.userName

Application Notice Published

  • event.payload.notice.description
  • event.payload.notice.startTimestamp
  • event.payload.notice.endTimestamp
  • event.payload.postedBy.userId
  • event.payload.postedBy.userName

There are out-of-the-box default templates that you can start using right away. For a custom user experience though, consider building and managing your own.

Learn More

Learn how to

  • monitor your application’s health.
  • use status codes to keep users informed about application health.
  • provide notices about application status to end users.