In some rare cases, notifications (email, SMS, app) stop being received by the user. 

Typically, it is for one of the following reasons:

• The alert/report we are expecting to receive was not actually generated by TG in the first place, so there was no notification to send
• Organisation Notification Send Limit has been reached
• Caught in user's mailbox spam filter
• The user's mailbox bounced the email
• Cellular Network issue for SMS

If notifications such as alerts or scheduled reports are not being received by certain/all users - the following steps can be taken to help correct the issue.

Troubleshooting tips:

1. Check the Alert/Report was actually generated

For alerts - go to History -> Asset Timeline. If the alert was generated, it will appear in the timeline. If it does not - check the conditions on the alert are correct, and whether they actually occurred via the asset's Telemetry. 

For reports - go to Reports -> Scheduled Report Logs. (The Scheduled Report Logs permission is required on your user account). A list of generated reports is shown - if there are any errors - they will be indicated. This shows that the error is with the report generation rather than notifications specifically. 

2. Check the notification was sent. 

The Admin -> Organisation Messages view will display a history of all notifications that were sent via Email, SMS or Webhook. It requires either the Organisation Manage or Organisation View permission. 

This menu has the following features:

1. Filter by specific entry in the address book
2. Filter between Mobile App, Email, SMS or API notifications
    
3. If a specific user is set in (1) - you can check the Mail Deliverability
   
   
   If the user is on a bounce list - there will be a button Remove From Suppression List - click this to remove them from the list.
4. The current number of notifications vs the limit set up for the organisation is shown. Edit the Organisation to increase this value - it simply needs to be set to a sensible value to provide a backstop - such that any misconfigured alerts that generate thousands of emails will eventually be cut off when many are generated.
5. Success (as reported from Sendgrid)

A note on "Success"
When an alert/report is generated in TG - and an email must be sent - TG sends the required information off to it's mail server provider - Sendgrid - which handles the email processing - and responds back saying whether it was successful or not. So in general this indicates success - but in rare cases this may be lying - as it does not indicate the email completely reached it's end destination - just that Sendgrid responded saying everything is OK.

3. Check Email Limits:

Emails by default are limited to 5000 per month, and SMS Messages 500. 

This is not a set number, any limit can be set via the UI. The number of emails is only capped as a precaution to avoid any misconfigured alerts potentially generating many thousands of emails.

Given SMS charges apply, by the same token, it makes sense to have an SMS Notification Limit to prevent excessive SMS charges and bill shock. 

If notifications are not being sent due to the limit being reached, this will be obvious in the Organisation Messages view.

You can change the caps to any number you prefer from Admin->Organisation Manage->Organisations->Edit

Pick something that makes sense for the number of assets your organisation has, and the number of alerts that are sent. 

However, if you are generating 10s of 1000s of notifications each month, perhaps your alerts should be reconsidered. Alerts are best used to report exceptions, not day to day events. Maybe schedule a daily report. 

4. Check Email Address/phone number is correct and send test messages. 

Check that the email address is correct in the Address Book. The Address is accessible from the Dashboard, or Admin >> Address Book.

A test email can be sent to the user via the "Test" button in the Address Book edit dialogue.

5. Check if Email Address/ Mobile Number is blacklisted

If a delivery to a particular email address or mobile number fails repeatedly, Telematics Guru flags this number or email address as "blacklisted". This can be checked in the "Address Book" section in TG.

This could be due to either of the below reasons

• The email address or phone number is actually blacklisted by the service provider. You will need to reach out to the service provider to confirm this.
• Telematics Guru may eventually add an email address or phone number to the blacklist if delivery repeatedly fails. This prevents the domain being marked as ‘untrustworthy’ and leading to more emails/SMS going to spam. 

Once you have confirmed the email/phone number is not blacklisted by the service provider and the issue still persists, contact support and we can remove the entry. 

6. Restart Report

A scheduled report may fail to generate if there is an incorrect parameter setup. The Scheduled Report Logs will indicate the below in this instance.

Edit the report to make the needed changes and resave. Once this is done, restart the report from Reports →Scheduled Reports →Restart Report.

Reports + Preventative Actions

Telematics Guru has reports available which can be scheduled in order to provide pro-active warning of issues with notifications. 

Partner Send Limit Usage Report

This report can be configured to send with embedded HTML in the email body -so the results appear in the email vs needing to open an attachment.

Additionally, if ‘Send If No Data’ is left unchecked - an email is only sent if the usage threshold is breached. 

This report will give pro-active warning when an organisation is getting close to the limit so that it can be increased or the reason further investigated. 

Scheduled Report Failures Report

If you have a few scheduled reports setup and suspect any are not being delivered, you can run the Scheduled Report Failure report. This report will list all the scheduled report that was not sent after multiple attempts.

It is also worth scheduling this report - to allow for pre-emptive warning. 

Alerts Not Assigned Report

This report returns the count of Recipients and Assets assigned to an alert.

If either is 0, it could point to misconfiguration.