Alerts are designed to notify the right people on your team of a potential issue with a machine so they can act quickly to address it before it impacts production. To make sure that your team takes action on alerts, it’s important to follow best practices so they aren’t overwhelmed by the number of alerts they receive. This article will help you design a winning alert strategy.

Who should set up your alerts?

Here are some examples of typical situations where users use alerts to help them quickly identify issues and take action to address them.

Example 1:

Here is an example of a dip in runtime for Machine 8.

If you saw this dip for one of your machines, would you want to be notified when the machine is idling for more than the standard changeover time which is 10 minutes?

How many minutes after the machine stops running for more than the standard changeover time should someone get notified?

Who should get notified first?

If this issue remains unresolved after 15 minutes, who should be notified?

Example 2:

Here is an example of Extruder 5’s runtime going beyond it’s upper threshold.

If you saw one of your machines was overloaded, would you want to be notified?

How many minutes after a machine overload is detected should someone get notified?

Who should get notified first?

If this issue remains unresolved after 15 minutes, who should be notified? What about if the issue is still unresolved after 30 minutes?

To answer these questions, follow the best practices listed below.

1. Only send alerts during working hours

Alerts sent to team members outside of hours when they’re working or on-call are just noise. To make sure that the team takes alerts seriously and takes action when they receive an alert, configure alerts only during working hours.

The best way to do this is to define an Alert Window for each alert so it’s only sent to team members during times when they need to know about it.

2. Create one alert for each shift

To ensure you only send alerts during working hours, create a separate alert for each shift.

For example, if you want to alert a team member when machine 1 has been down for 5 minutes, create one instance of this alert for each shift. Creating one alert per shift will allow you to set up the alert with the first shift alert window so that it only notifies the people who work during the first shift.

Do the same for the second shift alert window so that it only notifies people who work during the second shift. This will ensure issues are relevant to the right people at the right time.

3. Set up an escalation path

Alerts should be received by a teammate who will address the issue and can escalate up the chain of command if the problem remains unresolved.

Teams typically set up escalation paths in the following way:

4. Use multiple alert notifications sparingly

You can set up an alert to notify a team member up to 5 times about the same issue using the “alert every” dropdown. It may seem that notifying a team member multiple times about an issue will create a sense of urgency. However, be cautious as we’ve noticed the opposite effect. If a user receives too many notifications, they tend to ignore them and critical issues go unresolved.

5. Preview alerts before they go live

When setting an alert window, always click “Show Preview.” This shows you how many issues this alert would have created in the last 72 hours so you can validate you’ve set it up correctly.

If the alert would create too many issues and potentially too many alert notifications for any member of your team, adjust the alert settings to reduce the noise.

6. Only setup alerts for times when a machine is expected to run

Schedule planned downtime using the Planned Downtime feature. This is an Issue that must be created manually and once set up, will ensure that no Alerts are sent during periods when a machine is expected to be down for planned maintenance, no business, or any other scheduled downtime.

7. Aim to send no more than 10 alerts to a user during their shift

We have seen that when a team member receives more than 10 alerts in a shift they begin to tune them out. Review your alerts periodically to ensure you’re below this threshold.

It’s also a good idea to ask your team how many alerts they receive, on average, during a shift, to keep a pulse on this.