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. Research on T1D adults consistently shows they maintain demanding careers, raise families, and manage complex lives while self-managing their condition. The burden is real, but so is the adaptation. The problem is not that T1D adults cannot function. It is that the tools designed to help them often do not.

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. Where the current state of the art has improved, I note it. Where the gap remains, I name it precisely.

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. Ringholm et al. documented nocturnal hypoglycemia occurring after 4.6% of nighttime breastfeeds in T1D mothers, with glucose patterns variable enough across the first six months postpartum to warrant active monitoring. Overnight CGM use in this context is clinically prudent, not precautionary.

What happened: 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. Temporarily silencing it meant not knowing when the issue resolved and real glucose alerts might follow.

What Dexcom has improved since: The G7 now offers Quiet Modes (Vibrate and Silence All), accessible from the Alerts screen. Users can create a second alert profile and schedule automatic switching between daytime and nighttime settings. These are real, meaningful improvements that address part of the problem I experienced.

What the gap still is: Even in Vibrate mode, Dexcom's own documentation confirms that Urgent Low and technical alerts will still escalate to sound if not acknowledged within a set period. A Sensor Fail at 2am will eventually sound audibly regardless of mode. More importantly, Quiet Modes require manual activation before the alert fires. The system still does not know you are nursing, sleeping next to an infant, or in any other context where the standard alert behavior creates compounding risk. Switching modes requires navigating into Profile → Alerts, not from within the alert itself.

Additionally, the main Dexcom home screen shows no persistent indicator of which alert profile or mode is currently active. A banner appears during active Quiet Mode sessions, but outside of that, there is no passive confirmation that your settings are what you think they are.

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. Using a Medtronic CGM.

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 Medtronic's documentation confirms: When a "Sensor Updating" alert fires, Medtronic instructs users not to remove the sensor if the alert has been present for less than 3 hours. The system fires a persistent alert, offers no resolution path, and asks the user to wait up to 3 hours. The alert continues throughout. This is not a misuse scenario. It is the documented intended behavior.

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 updating but not yet failed 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.