The Interrupt Is the Product
Notifications are not a feature of your apps. They are the product your apps are selling to your attention. This distinction matters because features serve you, while products serve their makers. Slack, email clients, news apps, and social platforms are all in the same business: delivering interrupts that feel urgent enough to open, but not so consequential that you quit in frustration. The goal is maximum engagement, not maximum usefulness.
Understanding this flips the question. The usual framing is “how should I manage my notifications?” The better framing is “why am I allowing software companies to schedule my day?” The former leads to notification triage. The latter leads somewhere more interesting.
The cognitive cost of an interrupt is not just the time it takes to handle it. Gloria Mark’s research at UC Irvine found that it takes around 23 minutes on average to return to a task after an interruption. That number gets quoted everywhere, but the mechanism behind it is what matters: interruption forces a context switch, and context switching steals your best thinking, not your time. Your working memory, the mental scratchpad where you hold the current state of a hard problem, gets partially overwritten. Resuming isn’t free. You have to reconstruct what you were doing, which means some percentage of your best thinking simply evaporates.
Why “Just Ignore It” Doesn’t Work
The naive response to notification overload is willpower: see the badge, choose not to tap it. This fails for a reason that’s more mechanistic than motivational. The mere presence of a notification, even one you don’t act on, taxes your attention. A study published in the Journal of Experimental Psychology in 2015 found that receiving a phone notification (without even looking at it) produced distraction comparable to actually using the phone. The alert had done its job before you did anything about it.
This is why “just turn off the sound” is a half-measure. Visual badges, lock screen previews, and even the habit of glancing at your phone create the same anticipatory loop. Your brain learns that the phone is a source of unpredictable social and informational rewards, and unpredictable reward schedules are famously hard to ignore. This is the same mechanism behind variable-ratio reinforcement, the principle that explains why slot machines are more compelling than vending machines. You don’t know when the good thing will arrive, so you keep checking.
The implication is uncomfortable: you cannot out-discipline a system that was engineered to undermine your discipline.
The Asymmetry Nobody Accounts For
Here’s a framing I find useful when thinking about this systematically. Every notification represents a claim on your future attention. When you allow an app to send notifications, you are essentially signing a contract that says: “At some unpredictable moment, you may interrupt me, and I will pay the cost of that interruption regardless of whether the interrupt was worth it.”
The asymmetry is this: the cost of handling a low-value notification is nearly the same as handling a high-value one. Both require context switching. Both take several minutes to fully recover from. But the value delivered is wildly different. A Slack message that says “lol” and a Slack message that says “the production database is down” both arrive as identical red dots. Your nervous system treats them similarly; your calendar does not.
This asymmetry means that a notification channel is only worth keeping open if you trust its signal-to-noise ratio enough to justify paying the full context-switching tax on every message it delivers, including the low-value ones. Most channels cannot meet that standard when you actually audit them.
Audit is the operative word here. Most people have never actually counted how many notifications they receive in a day, let alone classified them by whether they were actionable, time-sensitive, or genuinely irreplaceable. When researchers have done this in studies on mobile usage patterns, the results are usually sobering: a large fraction of notifications are neither urgent nor important by any reasonable definition of those words.
Designing Your Own Interrupt Policy
Software engineers have a useful concept here: interrupt-driven versus polling architectures. In an interrupt-driven system, a component stops what it’s doing whenever a signal arrives. In a polling system, the component checks for new information at regular, scheduled intervals. Interrupt-driven systems are faster to respond but expensive when interrupts are frequent. Polling systems have predictable overhead and are often more efficient under load.
Most people’s relationship with notifications is interrupt-driven by default. Every app gets permission to fire whenever it wants. The overhead accumulates invisibly. Switching to a polling model means you decide when to check things, not the apps. Email twice a day, Slack at the top of each hour, news in the evening. The information is the same; the cost structure is completely different.
The practical version of this looks like:
- Turn off all notifications by default for every newly installed app. Opt back in deliberately after a week if you find you actually needed them.
- For the channels you do keep live, ask: is this channel capable of delivering something time-critical that I cannot handle 60 minutes from now? Most channels fail this test.
- Separate your “I need to respond to something” loop from your “I want to stay informed” loop. These have different latency requirements and should not share the same interrupt channel.
- Tell people about your latency. If colleagues know you check Slack on the hour, they’ll plan accordingly. The notification that really needed a faster response will find another path.
That last point carries more weight than it seems. A huge fraction of “urgent” notifications are urgent because of social expectations, not operational reality. Normalizing async response in your team doesn’t slow things down; it mostly reveals that most things were not actually urgent.
The Default Settings Are Not Neutral
App developers make conscious choices about default notification settings, and those choices are not made in your interest. The default is almost always “all notifications on.” This is not because it’s the best experience for users. It’s because notification opt-in rates in the app store ecosystem directly correlate with engagement metrics, and engagement metrics directly correlate with revenue, retention, and the numbers that get shown to investors.
iOS now requires apps to ask for notification permission explicitly, which was a meaningful change when it shipped. But permission is binary; it doesn’t capture granularity. Many apps use that permission to send multiple notification types, only some of which you’d actually want. The settings exist to configure this, buried several menus deep, which is not an accident.
The correct posture is to treat default notification settings the way a security engineer treats default software configurations: wrong until proven otherwise. Production systems are not deployed with default credentials and open ports. Your attention deserves the same level of intentional configuration.
What Actually Requires a Real-Time Alert
There is a short, honest list of things that genuinely warrant an interrupt:
Production systems going down. If you’re on-call and a service is failing, you need to know immediately. This is the canonical use case for alerts. PagerDuty exists for this reason.
Time-sensitive coordination with a specific person you’re actively working with. If you and a colleague are debugging something together in real time, a fast back-and-forth makes sense.
Calendar reminders for imminent events you might otherwise miss.
That’s roughly it. The rest, news, social media, marketing emails, chat messages that are not from people you’re actively coordinating with, non-critical product updates, can all wait. If they cannot wait, that is a signal about how that system is designed, not a fact about the underlying information.
The test I use: if this notification arrived three hours from now instead of right now, would any meaningful outcome change? For the vast majority of things, the honest answer is no.
What This Means
Notifications are not a neutral communication tool. They are an interrupt mechanism built into software that is incentivized to maximize your engagement, not your output. The cognitive cost of an interrupt is not the time you spend on it but the working memory overhead it creates, which is why willpower alone cannot protect you. The same interrupt, whether you act on it or not, degrades focused work.
The productive response is architectural, not behavioral. Decide on your interrupt policy, switch from interrupt-driven to polling for most channels, treat app defaults as adversarial rather than benign, and maintain a very short list of channels that actually meet the bar for real-time alerting. The goal is not to stay more organized inside a noisy system. The goal is to reduce the noise until what remains is actually signal.
