I spent a week with the Galaxy Watch Ultra 2: Why can't I see my workout stats?

I put the Galaxy Watch Ultra 2 on my wrist expecting a deluge of fitness metrics. But after a 10‑mile trail run all I found was a blank dashboard and a sinking feeling that something upstream was eating my data. Beneath the polished hardware of the Galaxy Watch Ultra 2 lies a data pipeline that struggles with the most fundamental expectation: consistent workout telemetry. As a senior engineer who spends days debugging distributed systems, I couldn't just shrug and move on-I needed to trace exactly where those lost statistics went.

Wearables have become miniature edge computers, packing accelerometers, gyroscopes, PPG sensors, barometers. And GPS receivers into a device thinner than a stack of quarters. They generate per‑second observations that must be fused, timestamped, encrypted. And reliably shipped to a companion app, all while running on a constrained real‑time operating system. When you can't see your workout stats, you're not facing a "broken feature"-you're witnessing a failure in a multi‑hop telemetry pipeline that spans firmware, mobile SDKs, cloud sync and authorization layers. This article unpacks that pipeline through the lens of reliability engineering and shows why the Watch Ultra 2 sometimes forgets how hard you worked.

The Promising Hardware Meets a Fragile Data Layer

The Galaxy Watch Ultra 2 ships with a 3nm Exynos W1000 processor, dual‑frequency GPS, and a bio‑active sensor array that can track heart rate, blood oxygen, and even skin temperature overnight. From an electrical engineering standpoint, it's a marvel: 16 GB of storage, 2 GB of RAM. And a 590 mAh battery all packed into an IP68 / 10 ATM chassis. Yet none of that silicon matters if the software pipeline that turns raw ADC readings into a clean workout summary can't guarantee delivery.

In production environments, we measure every microservice's exactly‑once delivery guarantee, but consumer wearables often rely on best‑effort sync protocols hidden behind a simple "Sync now" button. When the data layer fails silently-perhaps because a SQLite journal in the companion app couldn't flush. Or a cloud API returned a 503 with no retry-the user sees nothing. On a recent seven‑day wearing trial, I recorded 12 distinct aerobic sessions; exactly four of them failed to propagate heart‑rate zone breakdowns to the Samsung Health timeline, leaving only a bare‑bones duration and average BPM without the drill‑down graphs that the watch's own AMOLED screen had shown during the workout.

How SAMSUNG Health Orchestrates Fitness Data on Watch Ultra 2

Samsung Health acts as both the recording engine on the watch and the aggregation hub on the paired phone. When you start a run, the One UI Watch launcher forks a foreground service that subscribes to sensor events through the Android Sensor HAL. Each sensor reading-accelerometer at 50 Hz, heart rate at 1 Hz, GPS at 1 Hz-gets buffered into a local SQLite database, typically /data/data/com samsung, and androidshealth/shared_prefs on the watch. After the session ends, a reconciliation job merges the raw frames into a structured workout record.

That record isn't a single blob; it's a collection of segments, laps, and derived metrics like VO₂max estimates - anaerobic effect. And training load, all computed by Samsung's on‑device machine learning models. If any segment's computation throws an uncaught exception-say, the GNSS module lost fix mid‑session and left a null lat/lng array-the entire workout may be demoted to a "summary only" entry in the phone app, stripping away the detailed charts you expect. Developers can peek into this behavior via the Samsung Health SDK. Though the internal logic that decides whether a workout is "enriched" or "bare" remains largely undocumented.

The Missing Stats: A Case Study in Telemetry Inconsistencies

To reproduce the problem, I instrumented a controlled treadmill session while capturing BLE logs from the paired Galaxy S24. The watch recorded 45 minutes of continuous data: heart rate oscillated between 135 and 162 bpm, step cadence averaged 84 spm. And estimated calorie burn reached 520 kcal. On the watch, the post‑workout summary displayed all these metrics with per‑minute granularity. Yet after the sync triggered, the phone's Samsung Health showed only "Duration: 45m, Avg HR: 148," with a greyed‑out "View details" button that led to an empty canvas.

Digging through the phone's logcat with adb logcat -s HealthService:S revealed a curious error: "segment_key_not_found" when the cloud uploader tried to reconstruct the activity segment tree. This points to a schema mismatch between the on‑watch data model and the cloud‑backed representation stored in Samsung's GraphQL API. In distributed systems parlance, this is a contract drift-the producer and consumer disagree on the structure of the payload. Without a public changelog for Samsung's internal health models, users can only hope a future firmware update realigns those contracts.

Sensor Fusion and Data Integrity: Where the Pipeline Breaks

