Self-healing asset tracking: how automation reduced field interventions by 80%

Trackers rarely fail all at once. More often, they continue reporting while gradually losing the data quality that fleet operations depend on. This case study shows how one container terminal automated device recovery with the Device Health Check template in Navixy IoT Logic, reducing manual recovery work by 80%, and how the same approach can evolve into a much richer device health monitoring framework.

When trackers stay online but stop being reliable

In telematics, online doesn't always mean healthy. A tracker may continue sending data while gradually losing the ability to produce reliable positioning, report stable power, or communicate consistently. Dispatchers still see the vehicle. Maintenance teams still receive telemetry. Yet sooner or later someone has to answer a familiar question: Does this tracker simply need a reboot, or is there a real hardware problem behind the symptoms?

Answering that question manually for every suspicious device quickly becomes routine work in large fleets. The challenge isn't that trackers occasionally misbehave. Every deployment sees that. The challenge is recognising those situations consistently and responding before they become support tickets or unnecessary field visits.

Automation changes that process. Incoming telemetry can be evaluated continuously, unhealthy devices identified automatically, and the first recovery step performed without waiting for human intervention. Technicians are then left with the cases automation cannot solve, which is usually where their expertise creates the most value.

Learn more about ready-made automations with IoT Logic:

• Automated idling response
• Driver access control

Device health automation without starting from scratch

Building that kind of workflow isn't particularly difficult. It is, however, repetitive. Every implementation needs to receive telemetry, evaluate device health, decide whether recovery is required, execute the appropriate action, and continue processing.

The Device Health Check template in Navixy IoT Logic already provides that workflow. Rather than designing the logic from scratch, engineers can adapt the health conditions and recovery actions to match their devices and operating environment.

At a high level, the workflow remains the same regardless of the fleet:

1. Receive incoming telemetry.
2. Evaluate the configured health conditions.
3. Continue normal processing if the device is healthy.
4. Execute the configured recovery actions if it is not.

The template is designed to be adapted, not deployed unchanged. Different fleets experience different failure modes, use different hardware, and define "healthy" differently. The workflow stays the same while the health model evolves.

Case study: adapting the template for port terminal vehicles

A mid-sized container terminal operated a mixed fleet of terminal tractors, reach stackers, container handlers, forklifts, and service vehicles.

The fleet used Teltonika GPS trackers capable of external power monitoring, configurable telemetry, CAN integration, and remote command execution. Although this case focuses on Teltonika hardware, the overall approach applies to any tracker that supports remote management.

The deployment covered powered vehicles that report telemetry continuously and can receive remote commands. Battery-powered asset trackers operating in deep sleep mode require a different monitoring strategy.

The operational challenge

The maintenance team kept encountering the same pattern. A tracker appeared to be behaving unusually. It was still online, but something wasn't right. GNSS reception degraded between container stacks. External power became unstable after servicing. Sometimes the tracker simply stopped producing reliable positioning data while remaining connected to the platform.

Every case followed essentially the same process. Someone reviewed the telemetry, decided whether a remote reboot was worth trying, sent the command, and then checked whether the device returned to normal operation or required physical inspection.

None of those individual incidents justified a software project. Taken together, however, they represented a steady stream of routine maintenance work that consumed engineering time without adding much value.

Starting with the standard Device Health Check template

Rather than building a custom workflow, the team started with the standard Device Health Check template included with Navixy IoT Logic.

Out of the box, the template evaluates four basic health conditions:

latitude != null &&
longitude != null &&
satellites >= 4 &&
board_voltage >= 11.5

If the expression evaluates to TRUE, telemetry continues through the normal processing path.

