Why is my Stelo glucose data delayed in Apple Health?

Dexcom deliberately writes Stelo readings to Apple Health on a delay of roughly 3 hours. Your live number always appears in the Stelo app itself; Apple Health, and every third-party app reading from it, receives the data once the delay window passes. This is a Dexcom design decision for the over-the-counter product, not a bug in your phone or in any companion app.

Is my Stelo broken if Apple Health shows no recent glucose?

Probably not. If the Stelo app shows current readings but Apple Health's latest entry is about 3 hours old, everything is working as designed. If Apple Health shows nothing at all, check that Stelo has permission to write glucose to Apple Health (Stelo app settings and iPhone Settings, Privacy and Security, Health) and that the app has been opened recently so it can sync.

Can any third-party app show live Stelo data?

No app reading from Apple Health can beat the delay, because the data simply isn't there yet. Apps built on Dexcom's partner APIs operate under separate agreements and delays of their own. For your live number, use the Stelo app. For understanding what meals did to you, delayed data is fully sufficient.

Does the 3-hour delay make meal analysis less accurate?

No. A meal's glucose response takes roughly 2 to 3 hours to complete anyway, so analysis apps like spike would wait for the full curve even with live data. The readings themselves are identical whenever they arrive; the timestamps are preserved. You get the same curve, peak, and recovery numbers, just delivered when the meal's story is complete.

Blog · July 5, 2026 · 6 min read

Why your Stelo data is 3 hours behind in Apple Health (and why that's fine)

You connected your Stelo to Apple Health, opened a glucose app, and the most recent reading is from three hours ago. Nothing is broken. Here's what's actually happening, why Dexcom built it this way, and why the delay matters far less than it first appears.

What's actually happening

The Stelo sensor talks to the Stelo app in near real time; that app always has your current number. But when the Stelo app writes readings into Apple Health, it does so on a delay of roughly 3 hours. Every third-party app that reads glucose from Apple Health (spike included) receives the data only once that window passes, with the original timestamps intact.

So at 3:00pm, Apple Health contains your glucose history up to roughly noon. By 6:00pm, it has your lunch. The data is complete and accurate; it just arrives in batches, behind the present.

Why Dexcom does this

Stelo is an over-the-counter wellness product cleared for adults not on insulin. Real-time glucose streaming to arbitrary third-party apps looks a lot more like a medical data feed, with the regulatory weight that carries. The delay keeps the OTC product clearly in wellness territory: the Stelo app remains the place for "now," and everything downstream works with recent history. Whether you find that conservative or sensible, it's deliberate, documented behavior, not a sync bug.

Checklist: delay vs actual problem

Worth separating the designed delay from real setup issues:

Stelo app shows readings, Apple Health is ~3 hours behind: working as designed. Nothing to fix.
Apple Health has no glucose at all: check the Stelo app's Apple Health connection setting, then iPhone Settings → Privacy & Security → Health → Stelo, and make sure blood glucose write access is on.
Data stopped arriving hours ago and never catches up: open the Stelo app; background sync can stall until the app runs. Restarting the phone clears most of the rest.
A companion app sees nothing: that app also needs its own Apple Health read permission for blood glucose.

Why the delay costs you less than you think

Here's the reframe: what is a live number actually for? If you're managing diabetes with insulin, it's essential, and that's what prescription CGMs with real-time apps are for. But if you're wearing a Stelo to learn how food affects you, the question you care about is retrospective by nature: what did that meal do?

A meal's glucose story takes 2 to 3 hours to unfold: rise, peak, recovery. Even with a perfectly live feed, an honest analysis has to wait for the story to finish before scoring it. Judging a meal at minute 40 is reviewing a movie at the halfway mark.

This is exactly how spike is designed. You log the meal when you eat it (photo, voice, or search). spike watches Apple Health, and once the full response window has arrived, it analyzes the curve and notifies you: baseline, peak, rise, and time back to baseline. The notification lands a few hours after you ate, which is the earliest moment a complete answer could exist anyway. The delay and the analysis window largely overlap; the practical cost is close to zero.

The right mental model: two apps, two jobs

Keep the Stelo app for the present tense: your current number, your live graph. Use a companion app for the past tense, where the actual learning lives: which meals spiked you, which didn't, and what your days look like in range. The delay only hurts if you ask an Apple Health app to do the Stelo app's job. Split the jobs correctly and both apps excel.

The bottom line

The 3-hour Apple Health delay is a deliberate Dexcom design choice for the OTC Stelo, not a malfunction. No third-party Apple Health app can beat it, and for meal analysis none needs to: complete glucose responses take hours to form regardless. Use Stelo's app for now, spike for why, and the delay becomes a footnote.

built for how Stelo actually works.

spike analyzes each meal's complete response the moment the data lands. Free trial on the App Store.

Download on the App Store

spike is a wellness app, not a medical device, and is not affiliated with or endorsed by Dexcom. Stelo behavior described reflects publicly documented functionality as of July 2026 and may change with Dexcom software updates. If you use insulin or manage diabetes, rely on your prescribed real-time CGM system and care team, not delayed data.