Two Minutes Against Twenty: Setup Time Is the One Pillar Nobody Puts on a Compare Page
Every Apple Health connector compare page has a metrics row, a tools row and a privacy row. Almost none of them has a time row, and time is the pillar that decides whether you get an answer tonight or next weekend. Here are the real numbers, taken from each project's own docs, and a fair way to benchmark them yourself.
AI-assisted, human reviewed. How we use AI
Quick answer
Setup time for an Apple Health connector runs from roughly two minutes to about twenty, depending entirely on the route. A hosted connector is an OAuth click, under a minute. The MetricBridge route is the app writing a local JSON file plus one install line, about two minutes. health4.ai advertises around 15 minutes. Open Health Sync says about 20 minutes for its Docker and PostgreSQL stack. The spread is ten times over, and no compare page prints the row.
Why the number never makes the page
Three reasons, and none of them is a conspiracy. First, setup time is not a spec sheet value. It only exists after someone runs the install on a real machine, so a page built from a README cannot copy it in. Second, it is hard to self-report without sounding slow: "about twenty minutes" is honest and it also reads like a warning, so the temptation is to drop the number and let the reader assume "quick". Third, minutes are not a screenshot. A metrics count photographs well; a stopwatch does not.
The result is a comparison table where the fastest route and the slowest route look identical on paper. That is the gap this post fills, using each project's own documentation rather than a marketing claim.
The routes, and what each one really asks of you
| Route | Their own number | What the clock covers |
|---|---|---|
| Hosted MCP connector | Under a minute | Paste a URL, complete OAuth. No local install. Data lands on the host. |
| MetricBridge (export plus local server) | About two minutes | Export from the app to a folder, one npx install line, restart the client. |
| health4.ai | About 15 minutes | Create the destination (your Google Sheet or your Supabase/Postgres), connect it, wait for a background sync that iOS schedules. |
| Open Health Sync | About 20 minutes | Docker Compose stack, create your user, export, import into PostgreSQL, mint a read-only token, add the server to the client. |
The health4.ai and Open Health Sync numbers are from their own documentation as we read it on 8 November 2026. The hosted-connector number is the shape of any OAuth flow. Nobody publishes a stopwatch; these are the vendors' own estimates, which is exactly why a buyer should re-run the clock.
What "two minutes" includes, and what it does not
We are not going to pretend our own number is a clean two under every condition, because it is not. Here is the honest breakdown of the MetricBridge route, so the comparison is at least symmetric:
On the phone The app reads Apple Health read-only and writes 194 metrics as JSON to a folder you pick. If you have never exported before, the phone does the first one and it runs in the background while you set up the Mac.
On the Mac One line:
claude mcp add health-export -- npx -y health-export-mcpThat server is zero-dependency, speaks stdio, ships 22 tools (20 read-only, and the other two only log events to their own file), and makes zero network calls. It needs Node.js. If Node is already on the machine, this is seconds. If it is not, add the download, and the two-minute estimate stops being true.
The rule for a fair number. Start the clock with the machine as a new user actually has it and stop it when the agent answers a real question about real data. That includes Node if it is missing, the first Health app export if none exists yet, and the client restart. A number that skips any of those is a spec sheet, not a setup time.
The part the minutes hide: what you maintain after
Setup time is a one-off, and it is the wrong thing to compare if you ignore what recurs. Read the twenty-minute route closely and you will find chores that do not show up in a "time to first answer" number:
- A token that expires. Open Health Sync mints a read-only token with a 30-day expiry in its docs. Good hygiene, and also an event every 30 days: when it lapses, the agent goes quiet.
- A service that has to stay up. A container stack and PostgreSQL have to be running for the agent to work. That is a process on your machine, not a file on your disk.
- A database to back up. Your history now lives in a server you own and maintain.
- A sync you do not control. health4.ai's own page is candid that iOS decides when apps run, so its background sync is best-effort, not a schedule you set.
Compare the local-file route on the same axis. There is no token to renew, because the grant is the folder path: point the server at your export directory and that is its entire reach. There is no service to keep alive, because the server is a process your client starts on demand. None of that makes the self-hosted route wrong. It makes "20 minutes" an underestimate of the real cost, and it makes setup time a pillar you should read together with maintenance.
How to benchmark any route yourself
Four rules that make the numbers comparable:
- Same machine, same client. A cold laptop with no Node is a different test from your daily driver.
- Start from nothing. No export sitting in a folder, no client already configured, no Docker installed.
- Stop at the first real answer. Not the first green check, not the first tool listed. The moment the agent reads an actual number of yours.
- Count the moving parts, not just the minutes. Ten minutes of typing is not the same as ten minutes of waiting on a database import. Write down how many things you had to install, run and keep running.
Do that once per route and you have a column that no compare page gave you, and you can point it at whichever project you test, us included. If our two-minute number does not survive your stopwatch, that is worth knowing, and it is the kind of thing we would rather you measure than accept.
When setup time is the wrong thing to optimize
The hosted connector wins this pillar outright, and it would be dishonest to bury that. It also changes the trade: the export reaches the host's database, the answer is computed server-side, and the tool result is handed to whichever model writes your sentence. That is a real convenience and a real trust boundary at the same time. Fastest is not the same as best. The point of the time row is to make the trade visible, not to declare a winner from a stopwatch.
We argued the longer version of that trade in remote MCP server versus a file on your Mac, and the shorter version for the self-hosted route is in the Open Health Sync walkthrough. Read them next to a stopwatch and you can decide the whole thing in an evening.
Doing this yourself? MetricBridge handles the export step on the iPhone: 194 metrics as local JSON, read by the open-source MCP server (GitHub) in one install line.
FAQ
How long does it actually take to set up an Apple Health MCP connector?
It depends entirely on the route, and the honest numbers come from each project's own docs: a hosted connector is an OAuth click under a minute, the MetricBridge route is the app writing a local JSON file plus one install line, about two minutes, health4.ai advertises around 15 minutes, and Open Health Sync says about 20 minutes for its Docker and PostgreSQL stack. The range is roughly two minutes to twenty, and no compare page prints it.
Why do Apple Health connector compare pages leave out setup time?
Because it is hard to self-report without looking slow, and because minutes are not a screenshot. A compare page can list metrics and tools from a spec sheet, but setup time only exists after someone runs the install on a real machine, so the row that decides whether you get value tonight is the row that gets left off.
Does setup time include installing Node.js?
It should, and most published numbers quietly exclude it. A fair number starts the clock with the machine as a new user has it and stops it when the agent answers a real question. For any route that runs a local MCP server, that includes Node if it is missing, the first Health app export if none exists yet, and the client restart.
Is a faster setup always the better route?
No. A hosted connector is the fastest to connect because there is nothing to install, and it also moves your health data onto someone else's machine and computes answers server-side. Setup time is one pillar, not the whole decision: pick the route whose trade is right for you, then measure the minutes on the pillar the page refused to list. Wellness information, not medical advice.
Two minutes, then your own numbers
Export all 194 metrics on the iPhone, then let Claude, Cursor or any MCP client read them from a folder on your Mac. One install line, no host in the path.
Where it goes: the app reads Apple Health read-only and writes JSON to a folder you pick. Your health data never reaches us or a cloud AI; the MCP server makes zero network calls. What you get: all 194 metrics, on-device Ask with a provenance card on every answer, the Weekly Brief, and the Mac and Apple Watch apps. Price: $24.99 one time after a 7-day free trial, not a subscription. Wellness, not medical advice.