If it evaluates to FALSE, telemetry is still forwarded while the workflow also executes the configured recovery action. The standard template includes reboot actions for both Teltonika (cpureset) and Jimi/Concox (RESET#) devices, allowing it to support different hardware families from the outset.

Because the terminal fleet consisted exclusively of Teltonika devices, the team simply removed the Jimi reboot node and kept the Teltonika recovery action.

The health check itself required only three adjustments. The generic board_voltage parameter was replaced with the Teltonika-specific external_voltage attribute. The satellite threshold increased from four to five satellites. Finally, the team added an HDOP condition to improve GNSS validation in an environment where cranes, container stacks, and plenty of steel make satellite reception, as every port engineer knows, a little unpredictable.

The resulting health condition became:

external_voltage >= 11.5 &&
latitude != null &&
longitude != null &&
satellites >= 5 &&
(hdop == null || hdop < 2.5)

Everything else remained unchanged.

What's the outcome?

The 90-day pilot reduced manual tracker recovery interventions by approximately 80%. More importantly, it changed the maintenance workflow itself. Devices that matched the predefined recovery criteria were restarted automatically, often before anyone noticed the issue. Maintenance teams only became involved when automated recovery failed or when the health conditions suggested a hardware problem rather than a temporary software issue.

Routine reboot requests all but disappeared. Technicians spent less time reviewing telemetry that ultimately led to the same recovery action, while field visits increasingly focused on genuine hardware faults such as damaged antennas, unstable wiring, or power issues. Automation didn't eliminate maintenance work. It eliminated maintenance work that didn't require human judgement.

The implementation described above is intentionally straightforward, and for many fleets that level of automation is enough to deliver immediate value.

Port terminals, however, are among the most demanding environments for telematics devices. Looking more closely at those operating conditions reveals opportunities to build much richer device health models while still using the same underlying workflow.

Designing a richer device health model

As mentioned, the case study above demonstrates a deliberately simple implementation. With only a few adjustments to the default health conditions, the terminal automated a significant share of routine recovery work.

That naturally leads to the next question. If this much value comes from monitoring four or five parameters, what happens when the health model reflects the operating environment in more detail?

Port terminals provide a good example.

Vehicles spend their days between container stacks, cranes, warehouses, and large steel structures. GNSS conditions change constantly. Wiring is exposed to vibration. Power interruptions occur during servicing. CAN communication can disappear even though the tracker itself remains online.

None of these situations necessarily indicates a faulty tracker. Together, however, they provide a much more complete picture of device health than latitude, longitude, satellite count, and voltage alone. Rather than redesigning the workflow, engineers simply expand the health model.

A typical implementation evaluates four groups of parameters.

Health area	Typical parameters
GNSS	Satellite count, HDOP, fix validity, age of last valid position
Power	External voltage, backup battery, ignition state, voltage stability
Communication	Signal quality, reconnect count, packet frequency, time since last communication
Vehicle interface	CAN availability, freshness of engine data, digital inputs

These groups don't represent a universal standard. They represent a practical way of describing the aspects of device behaviour that matter for this type of fleet.

Building the health logic

Once the required telemetry is available, there are two common ways to design the health check.

One approach defines what a healthy tracker looks like.

The If-then node simply evaluates whether the incoming telemetry matches the expected operating conditions.

For example:

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "good" &&
can_available == true

If the expression evaluates to TRUE, the workflow continues normally.

If it evaluates to FALSE, the tracker has drifted outside its expected operating state and the recovery branch takes over.

The second approach starts from the opposite direction.

Instead of describing healthy behaviour, it describes specific failure signatures that should trigger action.

For example:

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "poor" &&
gnss_bad_duration_min > 10

Here, the tracker still has power and remains connected, yet GNSS quality has been poor long enough to suggest that the positioning subsystem needs attention.

In practice, the two approaches work well together.

The health check first answers a simple question:

"Is the tracker healthy?"

If the answer is no, additional rules determine why and select the most appropriate recovery action. Keeping those two decisions separate makes the workflow easier to understand and easier to extend as new failure patterns emerge.

When telemetry isn't enough

Designing the health model often exposes another reality.

The parameters you want aren't always the parameters the tracker provides.

Some devices report satellite count but not a meaningful indication of positioning quality. Others provide voltage but not whether the power supply has been stable. A third tracker may expose every communication timestamp but never tell you that communication has become unreliable.

This is where the Initiate Attribute node becomes useful.

Instead of building increasingly complex expressions inside the health check itself, engineers can create higher-level operational attributes before the Device Health Check evaluates the telemetry.

The workflow becomes:

Incoming telemetry
        │
        ▼
Initiate Attribute
(create operational attributes)
        │
        ▼
Device Health Check
        │
        ▼
Recovery actions

Think of the Initiate Attribute node as a translation layer.

Raw telemetry describes what the tracker reports.

Operational attributes describe what those measurements mean.

Example: deriving GNSS quality

Suppose the tracker reports:

• latitude,
• longitude,
• satellite count,
• HDOP.

Rather than evaluating all four measurements throughout the workflow, the Initiate Attribute node can combine them into a single attribute:

gnss_quality

For example:

Input telemetry	Derived value
Missing coordinates	Poor
Satellite count below 5	Poor
HDOP ≥ 4	Poor
HDOP between 2.5 and 4	Degraded
Otherwise	Good

The health check now evaluates:

gnss_quality == "good"

instead of interpreting multiple telemetry values every time a message arrives.

The same principle applies to communication quality, power stability, CAN availability, or any other operational indicator. Once those attributes exist, the health logic becomes easier to read, easier to maintain, and much easier to adapt when the definition of a "healthy" tracker changes.

That's an important distinction.

The workflow doesn't become more complicated.

The understanding of device health becomes more sophisticated, while the workflow itself remains largely unchanged.

A different way to think about device health

The most interesting outcome of this project isn't only the 80% reduction in manual recovery work. It's the shift from asking whether a tracker is online to asking whether its data is still trustworthy.

That distinction matters because modern telematics supports dispatching, maintenance, compliance, utilisation analysis, and operational planning. A connected device can continue reporting while gradually producing incomplete or unreliable data. From the platform's perspective it's online. From an operational perspective, it has already begun to fail.

Device health monitoring changes that conversation. Rather than reacting after someone notices a problem, operators define what "healthy" means for their fleet, monitor those conditions continuously, and automate the first response when a tracker drifts outside them. The Device Health Check template provides a practical starting point for that approach. As requirements evolve, the health model becomes more sophisticated while the underlying workflow remains familiar.

The broader lesson extends well beyond port terminals. Every fleet has its own definition of a healthy device because every fleet depends on different data to keep operations running efficiently. The technology will continue to evolve, but the principle remains the same. Better operational decisions begin with trustworthy telemetry, and trustworthy telemetry begins with understanding device health.

If you're exploring automated device health monitoring for your fleet, contact our team to discuss your use case and explore how this approach could fit into your telematics workflows.