%25201.png)
Key Takeaways
- Open Wearables now stores day and session values, such as a day's steps or a night's HRV, in their own tables. Summaries read them instead of recomputing every day from raw samples.
- On a database with 25.6 million samples, once the history is rolled up, the heaviest activity summary drops from 1.3 to 2.9 seconds to 25 milliseconds.
- Time series can be read by day, week and month. Workout statistics a provider didn't send are computed from the workout's own samples.
- A rollup keeps the new tables current every 15 minutes. Rolling up the history from before the upgrade is a manual step in 0.11.
- Sleep summaries get an interruption count, and Apple Watch nights arrive about 15 minutes after upload instead of up to 3 hours later.
- The release has breaking changes, and some startup migrations can't be undone. Back up the database before upgrading.
Is Your HealthTech Product Built for Success in Digital Health?
.avif)
Open Wearables 0.11.0 was released on 2 November 2026. It is a data model release. Values that describe a whole day or a whole session now live in tables of their own, so summaries no longer recompute every day from raw samples on each request. The release merges 66 pull requests in total.
It is also the last big data model change before Open Wearables 1.0. Teams running Open Wearables in production should read the breaking changes before pulling the new images, and back up the database first.
Breaking Changes to Check Before Upgrading
Some startup migrations can't be undone, so a database backup comes first. These changes can affect an existing integration:
- Day and session values are no longer stored as samples. They are read through the time series endpoint at day resolution, or on their sleep or workout. Series webhooks no longer send them as daily totals. Old day-value samples are moved to a backup table, so nothing is deleted.
- The samples table is renamed from data_point_series to series_sample. Raw SQL queries and BI tools that read it need updating. During a rolling deploy, pods still on 0.10 fail until they are replaced.
- The data lifecycle settings change shape. The "archive after N days" option is removed, and two new switches control the rollup and the history rollup.
- Some values change. Sleep physiology now comes from the device that recorded the sleep, and workouts fill in statistics the provider didn't send.
- Two series are renamed: walking heart rate average becomes walking heart rate, and average MET merges into physical effort. Old names still work in requests.
- Suunto workout speed is now in metres per second, and Strava kilojoules are taken one to one as kilocalories.
- Sleep stages a device doesn't measure are null instead of 0. A startup migration fixes stored nights from the mobile SDK, Apple Health XML imports and Suunto, and can't be undone.
- The health scores endpoint returns one Open Wearables score per category and day. On 6 November 2026 the native Open Wearables scores are removed from the repository, and later releases no longer compute them.
- In production, signing in with the default admin password returns 403 Forbidden.
- Connections that can no longer sync are revoked. With outgoing webhooks enabled, expect a batch of revocation webhooks as connections sync after the upgrade.
- Stored Polar workout times and duplicated Polar nights are corrected at startup.
- iOS SDK 0.17.0 needs this backend. Upgrade the backend first, or body fat and walking percentages are multiplied by 100 twice.
Two series renames affect webhook filters:
series.walking_heart_rate_average.created -> series.walking_heart_rate.created
series.average_met.created -> no successor, now average_met on the workout
The release notes include a two-phase migration script for webhook subscriptions and a SQL query that lists the connections the upgrade will revoke.
Why the Data Model Changed
Until this release, values such as a day's step count or a night's HRV were stored in the same table as every individual reading, and workout statistics held only what the provider sent. A summary for one user over one month meant recomputing each day from raw samples, on every request. The benchmark database below holds 25.6 million samples.
0.11 gives day and session values their own place. One table holds a series over one local day, with its sum, average, minimum, maximum, last value and count. Another holds a series over one sleep or workout. The samples table keeps readings only, and each reading now records the window it covers, for example the 15-minute epoch a Garmin device reports.
Every aggregate row records who computed it. Either the provider sent it, or Open Wearables rolled it up from the samples. Readers take the provider's value first and fall back to the computed one. Days that are not rolled up yet are still counted from the samples, as in 0.10.
Seconds to Milliseconds
The team measured the change on a database with 25.6 million samples:
/summaries/activity, heavy user, 30 days 1.3–2.9 s -> 25 ms
/events/workouts/totals, all time 151 ms -> 74 ms
aggregates for the whole history 71 MB, +0.9 % of the database
The aggregates for the entire history add less than one percent to the database. Summaries that took seconds on a large database now return in tens of milliseconds.
Day, Week and Month Time Series
The time series endpoint now accepts day, week and month resolutions. These read the daily aggregates instead of bucketing raw samples, and days not rolled up yet are counted from the samples. Each daily point says whether the provider or Open Wearables computed it. Weeks and months are combined by Open Wearables.
GET /api/v1/users/{user_id}/timeseries?types=steps&resolution=1day&start_time=2026-10-01&end_time=2026-10-31
Workout Statistics That Fill Themselves In
Providers don't always send every statistic for a workout. Until this release, a missing figure stayed empty.
Now Open Wearables computes what the provider didn't send from the samples the same device recorded during the workout. That covers heart rate, steps, distance and pace, speed, power, MET, cadence, elevation and calories. The provider's figure always wins when it exists, and a value the provider sent as zero stays zero. Two new series, distance and elevation gain, hold whole-workout totals. Computed values usually appear within 15 minutes of the samples arriving.
Workout totals and the workout part of the activity summary add up the same per-workout values. A client that treated an empty field as "the provider sent nothing" now gets a computed value in that field instead.
How the Upgrade Fills the New Tables
Three processes populate the new tables, and only one needs a decision.
The rollup runs every 15 minutes and rolls up the days that changed. It is on by default, also on upgraded instances. Switching it off in the data lifecycle settings keeps everything working as in 0.10, just without the speedup and without computed workout statistics.
The backfill copies the provider's historical values and workout statistics into the new tables, starting with the last 30 days. It runs automatically in the background and takes minutes.
The history rollup computes Open Wearables' own values for days before the upgrade, which matters most for Apple Health, Health Connect and Samsung Health data. In 0.11 it is a manual step, switched on in the dashboard or through the settings endpoint. It becomes automatic in 1.0, once it has been tested on the largest instances. Skipping it is safe: older days are counted from the samples as before, at 0.10 speed, apart from the value changes listed above. Workouts from before the upgrade get computed statistics only after it runs.
The history rollup is heavy. On a copy of a production database it took about 30 minutes of database work, and it takes hours on the largest instances. Run it when the database can take the load. It resumes where it left off, so it can be switched off and on again. Until it finishes, the speedup covers new days and provider values only.
Data Lifecycle, still in early access, changes with it. The "archive after N days" option is gone. Deleting old data now removes samples only. With the rollup on, their days and sessions stay as aggregates. Retention waits until the backfill is done.
Rolling back works through the backup. The downgrade migration refuses to run once retention has deleted samples, and by default also once provider values are stored in the new tables, which happens right after the upgrade.
Sleep Data
Several fixes make sleep data more accurate:
- The daily sleep summary now fills in the interruption count: awakenings longer than five minutes.
- Apple Watch nights show up about 15 minutes after upload, instead of up to three hours later.
- Nights that other apps write to HealthKit no longer merge into the Apple Watch night.
- Sleep stages a device doesn't measure come back as null instead of zero. "No deep sleep measured" and "zero minutes of deep sleep" are different statements, and the data now keeps them apart.
Providers and Mobile SDK
- Polar workouts are stored at their real time. They were previously placed twice their UTC offset in the future.
- Cycling power, cadence and speed from iOS and Samsung now reach the workout.
- Apple Watch sleeping wrist temperature is stored as skin temperature.
- Third-party HealthKit apps no longer inherit the iPhone's device type. It is taken from the app, so Oura shows up as a ring, or left empty.
- Reconnecting a provider backfills only the gap since the last sync. Historical sync is capped at the provider's limit where it has one.
- Google Health API workouts and sleep are paged within the sync window, with a guard against a repeated page.
Health Scores
The health scores endpoint now returns one Open Wearables score per category and day, picked by source priority. On 6 November 2026 the native Sleep Score and Resilience Score are removed from the Open Wearables repository, and later releases no longer compute them. The endpoint and its response format stay the same, scores from connected providers such as Garmin, Oura or Whoop are unaffected, and scores computed before that date are still returned.
Security and Self-Hosting
- In production, a fresh database with the default admin password stops the backend at startup, and signing in with the default password returns 403 Forbidden. Setting the admin email and a new admin password, then restarting, fixes it.
- The provider settings warn about providers that are enabled without OAuth credentials.
- Teams that deployed from the Railway template should rotate their secrets after Railway's October security incident.
- Garmin's developer program is open again. Historical backfill needs the Enterprise tier.
Upgrading
Upgrading is a standard Docker Compose update:
docker compose pull
docker compose up -d
Back up the database first. Read the breaking changes, set the admin email and password if production still uses the default, and check which connections the upgrade will revoke. Teams that query the samples table directly need to update their SQL and BI. Upgrade the backend before rolling out iOS SDK 0.17.0. Plan the history rollup for a time when the database can take the load.
Official Docker images remain the recommended deployment path. Pin a version for production.
The full changelog is at github.com/the-momentum/open-wearables/releases/tag/0.11.0.
Community
Open Wearables has 2,749 stars on GitHub and 540 forks. The project is at github.com/the-momentum/open-wearables. The Discord community is the fastest place to get an answer.
What's Next
0.11 is the last big data model change before Open Wearables 1.0. The team wants feedback on Discord or in GitHub Discussions, especially from large instances that try the history rollup.
Teams still choosing how to bring wearable data into their product can start with the Open Wearables FAQ on avoiding vendor lock-in or the one-click deployment guide. Momentum also helps teams build wearable integrations on top of the platform and run it on HIPAA-ready infrastructure.
See Related Articles
Frequently Asked Questions
%201.png)
