Prometheus is built to scrape live infrastructure metrics; Apple Health is historical, irregular, personal data, so for most people a queryable time-series database is the better fit. HealthSave Pro syncs your HealthKit data to a self-hosted TimescaleDB you own. If you genuinely want Prometheus, you expose your synced data through a small exporter, here's the honest path, and when it's worth it.
Read this before you wire it up
Prometheus is excellent at what it's for: scraping fast-moving operational metrics from services it polls, with retention and sampling tuned for monitoring and alerting. Apple Health is the opposite shape, sparse, irregular samples (a heart-rate reading here, a sleep block there, a weight entry once a week) that you mostly want to look back over. Forcing that into Prometheus fights the tool. For health history, TimescaleDB + Grafana, which HealthSave gives you directly, is the right answer. Prometheus only earns its place if you already run it and want a couple of current health gauges next to your infra.
The pipeline (if you proceed)
iPhone (Apple Health)
└─ HealthSave Pro ──(background sync)──▶ Observatory (FastAPI + TimescaleDB)
└─▶ exporter (/metrics) ◀──scrape── Prometheus ──▶ Grafana
Step 1, Get Apple Health onto your own server
Stand up the open-core HealthSave Observatory (the datahub project, FastAPI + TimescaleDB via Docker), buy HealthSave Pro, and set Settings → Server Sync → Server URL to your server, then enable background sync. Your HealthKit data now lives in a database you own.
Step 2, Sanity-check the choice
If your goal is trends and history, stop here and use Grafana over TimescaleDB. If your goal is "a few live health numbers on my existing Prometheus/Grafana monitoring board," continue.
Step 3, Write a tiny exporter
Run a small service that reads the latest value per metric from the Observatory's REST API and serves them as Prometheus gauges on /metrics:
# /metrics output (illustrative)
apple_health_resting_heart_rate_bpm 58
apple_health_steps_today 7421
apple_health_hrv_ms 42
Keep it to current values, this is the use case Prometheus handles well. Don't try to replay years of history through it.
Step 4, Scrape and chart
Add a scrape job in prometheus.yml pointing at your exporter, then build a panel or two in Grafana. You now have live health gauges beside your infrastructure metrics.
Prometheus vs TimescaleDB for this job
| TimescaleDB (you already have it) | Prometheus (exporter) | |
|---|---|---|
| Best at | History, trends, ad-hoc SQL | Current values, alerting |
| Data shape fit | Great for irregular samples | Awkward for sparse history |
| Setup | Included in the Observatory | You write an exporter |
| Use it when | You want the full record | You already run Prometheus |
What's free vs Pro
| Capability | Tier |
|---|---|
| On-device dashboard, CSV/JSON export | Free |
| Background sync to your server (TimescaleDB) | Pro |
| REST API (for the exporter) | Pro |
Pro is a one-time $24.99 (US price, varies by region), Family Sharing included, no subscription.
Honest limits
- No native /metrics endpoint. The exporter is your code; HealthSave delivers to TimescaleDB.
- Prometheus suits current gauges, not history. Use TimescaleDB/Grafana for long-range trends.
- You run it all, server, database, exporter, Prometheus. No hosted option.
- iOS only; reads Apple Health, so data must already be in HealthKit.
- Accuracy is your wearable's.
Related
- Apple Health to Grafana, the recommended path for health history.
- Store Apple Health in your own database.
- Build a custom REST API over your Apple Health data, what the exporter reads.
- Apple Health data in your homelab.
FAQ
Does HealthSave expose a Prometheus endpoint?
Not natively. HealthSave syncs to TimescaleDB. To expose Prometheus metrics, you run a small exporter that reads the latest values from the Observatory REST API and serves them on /metrics for Prometheus to scrape.
Should I use Prometheus for Apple Health data?
Usually not. Prometheus is designed for scraping live infrastructure metrics, with sampling and retention tuned for that. Apple Health is historical, irregular, and personal; a queryable time-series database like TimescaleDB with Grafana fits it better.
When does Prometheus make sense here?
If you already run Prometheus and want a few current health gauges, like latest resting heart rate or today's steps, alongside your infra metrics, an exporter is a reasonable way to surface them.
What about historical health data in Prometheus?
Prometheus isn't built to backfill years of irregular history. For long-range health trends, query TimescaleDB directly or use the bundled Grafana dashboards instead.
Is there a hosted version?
No. You run the Observatory, the database, the exporter, and Prometheus yourself. There is no hosted backend.
HealthSave is not a medical device. It is for informational purposes only and does not diagnose, treat, cure, or prevent any disease or condition. The accuracy of any health data depends on your wearable device and its sensors. Privacy claims of zero data collection apply to the iOS app; self-host sync sends your data to your own server.
Get HealthSave
Download free, try the export, then unlock background sync to your own server with a one-time Pro purchase, and expose a Prometheus exporter from there if you need it.
Download HealthSave on the App Store