I want to raise a serious concern about Garmin’s current direction with Lactate Threshold Heart Rate detection.
For years, one of the most useful features for serious runners was the Guided Lactate Threshold Test. It was not perfect, but it had one major advantage: control. You could perform it when fresh, on flat terrain, with a chest strap, under repeatable conditions. That made the result meaningful, because the test was based on a deliberate ramp effort rather than background interpretation of unrelated training sessions.
The newer passive auto-detection system may be convenient, but in my experience it can be significantly misleading, especially during structured training blocks.
1. Passive detection is not the same as a controlled test
LTHR is not just another background metric. It depends on context: fatigue, terrain, heat, session type, recovery structure, and current training load.
A controlled threshold test attempts to isolate those variables. Passive detection does not. It may be looking at easy runs, hilly routes, trail runs, interval sessions, recovery periods, and long runs, then trying to infer a physiological breakpoint from mixed data.
That may work reasonably well for some users, but for athletes following structured training, it can become unreliable.
2. Structured workouts can distort the algorithm
During a proper training block, many runners perform workouts with deliberate recovery intervals. For example, threshold work, VO2max intervals, or quality sessions may include walking or easy jogging recoveries to clear fatigue before the next repetition.
Those recoveries are intentional. They are part of the workout design.
The problem is that passive detection may not correctly understand this context. It can see pace dropping and heart rate recovering, then interpret the session as reduced sustainable performance, even though the athlete is executing the session exactly as planned.
This can lead to large and unrealistic shifts in detected threshold pace or heart rate.
3. Good hardware data does not solve bad interpretation
Many of us use Garmin chest straps such as HRM-Tri, HRM-Pro, or similar devices. That means the heart-rate data itself is high quality.
But accurate input data is not enough if the algorithm misinterprets the session structure.
A chest strap can provide excellent heart-rate data, but if the software treats planned recovery intervals as signs of reduced fitness, then the final LTHR estimate can still be wrong.
4. The Safety Paradox: This Is Becoming a Liability Concern
I understand that LTHR is dynamic. It changes with fitness, fatigue, heat, detraining, and recovery. I also understand why Garmin may want to protect users from relying on outdated threshold values after inactivity, illness, or injury.
But replacing a controlled test with a passive algorithm creates a different risk.
An experienced competitive runner may question a sudden, unrealistic LTHR drop. They may compare it against recent workouts, race performances, perceived effort, and controlled field tests. But many ambitious runners are not experienced enough to make that distinction. They trust the device.
That is where the risk begins.
If the watch aggressively underestimates LTHR because it misreads structured recovery intervals, hilly runs, fatigue, heat, or workout design, an inexperienced but driven runner may accept the new value as truth. They may then alter their training zones, push unnecessarily hard to “prove” fitness back to the watch, or lose confidence in a training block that is actually working.
That is not safer. It can encourage inappropriate intensity, distorted training zones, and poor training decisions.
This is where the issue stops being a minor software inconvenience and becomes a potential liability concern. Garmin has taken a metric that directly influences training intensity and removed the user’s best controlled validation tool. Even if the user can accept or reject an automated LTHR change, that choice is incomplete if Garmin does not also provide a controlled Guided Test to verify the new value.
If an automated system produces materially wrong thresholds and guides less experienced athletes into inappropriate training behavior, that is not just a bad user experience. It is a product-risk issue.
5. Passive detection should not replace controlled validation
I am not arguing that passive LTHR detection should be removed. It can be useful. It may help casual users, returning athletes, or runners who never perform structured tests.
The problem is that passive detection should not replace a controlled validation option.
Yes, Garmin may allow the user to accept or reject a newly detected threshold value. But that is not enough. Accepting or rejecting a number is not the same as having a proper way to verify it.
When Garmin upgrades or downgrades an athlete’s LTHR, the athlete should have immediate access to the Guided Lactate Threshold Test to confirm or reject the new value under controlled conditions. That is the missing piece.
Garmin should provide:
- The return of the Guided Lactate Threshold Test on all compatible newer devices.
- A direct “Confirm with Guided Test” option whenever LTHR is upgraded or downgraded.
- A setting to ignore certain workout types from LTHR detection.
- Better handling of structured intervals and planned recovery periods.
- Clearer explanation of why an LTHR change was made.
The current passive system may be convenient, but LTHR is too important to be treated as a hidden background estimate without controlled verification.
Garmin has excellent hardware. The chest straps work. The watches collect useful data. But the interpretation layer needs user control, transparency, and validation.
For serious training, Garmin should not force athletes to choose blindly between trusting or rejecting an automated estimate. Give users back the ability to test, validate, and control the metric that defines their training zones.
