Temperature Alert
What It Does
The Temperature Alert monitors your equipment's temperature sensors and notifies you when a reading falls outside the range you define. You set a low limit and/or a high limit for each sensor — if a reading drops to or below your low limit, or reaches or exceeds your high limit, you'll receive a notification.
Available Sensors
You can configure thresholds for up to 8 temperature sensors:
Trigger | Range |
Ambient Air | - 273 C to 1734 C |
Engine Air Intake | - 40 C to 210 C |
Engine Coolant | - 40 C to 210 C |
Engine Fuel | - 40 C to 210 C |
Engine Intercooler | - 40 C to 210 C |
Engine Oil | - 273 C to 1734 C |
Engine Turbocharger Oil | - 273 C to 1734 C |
Transmission Oil | - 273 C to 1734 C |
How to Use It
Navigate to Manage > Alerts > Create Alerts
Select Temperature as the notification type
Assign the assets you want to monitor
For each sensor you want to track, enter a Low Limit, a High Limit, or both
Leave a sensor's fields blank if you don't want to monitor it
Configure your recipients and schedule as usual
Temperature Sensor Definitions
Sensor Name | Definition |
Ambient Air Temperature | The outside air temperature surrounding the equipment, measured by the vehicle's onboard sensor. Useful for monitoring environmental conditions that may affect engine performance or operator comfort. |
Engine Air Intake Temperature | The temperature of air entering the engine's intake manifold. High intake temps reduce engine efficiency and power output; monitoring helps detect clogged air filters or intercooler issues. |
Engine Coolant Temperature | The temperature of the liquid coolant circulating through the engine block. This is the most commonly reported sensor — overheating here indicates cooling system failures (low coolant, bad thermostat, radiator blockage). |
Engine Fuel Temperature | The temperature of fuel before it enters the injection system. Excessively hot fuel can reduce power and fuel economy; excessively cold fuel can cause starting or atomization issues in diesel engines. |
Engine Intercooler Temperature | The temperature of compressed air after it passes through the intercooler (charge air cooler). The intercooler cools turbo-compressed air before it enters the engine — high readings indicate a failing or clogged intercooler. |
Engine Oil Temperature | The temperature of the engine's lubricating oil. Oil that's too hot loses viscosity and protective properties; oil that's too cold may not flow properly. Monitors overall engine thermal health. |
Engine Turbocharger Oil Temperature | The temperature of oil lubricating the turbocharger bearings. Turbochargers operate at extreme temperatures — elevated readings can indicate bearing wear, oil starvation, or impending turbo failure. |
Transmission Oil Temperature | The temperature of the transmission fluid/oil. Overheating transmission fluid breaks down rapidly, leading to accelerated wear, slipping, and potential transmission failure — especially common under heavy load or towing. |
Important Details
Units — Temperature values follow your account's unit setting. If your account uses metric, values are in Celsius. If your account uses standard/imperial, values are in Fahrenheit. Due to internal conversion rounding, displayed values may vary by ±1 degree.
All 8 sensors are shown on the configuration form regardless of which sensors your specific equipment reports. The notification will only trigger for sensors that are both configured with a limit AND actively reporting data.
Stale data protection — If a sensor hasn't reported a reading in the last 60 minutes, it will not trigger a notification. This prevents false alerts from outdated data.
You only need to configure the sensors you care about — any sensor row left blank is simply ignored.
FleetWatcher Device Compatibility — New Alerts
Alert Type | Required Data | Compatible Devices | Not Compatible |
Temperature | CAN bus temp sensors | GS-364/364e, jPOD, WirelessLinks, SAMSARA — any J1939/J1708/OBD-II device | GS-303, GS-283, any GPS-only device |
Excessive Idle | Idle Timer | GS-364/364e, jPOD, WirelessLinks, SAMSARA, possibly GS-303 | Devices without Idle bucket configured |
Key takeaways for the customer:
Temperature requires a wired diagnostic connection (J1939, J1708, or OBD-II) to read engine sensor data. GPS-only devices like the GS-303 and GS-283 cannot support this alert.
Excessive Idle has broader compatibility since idle detection is a more basic data point. Even the GS-303 may support it if the Idle bucket is configured for that device.
SAMSARA integration devices support both alerts.
Not every temperature sensor will be available on every asset — it depends on what the vehicle's CAN bus publishes.
Temperature Alert — Troubleshooting
"The customer says the notification never fires even though the equipment is running hot."
Check these in order:
Is the sensor actually reporting? Look in the EqBucket table for the device — does a row exist for the sensor in question? If the equipment doesn't report that sensor type, the notification will never trigger regardless of configuration.
Is the reading stale? The sensor's last reading must be within the last 60 minutes. If lastupdatedt is older than 60 minutes, it's treated as stale and won't fire. This is by design to prevent false alerts on parked/offline equipment.
Did the customer configure the correct sensor row? All 8 sensors display on the form even if the asset only reports 2–3 of them. Confirm the customer entered limits on the row that matches what their equipment actually reports.
Are the limits set in the right direction? Low Limit triggers at ≤ the value, High Limit triggers at ≥ the value. A customer wanting a "high temp" alert needs to populate the High Limit field, not the Low Limit.
"The customer says the alert fired but the temperature shown doesn't match what they configured."
Root cause: Unit conversion rounding.
Values are stored internally in Celsius regardless of the customer's unit preference.
When a customer enters a Fahrenheit value, it's converted to Celsius for storage, then converted back for display.
This can introduce ±1 degree variance (e.g., customer enters 180°F → stored as 82.2°C → displays back as 181°F).
This is expected behavior. Advise the customer that a 1-degree variance is normal due to rounding.
"The customer asks where the C/F toggle is."
The new notification UI does not have an explicit Celsius/Fahrenheit toggle like the old Alert Manager did. The system uses the customer's account-level unit setting (is_metric). If they need to change units, it's an account-level setting change, not a per-notification option.
"Customer entered a limit but used a decimal or scientific notation (e.g., 1e2)."
The e character issue in numeric fields has been fixed in dev. If a customer reports this on an older build, confirm they're on FW 2026.15.0 or later. Limits should be entered as whole numbers or standard decimals only.
"Customer wants to monitor only 2 sensors but is confused by all 8 showing."
This is by design. All 8 sensor rows always render. Advise the customer to simply leave the rows blank for sensors they don't care about — blank rows are completely ignored by the system.
Excessive Idle Alert
What It Does
The Excessive Idle Alert notifies you when a piece of equipment has been idling continuously for longer than a threshold you define (in minutes). This helps you identify assets wasting fuel or operating inefficiently in real time.
How to Use It
Navigate to Manage > Alerts > Create Alerts
Select Excessive Idle as the notification type
Assign the assets you want to monitor
Supp Timer: Checkbox 1: "Selecting a Supp Timer will cause the alert to trigger only if the engine is Idle AND the Supp Timer is also Idle for the same time period".
What causes the Supp Timer to idle: The Supp Timer is driven by a separate hardwired digital input on the tracking device, “internally called the "Blue Wire", that's wired into a specific auxiliary component on the equipment, most commonly the PTO (Power Take-Off). When that wired component is not engaged (switch open, no signal), the Supp Timer is idle. When it is engaged, the Supp Timer counts as active, independent of whether the vehicle/equipment engine itself is idling or moving. That's why the Supp Timer setting on the Excessive Idle alert exists: it lets the alert distinguish "truly doing nothing" from "stopped, but running something productive via PTO."
How It Works
The system checks whether the asset is currently in an idle state
It then verifies that the asset has been idling continuously (not on-and-off) for at least the number of minutes you specified
If both conditions are true, the notification fires
Setting Up Tiered Alerts
If you want escalating notifications (e.g., a warning at 15 minutes, another at 30 minutes, and a final alert at 60 minutes), you can create multiple Excessive Idle notifications with increasing thresholds:
Notification | Threshold | Notification Time Limit |
Tier 1 (initial warning) | 15 minutes | Less than 20 minutes |
Tier 2 (escalation) | 20 minutes | Less than 30 minutes |
Tier 3 (critical) | 30 minutes | (none — repeats until idle stops) |
By adding a "Notification time limit" condition with a "less than" value on lower tiers, each tier stops firing once the next tier takes over. The highest tier continues to alert until the equipment stops idling.
Important Details
Continuous idle only — Intermittent idling (idle, move, idle, move) will NOT trigger this alert. The equipment must be idling without interruption for the full threshold duration.
The asset must have an active idle timer reporting data for this notification to work.
Threshold is in minutes — enter whole numbers representing the minimum continuous idle time before you want to be alerted.
Excessive Idle Alert — Troubleshooting
"The customer says the notification never fires even though the asset has been idling for hours."
Check these in order:
Does the asset have an Idle Timer bucket? Query EqBucket for the device and confirm a row exists with BucketId = 13. If there's no Idle bucket configured for that device, this notification cannot work.
Is the bucket actively reporting? Check lastupdatedt on the BucketId 13 row. If it's stale (older than the configured threshold window from current time), Gate 1 fails and the notification won't fire.
Is the idle continuous? The system verifies that idle time accrued at the same pace as wall-clock time elapsed. If the asset idled for 5 min, moved for 1 min, then idled for 10 min, that does NOT count as 15 continuous minutes. The counter resets on any movement.
Check the threshold value — confirm the customer entered the value in minutes, not hours or seconds.
"The customer says the alert fires too frequently / keeps repeating."
If they have a single notification: The notification will re-fire on each evaluation cycle as long as the continuous idle condition remains true. This is expected — the alert repeats until the equipment stops idling.
If they want it to fire only once: They should add a "Notification time limit" condition. For example, setting a "less than 30 minutes" limit on a 15-minute threshold notification means it will only fire while idle time is between 15–29 minutes, then stop.
"The customer set up tiered alerts but all tiers fire at the same time."
Common misconfiguration: The customer likely forgot to add the "Notification time limit (minutes)" condition with "less than" on the lower tiers.
Correct setup:
Tier 1 (15 min threshold) → Add time limit: less than 20 minutes
Tier 2 (20 min threshold) → Add time limit: less than 30 minutes
Tier 3 (30 min threshold) → No time limit (repeats until idle stops)
Without the time limit condition, all tiers will fire simultaneously once the highest threshold is exceeded.
"The customer says the old Excessive Idle alert worked but the new one doesn't trigger for the same asset."
Key architectural difference: The legacy alert (TypeId 3) may have used Eqactivitymast / WhyId logic. The new implementation uses only BucketId 13 (Idle Timer) data from EqBucket and EqBucketTotal.
If the asset reported idle state through activity records but doesn't have an active BucketId 13 entry, the new notification won't detect it. Confirm the asset has an Idle Timer bucket configured and reporting.
"What's the 1-minute tolerance mentioned in the implementation?"
The system allows a 1-minute sampling tolerance when verifying continuous idle. This prevents false negatives caused by slight gaps in discrete data sampling (e.g., if data reports every 30 seconds and one sample is slightly delayed). Support does not need to expose this to customers — it's an internal safety margin.
General Troubleshooting (Both Types)
"Customer migrated from old Alert Manager — where did their alerts go?"
These are new notification types in the modern notification system. Legacy alerts from the old Alert Manager are not automatically migrated. Customers need to recreate their temperature and excessive idle alerts as new notifications.
"The notification is configured but the customer receives no SMS/email."
This is not specific to these notification types — check standard notification delivery troubleshooting:
Are recipients configured correctly?
Is the schedule active for the current time?
Are SMS/email delivery services operational?
Is the asset assigned to the notification?