Google Health Alternatives: 7 Dashboards for Fitbit Data

If you own an iPhone, check this first

Google Health version 5.05, released 2 August 2026, added two-way Apple Health sync. Google Health can now write Fitbit data into Apple Health — steps, exercise records, sleep, vitals — where previously the connection only ran the other way. Apple's own Health app then gives you a native, free, multi-year history view on any screen, including a Mac or iPad.

To turn it on: Google Health → Connections → Apps and services → Apple Health → Manage data and access. Then confirm permissions on the Apple Health side under Sharing → Apps → Google Health.

This is the cheapest and fastest answer on this page, and it is the one most people have not heard about, because Google's own help documentation still described write-back as a future feature after it had already shipped. The release notes are the authoritative source.

Pulseboard — simplest first step

A read-oriented Node dashboard with no third-party runtime dependencies, aimed specifically at the Fitbit Air. It encrypts the persisted refresh token with AES-256-GCM, and defaults to holding OAuth tokens in server memory only. It shows steps, distance, energy, heart rate, sleep, HRV, oxygen saturation, respiratory rate and cardio fitness where those signals exist.

Choose it if you want a read-only view and nothing else. Skip it if you want scores.

Fitbit Health Explorer — most transparent scoring

An Electron desktop app that publishes its formulas more openly than anything else in this list: recovery as weighted z-scores of HRV, resting heart rate, sleep and respiratory rate against a trailing 30-day baseline, mapped through the normal CDF; strain 0–21 as a logarithmic cardiovascular load from active zone minutes, active energy and steps; readiness as a blend of those. All weights live in settings rather than code, so you can tune them without touching source. It also keeps 90 days locally and syncs incrementally.

Its README contains genuinely useful field notes about the API — the kebab-case in URLs versus snake_case in filters rule, the rollup range caps — which is the kind of thing you only learn by building against it.

Choose it if you want to understand the maths rather than just look at it. Skip it if you need it on your phone.

Vitals — easiest to evaluate before committing

FastAPI backend with a dependency-free frontend, installable via Docker or a single cross-platform script. Its distinguishing feature is a demo mode: 150 days of deterministic synthetic recovery, sleep, HRV and strain data, with no OAuth, no credentials and no wearable required. You can see exactly what you are getting before connecting anything.

Also the only entry here built for a household — multi-profile with fully isolated data per person, which matters if more than one of you wears a tracker. Ships nine read-only MCP tools so a local AI agent can read your data without a cloud round trip.

Choose it if you want to try before you commit, or if several of you use trackers. Skip it if you want only Fitbit — the multi-source support is extra scope you may not use.

Vitals Command Center — for people with more than one wearable

Takes a different approach to the same problem. Rather than trusting one device, it reconciles Fitbit, Oura, WHOOP and Apple Health into one normalised timeline with a weighted consensus and a per-metric confidence level, so you can see where two devices agree and where they do not. It routes each device either through the Google Health bridge or its own adapter, explicitly to avoid double-counting.

Installable PWA with a local SQLite database, intended to run on an always-on box behind a tailnet.

Choose it if you own two or more trackers and want them reconciled rather than siloed. Skip it if you have one device — the consensus logic is solving a problem you do not have.

fettle — built around an AI agent

FastAPI plus Next.js over local SQLite, scoped to a single user. Its differentiator is 25 MCP tools and a chat interface with inline generated widgets, so an agent can query your data and render charts without a cloud model in the loop.

It is also the most unusually honest about a platform constraint we found repeatedly: the documentation states plainly that Google Health scopes are restricted, that Production use would require an annual paid security assessment, and that staying in the Testing lane means re-authorising every seven days. It builds a countdown into the interface rather than letting you discover the problem.

Choose it if you want an agent reading your data and do not mind a setup wizard. Skip it if you want a plain dashboard.

HealthLog — broadest, but read the licence

The most capable entry here if your interest is health rather than fitness: adds blood pressure, glucose, medications, mood and cycle tracking on top of sleep and recovery, with per-metric source priority so overlapping wearables resolve consistently. Ships as a Docker PWA with a native iOS client streaming HealthKit.

Then the catch: this is source available, not open source. It is free to run, self-host and modify for noncommercial purposes. Commercial use requires a separate agreement. Releases up to v1.15.18 were AGPL. If this is ever going inside a product you sell, that is a blocker.

Choose it if you want one timeline for the whole household's health. Skip it if you need commercial rights.

HealthQuery — the Android shortcut

Reads Android Health Connect and posts to a server you run, storing in SQLite. Ships an MCP server and can generate structured summaries for a doctor appointment.

The reason it is on this list: it requires no Google Cloud project, no OAuth client and no developer console. The Android app reads Health Connect and pushes to your server. Everyone else on this page needs you to create a Google Cloud project and mint an OAuth client, which is the step that stops most people. If that step is your blocker, this is the one to try.

Choose it if you are on Android and want zero Google setup. Skip it if you are on iOS, or if you want scored metrics — it visualises raw data rather than computing recovery scores.