Let me describe a Tuesday evening.
I fire off /start "refactor billing module", the pipeline kicks in, six AI agents start doing their thing, and I think: great, I've got an hour. I'll cook pasta.
I cook pasta. I eat pasta. I do the dishes. I put on an episode of something. I come back.
The pipeline has been waiting for my approval for 54 minutes. The senior-dev agent is sitting there, doing absolutely nothing, blocked on a gate:plan that needed one click from me. Fifty-four minutes of human absence. Zero pasta to show for it.
This is the core tension of running an AI pipeline: the whole point is that it works while you're not watching. But the moment it needs you, it needs you immediately — and it has no way to tell you that.
Until now.
What we added
Two things, both live in the board's Notifications settings:
Email alerts — you enter your email, click a verification link, done. From that point on, five specific events send you an email:
- A P0 incident opens (the pipeline found a production fire)
- A gate has been waiting for your approval for more than 30 minutes
- A gate is actively blocking the pipeline right now
- Your monthly AI spend crosses the limit you set
- Monday morning weekly digest — what got done, what it cost, how many gates passed
Browser push notifications — desktop notifications, the same kind you get from Slack or email. You enable them once in the board settings, the browser asks for permission, and that's it. No app to install. No Firebase. No account anywhere.
Why exactly these five triggers
The first version of this feature had fifteen triggers. It was immediately annoying. Every time an agent sneezed, my phone buzzed.
The honest answer to "what do I actually need to know about right now" is surprisingly short:
Something broke. Not "an agent is running" or "a review started" — the actual situation where production is on fire and the pipeline found it before I did.
I'm blocking progress. The pipeline stopped and is waiting for me. The longer I wait, the more time I've wasted running all those agents. If it's been 30 minutes, I definitely didn't see the gate notification in the terminal.
I'm about to overspend. LLM costs are real. A runaway pipeline on a big refactor can quietly rack up $20–30 if nobody's watching. A cost alert at $15 is much better than discovering $40 on the invoice.
Weekly summary. Not urgent, but useful. Monday morning coffee + what your AI team accomplished this week = a surprisingly good way to start the day.
That's the whole list. No alerts for "agent started", "agent completed", "reviewer disagreed with another reviewer", or any of the other events that feel important but mostly produce noise.
The email setup
Open the board → Settings → Notifications. Enter your email. You get one verification email — click the link, and you're verified forever. No repeated sign-ins, no token rotation, no dashboard at some third-party service.
Under the hood the board sends emails through a relay we run at greatcto.systems. We're using Resend on the free tier (100 emails/day), which is more than enough for a solo developer who isn't actively burning the place down.
Why a relay and not direct SMTP? Because storing an SMTP password inside a local tool that lives on your laptop is a disaster waiting to happen. The relay holds the credentials; your board just sends an HTTPS request. If the relay is down, you miss a notification. That's fine. You're not building a hospital.
The push notifications
This one was more fun to build.
Browser push notifications sound simple — they're everywhere, every website pesters you with them — but implementing them correctly from scratch is genuinely involved. There's a spec called VAPID that requires signing cryptographic tokens with elliptic curve keys, and basically every tutorial says "just use the web-push npm package."
We couldn't. The board server is intentionally zero-dependency — no npm packages, no node_modules, nothing. It's a single file that you can read start to finish in an afternoon. Adding a library for notifications would mean adding a library for notifications and everything that library depends on, which is how you end up with 47 packages installed to send one HTTP request.
So we implemented it ourselves using only what Node.js ships with.
The fun gotcha: somewhere deep in the VAPID spec, the signature format that Node produces natively is not the format that browsers expect. One is DER-encoded (an old ASN.1 format from the 90s), the other is just raw bytes. Our first test push hit the browser's push service and got a 401 back. Fifteen minutes of reading specs later, we found the conversion, fixed it, and every subsequent push worked perfectly.
The end result: you toggle the switch in the board, your browser asks "Allow notifications?", you click Allow, and from that point on your desktop shows a native notification whenever any of the five triggers fire. Same notification you'd get from a Slack message. No third-party service involved.
The notification drawer
Push and email are for when you're away from the keyboard. The in-app drawer is for when you're at the keyboard but not watching the terminal.
Click the bell icon in the top nav. A panel slides out with the last 20 notifications — what fired, when, and whether you've seen it. Unread count shows as a badge on the bell. "Mark all read" lives right there.
The history persists across restarts. Close the board, reopen it tomorrow morning, your Monday digest is still there.
How to try it
npx great-cto init
npx great-cto board
Go to Settings → Notifications. Add an email or enable push (or both). Then just work normally. If a gate waits too long, you'll hear about it.
The whole thing is open source: github.com/avelikiy/great_cto (MIT, free, you pay your own LLM provider).
The pasta incident has not repeated since.
Top comments (0)