A daily digest is a short scheduled message that a system pushes to you, whether or not you remember it exists. Mine lands every morning in Telegram, fits on one phone screen, and has quietly replaced the monitoring dashboard I was so pleased with.
Key takeaway: if a system needs you to remember to check it, it isn't monitored. A boring text message that arrives on time beats a beautiful screen you have to open.
I built that dashboard for Helios, an autonomous side project of mine that wakes up on its own, does its work and reports back. Live charts, a branded dark theme matching the desktop app, per-item drilldowns, the lot. I was proud of it. I open it maybe once a week.
The thing I actually rely on is the plain text message.
This post is about why, because it took me an embarrassingly long time to admit, and because it changed how I build monitoring for clients too.
Why does a monitoring dashboard stop working?
A dashboard is a pull interface. It sits there, correct and up to date, waiting for you to have the idea of looking at it. That works for something you're actively building. It fails for something that runs by itself, because the whole point of a system that runs by itself is that you stop thinking about it.
Which produces a genuinely stupid failure mode. The more reliable the system gets, the less often you check the dashboard, and the longer a problem can sit there being displayed perfectly to nobody.
There is a second problem, and it's the one that stung. A rich dashboard flatters you. Charts look like understanding. I could stare at mine for a minute, see nothing red, and walk away with a confidence I hadn't earned. "Nothing red" and "nothing wrong" are different statements, and only one of them was on the screen.
What does a daily digest do that a dashboard can't?
It teaches you what normal looks like.
The digest is a push interface. It arrives whether or not I remember the project exists. It's short enough to read fully at a glance. If I catch myself skimming it, the digest is too long, and that's a bug in the digest, not in me.
The property no dashboard gives you is comparison. One arrives every single day, so my brain learns the shape of a normal one. An odd one snags my attention before I have consciously read it. A chart shows me the data. A daily message trains me, so "huh, that list is longer than usual" fires before analysis does.
Mine has four blocks, in this order:
- Is it alive.
- What it did since yesterday.
- What happened to it: restarts, errors, skipped cycles.
- Anything waiting on me.
No charts. No colour. It fits on a phone screen without scrolling, which is the real constraint, because the reason I read it every day is that reading it costs nothing.
Why Telegram instead of email?
Because it's a channel I already have open. Nothing sacred about Telegram itself. The requirement is a place you already read, not a place you have to visit.
Email would have failed. I have thousands of unread emails and a trained reflex to archive anything that looks automated. Push notifications from a custom app would mean building and maintaining a custom app. A bot posting into a chat I read all day costs one API token, needs no infrastructure, works the same on my phone and my desktop, and has never once needed maintenance. The Telegram Bot API is a plain HTTP endpoint, so sending a message is one request from whatever language the system already speaks.
It's also two-way, which I underused for months. Being able to reply with a command and get a status answer back, from wherever I am, removed the last reason to open the dashboard in a hurry. The control surface is now the same place the alerts arrive.
So what is the dashboard still for?
Investigation. I want to be fair to it, because it does have a job, just not the one I built it for.
The digest answers is something wrong. The dashboard answers why. Those are two different tools, and I was asking one of them to be both. The flow now: the digest snags my attention, I open the dashboard, I dig, I close it again. It gets ten focused minutes a month instead of the constant ambient monitoring I imagined, and it is far better at those ten minutes than a text message could ever be.
The mistake wasn't building it. The mistake was believing that building the view solved the problem of noticing. I've argued before, writing about the tooling I use to automate website chores, that automation you can't see is automation you'll either over-trust or re-check by hand. I still believe that. I just no longer assume a screen is the default way to see it.
What should a client get instead of an admin dashboard?
Something that reaches them without being asked.
Most small business sites I build have something running in the background: form submissions going to a CRM, a nightly sync, a scheduled mailing, a booking integration. The default deliverable for that is an admin page with a list of runs. Which is a dashboard. Which nobody opens.
So now I ask a different question at the start of the project. What should reach the client, unrequested, and how often? The answer is usually small. A weekly summary of the leads that came in. A message when a sync fails twice in a row. Silence otherwise. It's less work than the admin panel I would have built instead, and it's the difference between a client who knows the site is working and a client who assumes it is.
That assumption gets expensive, because a site can look immaculate and still be quietly broken underneath. It's the same gap I wrote about in why a beautiful website can still be useless, one level down in the stack.
The rule I've settled on: anything that matters should be able to interrupt you, and everything else should stay quiet. If a system needs someone to remember to check it, it isn't monitored. You can read the rest of what I've learned running things unattended on the blog.
Have something running in the background that you're not sure is still running? I build the boring reliable parts too.