Alarm Policy

The alarm policy is your organization's alarm philosophy, written down in one place. The ISA-18.2 alarm management standard uses that term for a written set of decisions made before the alarms start: what each priority means, how fast someone must answer it, and how much alarm load one person can handle. The Alarm policy page is where you record those decisions in Fleetera.

Each organization has exactly one policy. Until someone saves it, the page shows the standard defaults, which are the values listed on this page.

Most of the policy is guidance and starting values. Three settings under Notification pacing act on live notifications for every rule, so read that part before you change them.

Open the alarm policy

In the Insight space, choose Alerts under Monitor, then choose Policy in the Alerts sidebar. The page is titled Alarm policy.

Anyone who can see Alerts can open the page. The line under the heading tells you where the policy stands:

• Standard defaults. Not yet saved for your organization. Nobody has saved a policy yet.
• Version followed by a number, when it last changed and who changed it. Your organization has a saved policy, and the number goes up with each saved change.

The page has four sections, in this order.

Priorities

Fleetera alerts carry one of three priorities: Critical, Warning and Info. For each one you set three fields.

The standard defaults:

Rewrite the meanings in your own words. They are most useful when an operator on shift can read one and know what to do.

Rule defaults

This section has two parts, and they behave differently.

New rules start with

These are the values the rule editor fills in when someone creates a new rule. The author can still change them in the editor. Existing rules keep their own values, so changing a default here never changes a rule that already exists.

The checkbox Alerts wait for acknowledgement sets the starting value for new rules of every type: a new rule keeps its alert open after the condition clears, until someone acknowledges it. On a pattern rule, the auto-close time starts counting after that. Existing rules keep their own setting. It is off by default.

A band of hysteresis and a duration are the usual cures for a noisy rule. If your team keeps adding them by hand, setting them here saves the step on every new rule.

Notification pacing

Unlike the values above, these three apply to every rule, not only new ones. They change how often your team gets notified.

A routing policy that sets its own Repeat interval (seconds) (under Notifications, Routing) takes precedence over this value for the alerts it routes.

When an alert chatters

An alert that clears and re-triggers over and over is called chattering. With the standard values, once an alert triggers more than 5 times within 1 hour, its further trigger notifications are held. Nothing else stops:

• Fleetera keeps evaluating the rule, and the alert stays visible in the app.
• The alert's row in Events carries a Chattering badge while its notifications are held.
• The rule's row in Rules carries a Chattering badge. Hover it to see how many asset and variable pairs are over the budget, how many times the worst one triggered, and the budget and window it was counted against.
• Delivery resumes on its own once the rule settles.

The badge's advice is to fix the rule itself: give it hysteresis or a duration condition so it stops clearing and re-breaching.

Performance targets

The alarm load one operator position should handle, and the point where it becomes a flood. Every field takes a whole number except Top ten share (percent), which also takes decimals.

Under Priority mix (percent) you set the share of all alarms each priority should make up. The three values are whole percentages and must add up to 100. The page shows the running total as you type. The standard mix is Critical 5, Warning 15 and Info 80.

The standard targets are the figures ISA-18.2 gives for a single operator position.

Control-rule alerts

Control rules are standing controls that fire on purpose, to prove alerting is working.

This section records whether your organization's default view of alerts should leave control-rule alerts out. Choose one of two options:

• Hide control-rule alerts (the standard default)
• Show control-rule alerts

Who can change the policy

Members with the Admin role can edit and save the policy. Operator and Viewer members can open the page and read every value, but the fields are read-only and there is no save button. The page tells them: "You can view this policy. Organization admins can change it."

Save a change

1. Change the fields you need. A field outside its allowed range, or a priority mix that does not add up to 100, shows the problem under the field.
2. Optionally, fill in Reason for change (optional), up to 1,000 characters. It is kept with this version of the policy.
3. Choose Save policy.

Save policy stays disabled until you have changed something in the policy and every field is valid. Typing a reason on its own does not count as a change.

Each save stores the whole policy, every section exactly as the page shows it, as a new version. The version number on the page goes up by one, and the line under the heading shows who made the change and when. Earlier versions are kept.

Settings under New rules start with apply the next time someone creates a rule. Settings under Notification pacing apply to the notifications of every rule, existing ones included. A new repeat interval applies to notification groups that open after the save. A group holds the alerts of one rule at one severity, across all its assets, so an alert that joins a group that is already open keeps that group's interval.