One of my background jobs had a deeply annoying idea of good manners.
Every hour, it checked my personal project board. If there was work, it did the work. If something was stuck, it told me. And if everything was perfectly fine, it sent me a Telegram message announcing: “All caught up!”
That sounds harmless. Responsible, even.
It is also the digital equivalent of someone tapping me on the shoulder every hour to say there is nothing to talk about.
So I changed the rule: when there is no work, do nothing. Stay silent.
It was a tiny configuration change, but it clarified an opinion I have been circling for a while: silence is not a missing feature. In a well-designed system, silence is often the feature.
A green checkmark is not news
Software loves narrating normality.
The backup completed. The sync succeeded. No updates are available. The server is healthy. The queue is empty. Here is a cheerful green checkmark, delivered directly into the same notification channel your family, calendar, and actual emergencies use.
Individually, every message can defend its existence. Collectively, they turn a phone into a status dashboard that vibrates.
The problem is not just the few seconds it takes to glance at a message. A notification asks a question before I even read it: Is this important? My brain has to leave what it was doing, classify the interruption, and then find its way back.
A 2015 study in the Journal of Experimental Psychology found that phone notifications alone disrupted performance on an attention-demanding task, even when participants did not touch the phone. The distraction was comparable in magnitude to actively using the phone for a call or text. That is the part that gets me: ignoring a notification does not make it free. The buzz already collected its tax.
I do not need every tool competing for the front row of my attention. Most of them should be quietly doing their jobs somewhere backstage.
The rule engineers already know
Google’s Site Reliability Engineering book has a wonderfully blunt principle: every page should be actionable. Its alert-design checklist goes further: an interruption should point to something urgent, actionable, and actively or imminently visible to users. Less urgent information belongs in a dashboard, a ticket, or a log.
That guidance was written for large production systems, but it maps perfectly onto my little personal project checker.
- If something needs my decision now, interrupt me.
- If something useful happened but can wait, include it in a summary.
- If the system checked and everything was normal, write it to a log.
Anything else is software asking me to admire the fact that it is alive.
My original rule confused observability with notification. I absolutely want to know that a scheduled job ran. I want timestamps, results, and errors available when I inspect it. What I do not want is for every successful check to climb out of the log and into my pocket.
A record answers, “What happened when I look?”
An alert says, “Stop what you are doing.”
Those are not remotely the same product.
Silence is not blindness
There is an obvious objection here: if a system stays quiet, how do I know it has not quietly died?
Fair question. “Never tell me anything” is not good design either. Silence only works when the system keeps evidence behind the scenes and knows when the absence of activity becomes abnormal.
If a job is supposed to produce a result by a deadline and does not, that is an alert. If it cannot reach the project board, that is an alert. If an item has been stuck for too long, that is an alert. A routine empty queue is not.
That distinction matters because deleting every notification is not a magic cure. A 2019 randomized field experiment with 237 participants found that batching phone notifications three times a day worked better than an endless stream, while receiving none at all brought more anxiety and fear of missing out. A preregistered 2024 trial with 205 participants found something similarly inconvenient: disabling notifications for a week did not reduce checking frequency or screen time, though it did weaken the feeling that checking was automatic and again increased fear of missing out.
So the answer is not maximal silence. It is routing.
Urgent things interrupt. Useful things wait. Routine things leave a trail.
That is calmer than treating everything as urgent, and more trustworthy than turning everything off and hoping for the best.
Attention needs an admission policy
I have started thinking of notifications as a queue with a very strict admission policy.
The first bucket is interrupts: something failed, something is stuck, or a decision genuinely cannot wait.
The second is digests: completed work, changes worth knowing about, and updates I can review at a time I choose.
The third is records: successful checks, empty queues, health data, and all the other evidence that is valuable only when I go looking for it.
My project checker originally put all three buckets into Telegram. Most software does the same thing because notifications create visible proof that the software is working. That proof reassures the builder. It does not necessarily help the person holding the phone.
I am guilty of this in my own projects. When I make a background job, the first satisfying moment is seeing it announce success. The message feels like proof of life. But once the job is reliable, that proof becomes noise. A mature system should graduate from “Look, I ran!” to quietly earning trust.
The best tools in my life are boring in exactly this way. They do not demand praise for normal operation. They surface exceptions, preserve evidence, and otherwise get out of the way.
The new default
My rule for that project checker is simple now: if it finds work and produces a result, tell me. If something is stuck, tell me. If it checks every queue and nothing has changed, leave me alone.
The phone stays quiet, the logs still exist, and a quiet hour now means exactly what it should mean: nothing needs me.
As our tools become more capable, restraint becomes more important, not less. A system capable of generating infinite status updates needs judgment about which ones deserve a human interruption.
So the next time a tool offers to notify you about every successful sync, completed check, and perfectly normal heartbeat, ask one question: Will this message change a decision?
If the answer is no, put it in a digest, put it in a log, or do not send it at all.
How many pings on your phone exist only to prove that some software is still alive?
