Setting alarm thresholds that people don't ignore
Low-product, high-water, and offline thresholds that catch meaningful conditions without training your team to dismiss notifications. Use the questions below to understand the decision points, evidence, and follow-up work for your operation.
Published Last updated
What makes an alarm threshold useful?
A useful threshold identifies a condition the team understands and can act on. A threshold that activates during ordinary operations becomes noise; one that activates after the response window has disappeared does not support the workflow. The value should come from the real tank, product, operating pattern, delivery process, connection behavior, and response plan rather than a generic number copied from another location.
Begin by separating source ATG alarms from operational notification thresholds. The automatic tank gauge generates its own equipment and tank alarms according to its configuration. A remote-monitoring service may route supported alarm events it receives and expose operational settings such as inventory or offline thresholds. A notification setting does not replace, raise, lower, or certify the ATG manufacturer’s alarm configuration.
A threshold is only one part of the control. The notification needs the correct location and tank context, a reachable recipient, a clear expected action, and an escalation path. If any of those pieces is missing, changing the numeric value alone will not make the process reliable.
How should the action shape the threshold?
- 1Name the condition you need to detect, such as low product, high water, or a location that has stopped reporting, without deciding the value yet.
- 2Assign an owner and write the first action they should take when the notification arrives.
- 3Identify the information the owner needs, including location, tank, product, current status, and relevant contacts.
- 4Review recent operating data and known seasonal or delivery patterns to understand normal variation.
- 5Choose an initial threshold that supports the documented action and response time for that specific location.
- 6Observe the resulting notifications, investigate repeated activations, and adjust only with a recorded reason and owner.
What should guide a low-product threshold?
A low-product threshold should support replenishment or operating decisions before the location reaches an unacceptable condition. Consider typical consumption, variation by day or season, delivery lead time, order process, available product in other tanks, and who can authorize a delivery. Use actual location history where it is reliable; a threshold from a different tank may create either needless orders or too little response time.
Clarify whether the notification is informational, prompts a review, or starts an ordering workflow. That distinction affects recipients and urgency. If consumption changes because of a new customer, product switch, or operating schedule, review the threshold instead of assuming the old value remains useful.
Do not treat an operational low-product threshold as a safety limit or manufacturer setting. Preserve any ATG configuration and required operating limits established by qualified personnel. The operational threshold should complement those controls, not redefine them.
- How quickly can the location consume the remaining inventory under expected variation?
- How long does the approved ordering and delivery process usually need?
- Who reviews the notification, and what information do they need before ordering?
- What changes in product demand or delivery availability should trigger a threshold review?
What should guide high-product and water thresholds?
High-product conditions need to be understood alongside tank capacity, safe operating practices, delivery planning, and the settings maintained on the ATG. An operational notification can provide earlier awareness for a delivery workflow, but its value must be chosen with people who understand the tank and applicable requirements. Do not calculate or publish a generic fill limit from this guide.
Water readings require similar context. Probe behavior, tank geometry, product, equipment instructions, maintenance history, and the organization’s response procedure all matter. Choose any operational threshold with the qualified owner responsible for investigating water and preserving relevant ATG records. A change in the reading may warrant review even when a notification threshold has not been crossed.
For both conditions, define what the recipient should verify before escalating. The response may include checking the source gauge, reviewing recent delivery or service activity, and contacting an authorized operator or service provider. A remote reading is useful evidence, but it should not invite an unqualified person to alter safety-related equipment settings.
How should an offline threshold be chosen?
An offline threshold identifies when expected data has not arrived for long enough to matter operationally. Start with the normal reporting pattern for the connection and the consequences of losing visibility at that location. Tank inventory and status typically refresh every 5–15 minutes depending on ATG configuration, but the appropriate offline escalation still depends on the connection, operating hours, staffing, and monitoring responsibility.
Avoid setting the value solely to eliminate brief interruptions. First decide which missed-data condition should prompt a check and who can investigate the ATG, power, network, VPN, or cellular path. An offline notification does not reveal which component failed, and it does not by itself mean the tanks or source ATG are in an alarm condition.
When reporting resumes, determine whether the interruption was understood and whether any expected source records are missing. Repeated outages should enter a reliability review. Continually widening the offline threshold can hide a connection problem rather than resolve it.
Who should receive each notification?
Route notifications to people who own the documented action. Use organization, role, and location assignments to keep unrelated teams out of the path and to avoid disclosing operational data more broadly than necessary. A distribution list is not effective merely because it contains many addresses; each recipient should know whether they are primary, backup, or informational.
Build escalation for absence as well as response. If the primary owner is unavailable, define who takes over and how a time-sensitive issue is raised. Keep contact information current when staff or service providers change, and test the path using an approved non-emergency process.
Match the message to the recipient. An operator may need the tank and current reading, while an IT contact may need the location and last received time. Avoid sending people data they cannot use or asking a network owner to interpret a tank condition.
How can teams avoid notification fatigue?
Treat repeated notifications as evidence to investigate, not a reason to ignore the channel. Look for a threshold that overlaps normal variation, an unresolved operating condition, duplicate recipient rules, unstable connectivity, incorrect tank mapping, or a response that never closes the underlying issue. Record the cause before changing the value.
Use a regular review to compare notifications with actions. Useful questions include whether the intended owner received the message, whether the condition was real, whether the message arrived with enough context, and whether the chosen threshold created usable response time. Remove obsolete routes and correct configuration errors instead of training staff to filter them mentally.
Avoid broadening a threshold solely to reduce volume when the notifications represent a persistent problem. The appropriate response may be equipment service, network repair, delivery-process change, recipient cleanup, or operator training rather than a different number.
How should threshold changes be governed?
Record the previous value, new value, reason, requester, approver, affected locations, and review owner. Check whether the change is an operational notification setting or a source ATG configuration; changes to manufacturer, safety, or regulatory settings require the appropriate qualified process and should not be made through an informal alert-tuning exercise.
Review a threshold after material changes in tank use, product, delivery practice, consumption, staffing, connectivity, or response ownership. If a value differs across locations, document why. Consistency is useful only when operating conditions are actually comparable.
Product thresholds support an operating workflow. They do not replace ATG manufacturer settings, regulatory limits, required release-response procedures, or a qualified safety review. A well-managed threshold makes responsibility clearer without claiming that one value is universally correct.
How does TankActive help?
For authorized Network Operations users, TankActive exposes an organization low-inventory default, tank-specific overrides, and per-Location offline thresholds. It can route supported high-level alarms, probe-out events, connectivity issues, and low-inventory conditions through configured email rules. Availability still depends on the connected ATG, the data received, account permissions, and the organization’s notification configuration.
These controls support the documented operating workflow; they do not replace source-ATG settings, regulator requirements, or qualified safety decisions. Review the effective value, source labels, current reading time, recipient ownership, and exception rationale before treating a configuration as complete.
How can I put this guide into practice?
Use these product-specific help articles for the matching TankActive workflow.