Modern sports watches fuse accelerometer, gyroscope. And GPS data through a Kalman filter to produce smooth pace and distance estimates. The Galaxy Watch Ultra 2 leverages Samsung's BioActive Sensor and dual‑frequency L1+L5 GPS. Which in theory can deliver sub‑3‑meter accuracy. However, the fusion algorithm runs entirely on‑device and its output must be serialized into a compact protobuf for transmission-any truncation or version mismatch can drop the fused track.

During an interval sprint workout, I noticed the watch displayed pace and lap splits in real time but the phone sync lost all lap markers, collapsing the session into one monolithic block. The culprit appears to be the lap‑segmentation metadata that the fusion engine emits as an array of LapSegment objects. If even one lap object contains a NaN value (common when GPS briefly glitches), the Samsung Health phone app's validator may reject the entire array rather than gracefully skipping the offending segment. This "all‑or‑nothing" validation strategy mirrors what I've seen in poorly‑designed ingest pipelines where a single bad record poisons a whole batch.

Health Connect API: The Bridge That Sometimes Collapses

Google's Health Connect API is supposed to be the universal translator between Samsung Health, Google Fit, Strava. And third‑party fitness apps. On the Galaxy Watch Ultra 2, Samsung Health can optionally push workout records into Health Connect, which then exposes them to any app with the appropriate permissions. This layer adds at least two extra serialization hops: Samsung Health's internal format → Android FHIR‑inspired data types → Health Connect SQLite store → target app's format.

Each hop introduces the possibility of data loss. For example, Health Connect's ExerciseSessionRecord requires a Route object to carry GPS track points. If Samsung Health omits the route because it deemed the workout "indoor," but the user later wants to see heart‑rate zones in a third‑party app that expects a route, the record may be silently dropped by that app's importer. I confirmed this by querying Health Connect's database on a test device using content://com. And googleandroid apps healthdata/exercise_session and finding only six of my twelve workouts present.

Observability Lessons: What Wearables Can Learn from Site Reliability Engineering

If the Watch Ultra 2's data pipeline were a microservice, we'd instrument it with OpenTelemetry spans and expose Prometheus metrics like workout_sync_errors_total and segment_validated_latency. Instead, the only "observability" consumers get is a cheerful "Sync completed" toast that appears even when data silently disappears. There's no status page, no structured error codes displayed. And certainly no retry queue visible to the user.

Adopting even a lightweight SRE posture would transform the user experience. A wearable could surface sync health with a simple traffic‑light indicator-green for "last workout fully synced with full metrics," yellow for "summary only," red for "sync paused. " Samsung already stores per‑workout sync state in its backend; exposing a subset of that metadata through a privacy‑preserving API (perhaps as part of the Samsung Health SDK) would let developers build their own dashboards. Until then, power users are left running adb shell dumpsys activity service com samsung, and androidshealth just to understand whether their data is safe.

The Developer's View: Samsung Health SDK and Debugging Sync Failures

Third‑party developers who want to read workout data from Samsung Health can use the Samsung Health SDK's DataReader interface. The SDK abstracts away cloud sync and presents a unified stream of HealthData objects. But it inherits the same reliability issues. When a workout is marked "summary only" on the backend, querying for Exercise data returns only the basic fields-duration, average heart rate, calorie count-while the SessionGroup array that contains lap splits and heart‑rate zones is null.

To diagnose missing segments, I built a small Kotlin utility that periodically polls Samsung Health via content resolver URIs on a rooted companion phone. The utility revealed that once a workout enters the "summary only" state, even re‑triggering a manual sync doesn't repair the record; the backend appears to cache the stripped version indefinitely. This suggests that the watch‑to‑phone sync protocol lacks a robust reconciliation mechanism, akin to a lack of vector clocks or conflict‑free replicated data types (CRDTs). Without such a mechanism, the system will always favor the cloud's schema over the richer on‑device representation.

Privacy Permissions and Their Unintended Consequences on Workout Logging

On Android 14, apps must request precise location permission (ACCESS_FINE_LOCATION) to record GPS track points in background. Samsung Health handles this correctly. But Samsung's One UI Watch adds an additional toggle: "Share data with Samsung Health on phone. " If a user inadvertently disables this toggle-perhaps in a misguided attempt to save battery-the watch will still record workouts locally and show live metrics, but the sync service will strip all location‑derived metrics before sending the record to the phone.

During my testing, I found three instances where the missing workout stats coincided with a mismatch between the watch's "Health platform" permissions and the phone's "Health data sharing" settings. The watch OS offers no upfront warning that certain charts depend on the permission constellation being perfectly aligned. This is reminiscent of the "permission‑denied" errors that plague cloud‑native applications when IAM roles are out of sync, and it underscores the need for wearable