Diabetes Case Study - The Alert That Cried Wolf

The Problem

CGM alert systems are designed as if the person wearing the device has one job: managing diabetes.

The reality is different. Most T1D adults are high-functioning people for whom diabetes management is one of many simultaneous responsibilities. Not the primary one.

Yet the dominant paradigm of CGM alert design assumes a patient model: a person whose attention is largely available, whose context is relatively stable, and whose primary concern is glycemic control. For long-term, experienced T1D adults, this model creates a specific and well-documented failure: alarm fatigue.

A 2025 narrative review by Giza et al. identified alarm fatigue as the most common cause of CGM discontinuation, more common than cost, discomfort, or technical complexity. The same research notes that alarm fatigue significantly compromises sleep quality not just for patients, but for their entire families and caregivers. Critically, the solutions proposed by the literature (individualized education and better alarm settings) place the burden back on the user rather than addressing the underlying design failure.

This is a UX problem. Alert design in healthcare has been shown to result in clinician override rates of 49–96% (Winters et al., 2018). This reflects not recklessness, but rational adaptation to a system that does not prioritize signal quality. The same dynamic plays out in consumer CGM use, where experienced users routinely disable, silence, or ignore alerts. Not because they don't care about safety. Because the alert system does not understand their context. Dexcom has acknowledged this directly, noting that excessive notifications may become frustrating and diminish the significance of future alerts, making users more likely to ignore them.

Three Observations from the Field

What follows are three specific incidents from my own experience. They are not anomalies. They are representative of a class of design failures that repeat across devices, platforms, and years of use.

Observation 1 — The Nursing Mother

The context: Postpartum, breastfeeding a newborn, approximately 13 years ago. Nighttime. Glucose patterns during the postpartum period are unpredictable, particularly during nighttime breastfeeding. Clinicians routinely advise T1D mothers to monitor overnight during this period precisely because breastfeeding affects insulin needs in ways that are difficult to anticipate. Overnight CGM use in this context is clinically prudent, not precautionary.

What happened: On the device I was using at the time, the CGM began alerting repeatedly for a sensor connection issue. A technical error, not a glucose event. The alert was audible and persistent. It woke the baby. Silencing the alert permanently was not an option, because I genuinely needed overnight monitoring. At the time, no granular alert controls existed. The choice was full alerts or silence everything. No middle ground. No middle ground.

How the category has evolved: Some systems have since made meaningful progress here. Per-alert configuration now exists in more advanced platforms, allowing users to separately manage glucose alerts and technical system alerts. Schedulable alert profiles mean a nighttime configuration can switch automatically without manual intervention. These are genuine improvements that address the core of what I experienced.

What the gap still is: Even where these tools exist, the home screen of most CGM apps shows no persistent indicator of which alert profile is currently active. A user cannot confirm at a glance whether their nighttime settings are actually running. Switching profiles outside a schedule still requires navigating several levels into settings. Not something easily done in the dark, half-asleep, with a baby in your arms.

The design principle: Context-blind alert delivery. When a system cannot adapt output modality to real-world context, and when mode-switching requires pre-configuration rather than contextual response, it forces users into workarounds that compromise the safety the system was designed to provide.

Observation 2 — The Highway

The context: Driving on a highway to a work meeting.

What happened: A persistent sensor connection error began alerting repeatedly. The alert was urgent enough, and frequent enough, that I exited the highway, pulled into a parking lot, and spent time trying to resolve it. There was nothing to resolve. The error was a sensor fault with no available user action. The alert cadence gave me no meaningful decision window between notifications. Not enough time to assess the situation, decide whether to remove and replace the sensor (an expensive and time-consuming action), or conclude that the sensor might self-correct.

I was late to a meeting. I had introduced real road safety risk. The sensor eventually resolved on its own.

What the documentation confirms: On some CGM systems, when a sensor connection error fires, users are instructed not to remove the sensor for up to 3 hours. The system fires a persistent alert, offers no resolution path, and asks the user to wait. The alert continues throughout. This is not a misuse scenario. It is documented intended behavior. The alert cadence does not account for the time a user actually needs to make a meaningful decision, nor does it communicate clearly when no action is available.

The design principle: Actionless interruption. An alert that demands attention for a condition the user cannot resolve is not a safety feature. It is a liability transfer mechanism. Real safety design accounts for what the user can actually do, and when. A sensor that is self-resolving does not warrant the same urgency cadence as a dangerously low glucose reading.

Observation 3 — The Waterpark

The context: A day out with my children at a waterpark. Running a Dexcom G7 and an Omnipod simultaneously, with a smartwatch as a tertiary display. This is a common configuration for users managing both CGM and insulin pump therapy.

What happened: A single sensor error triggered simultaneous alerts from all three devices: the Dexcom app, the Omnipod app, and the watch. Three independent notifications, one underlying event. The combined alert volume, in a crowded social environment where I was actively present as a parent, was overwhelming. I silenced all three.

I then spent the remainder of the day without active monitoring, in a high-activity environment where glucose levels are inherently less predictable due to physical exertion, heat, and intermittent eating. The alert system designed to keep me safe had created the precise condition it was meant to prevent.

What the documentation confirms: Dexcom and Omnipod handle sensor communication errors as independent alert categories with separate troubleshooting paths. There is no cross-platform arbitration layer documented anywhere in either system's support materials. Each system behaves as if it is the only device the user wears.

The design principle: Alert arbitration failure. In integrated medical device systems, the absence of cross-platform coordination creates a compounding alert burden that rational users resolve by disabling monitoring entirely. In an era where closed-loop insulin management systems are the clinical standard, this is a significant architectural gap.

The Bigger Pattern

Across these three observations, and across 15 years of CGM use, a single structural failure emerges.

These systems are designed for a patient. Most users are people.

The distinction matters. A patient is someone whose primary context is their health condition, whose attention, environment, and daily structure are organized, at least partially, around managing that condition. A person is someone for whom a chronic condition is one layer of a complex, full life, layered beneath parenting, work, caregiving, driving, traveling, and showing up for the people who depend on them.

Research in personal informatics and chronic disease management increasingly recognizes this gap. Epstein et al.'s systematic mapping of the personal informatics literature found that diabetes had the most publications of any chronic condition studied. Yet the lived experience of long-term, expert self-trackers managing T1D across full and demanding lives remains underrepresented in how these systems are designed. Human-centered design frameworks have called for moving beyond patient-centered models toward person-centered approaches that account for the full context of someone's life, not just their clinical profile.

Alert fatigue is not a user education problem. It is a design problem. And the consequence of poor alert design in CGM systems is not inconvenience. It is that experienced, capable users disable the monitoring they need because the system demands more from them than their lives can accommodate.

The tools to manage alerts precisely have improved considerably. Some systems now allow per-alert configuration, multiple schedulable profiles, and granular control over sound, vibration, and timing. But good tools and accessible tools are not the same thing. When an alert fires at 2am, or while driving, or while trying to be present at a waterpark with your children, the path to the right setting is several taps into a settings menu you did not memorize. The blunt instrument (silence everything) is always one tap away. And when you are frazzled, interrupted, half-asleep, or just trying to get back to your life, you reach for what is closest. That is not a failure of willpower. That is how humans work under stress. Designing for the calm, deliberate user and ignoring the interrupted, frustrated one is a gap that no amount of settings granularity can fix on its own.