18,081 continuous-glucose readings over 65 days in 2024, in three wear blocks, asked what they do as a function of time of day. They are strongly clock-aligned: 26.4 mg/dL between the 04:00 trough and the 13:00 peak. His own diary question — whether dawn glucose consistently clears 100 — comes back usually: 67% of days. Every result here is a lead, not a finding, and the last section says what to do about that.
Four sections: the shape of the day, the contrasts named in advance, what was done to try to break them, and the one question this data cannot answer.
Is glucose aligned to the clock at all? Yes.
Peak-to-trough of the mean day is 26.4 mg/dL — trough at 04:00, peak at 13:00.
Each point is the mean across days of that clock hour's readings. The band is a 95% bootstrap interval <b>resampling days</b>, not readings — it answers “how much would this shape move if he had worn the sensor on a different set of days?” Abbott's own AGP shades the spread of readings instead, which looks similar and answers a different question. Bars along the bottom are how many days stand behind each hour. 26.4 mg/dL against a null that reaches 10.3 only one time in twenty (p<0.0001, 59 fully covered days).
| hour | glucose | interval | |
|---|---|---|---|
| trough | 04:00 | 96.1 mg/dL | 92.9 – 98.6 |
| peak | 13:00 | 122.6 mg/dL | 118.5 – 130.9 |
| amplitude | — | 26.4 mg/dL | null median 7.5, 95th pct 10.3 |
<b>The null is the whole design.</b> 18,081 readings is not n=18,081 — consecutive 5-minute values are near-deterministic in each other, so pooling them returns p<1e-50 for any difference at all, including one sensor's calibration drift. n here is the 59 days. But reducing to days is only half the fix: shuffling hour labels would destroy each day's autocorrelation along with its phase, comparing a real curve against white noise, which any smooth curve beats. This test instead <b>shifts each day circularly by a random number of hours</b> — shape, amplitude and autocorrelation all survive, only clock position is randomised. What it certifies is the claim that matters: the curves line up with the clock the same way on different days.
The 13:00 peak and 20:00 bump are almost certainly lunch and dinner, but nothing in the export records a meal time, so that reading is inference and not evidence.
“Look at dawn glucose level if consistently higher than 100 mg/dL” — his CGM diary, October 2024 Partly.
Pre-breakfast glucose averages 104.9 mg/dL and clears 100 on 41 of 61 days (67%). It is higher — usually, and by about 5.
Each row is one within-day contrast, tested across days with a sign-flip permutation. Intervals are normal approximations on the same day-level standard deviation; the p-values beside them are the exact permutation values, which is why a wide-looking bar can still carry a small p. Four of five are real and one is not: day of week does nothing (-2.8 mg/dL, p=0.24), reported because a null that was actually tested is worth more than a silence.
| contrast | effect | days | p |
|---|---|---|---|
| Dawn rise (06–08 mean − 00–05 trough) | +19.43 | 61 | <0.0001 |
| Dawn slope, 03:00–08:00 (per hour) | +2.64 | 63 | <0.0001 |
| Waking day − night | +13.79 | 61 | <0.0001 |
| Pre-breakfast mean − 100 | +4.94 | 61 | 0.0001effect found |
| Weekend − weekday (day mean) | -2.81 | 65 | 0.2442no effect found |
<b>The dawn rise is a return, not an overshoot.</b> It correlates -0.78 with the overnight trough but -0.01 with the pre-breakfast value itself. Part of the first is arithmetic — the trough is a term in the rise — but the second is not, and it is the informative one: he arrives at essentially the same number before breakfast whatever the night did. What varies between days is how far he dipped, not where he landed.
A sign-flip test assumes the day-level values are symmetric about their centre. For a difference of two means within the same day that is mild, but it is an assumption and not a fact.
Does any one stretch, or the sensor itself, carry this? No.
The shape survives dropping any wear block, and survives discarding the first 24 hours of every inferred sensor.
The same average day computed separately in each wear block. Bands are omitted on purpose — three translucent overlaps are unreadable, and the question here is only whether the <i>shapes</i> agree. Note the autumn block runs on PDT and the two winter blocks on PST, so these curves are aligned by wall-clock, not by sun. Amplitude ranges 25.3–28.9 mg/dL across the three leave-one-out fits, and the peak moves by at most an hour.
| attack | result | p |
|---|---|---|
| drop Jan 1–15 | amplitude 27.5 mg/dL, peak 13:00 | 0.00025effect found |
| drop Jan 29–Feb 12 | amplitude 25.3 mg/dL, peak 13:00 | 0.00025effect found |
| drop Sep 24–Nov 1 | amplitude 28.9 mg/dL, peak 14:00 | 0.00025effect found |
| drop 24 h after each inferred sensor start | dawn rise +18.41 mg/dL (58 days left) | 0.0001effect found |
| is it a level effect, not a shape? | r=-0.35 against the waking-day mean (no shared readings) | — |
<b>The level check is the one that could have killed it.</b> If the dawn rise were simply bigger on days he ran high, this would be a fact about his level and not about the clock — and a sensor reading uniformly high would produce exactly that. It is the reverse: the rise is <i>larger</i> on days he runs lower. Tested against the 08:00–22:00 mean, which shares no readings with the rise; the whole-day mean would have been the obvious comparison and is the wrong one, because it contains both windows and part of any correlation with it is arithmetic.
Sensor identity is inferred from gap shape, not recorded: the export carries one account-level UUID on all 21,782 rows. The warm-up attack is therefore only as good as that inference.
Is the autumn dawn rise a season, or a clock offset? Unresolvable.
The dawn rise is markedly larger in the autumn block, and nothing here can say whether that is the season, the hour the clock reads, or the sensor.
One dot per day. Bars are 95% bootstrap intervals on the block mean. Season, daylight-saving offset and sensor generation all change together at the same boundary. Three variables, one split: no amount of care recovers which one moved the number.
| block | dawn rise | days | clock |
|---|---|---|---|
| Jan 1–15 | +14.6 mg/dL | 14 | PST |
| Jan 29–Feb 12 | +13.7 mg/dL | 13 | PST |
| Sep 24–Nov 1 | +23.6 mg/dL | 34 | PDT |
This is reported rather than buried because it is the single cheapest thing to fix in the next wear: a sensor worn across a season boundary, or twice in one year, separates all three.
When each stream of data actually exists. A stream that stops before the analysis window opens is greyed out: it is in the files, but it cannot speak to this question.
Three wear blocks separated by a fortnight and by seven months. Oura covers all 69 of these days, which makes glucose-versus-sleep the natural next question.
What each source contributes to this question — and, where it matters more, what it cannot contribute. Every item links back to the audit page for the file it comes from.
A LibreView CSV export, downloaded 2026-09-03. The phone app emits only rendered PDF reports; the CSV is the analysable form and covers two wear blocks the PDFs never showed. See the data audit →
Validated against both of Abbott's own AGP reports: mean 107.6 vs 108, GMI 5.9 vs 5.9, CV 20.0 vs 20.0, time-in-range 95.4 vs 95.
Deliberately not merged into the series. Scans are user-initiated, so they cluster around meals and symptoms; folding them in would tilt the very time-of-day profile this page is about.
Too sparse to test — 28 entries across 69 days. They are the only record of meal timing in the file, which is why the tracking prescription asks for meal times.