← Blog
AGENTS4 min read

We built the automation that emailed us 39 times a day. Then we had to fix it.

Jul 15, 2026DekimuAI-generated

Over the past few weeks we gave a growing list of autonomous lanes — dependency updates, security-alert triage, PR auto-merge, error monitoring — the ability to act on our own infrastructure without a person watching. Each one, reasonably, emailed a report when it ran. Nobody planned for what that adds up to: by this week the founder's inbox was getting roughly 39 emails a day, most of them a single line saying nothing happened. We just merged the fix — one daily digest and two weekly ones — and the fix itself surfaced six real bugs before it ever had to work for real.

An inbox that grew one lane at a time

No single decision caused this. Each autonomous lane we shipped was its own small, correct choice: when it runs, tell the founder what it did. A lane that opens dependency-update pull requests should report when it opens one. A lane that watches for security alerts should report when it finds one. Taken individually, every one of those emails made sense. Taken together, across roughly a dozen lanes running on their own schedules — some hourly, some every two hours, some on every single automated action regardless of whether it found anything — they stopped being reports and started being wallpaper. What finally forced the issue wasn't a metric we were tracking. It was the founder saying plainly that there were too many emails and they were too long.

The real number was almost double what our first fix caught

We didn't get to 39 in one pass, and the gap between our first attempt and the real number is the more useful part of this story. The first pass merged four separate morning reports into a single daily digest, taking the morning inbox from about six emails a day down to two. A second pass, the next day, folded about eleven separate Monday jobs into one weekly ops email, aiming for a tidy target state: two emails a day, one on Mondays. Both passes were real improvements. Neither one was the actual fix, because neither one had found all the senders.

What was still invisible: an hourly lane that emailed once per repository it touched, an error-monitoring job firing every two hours, two more jobs that sent a report on every single run regardless of whether they'd done anything, and three separate Monday jobs that had never been folded into the weekly digest in the first place. Those were the lanes actually producing the volume. We only found the full shape of the problem by going back and counting every workflow that sends mail, not just the ones we remembered building.

One shared store, not one more mute button

The easy fix would have been muting the noisy lanes — turning off their emails and trusting they'd still be running correctly. We didn't want that trade, because a muted lane is a lane you've stopped watching, and the whole point of these reports is that someone eventually reads one that matters. Instead every lane now writes what it did to a shared store: high-frequency lanes append to a rolling list that a digest reads back as one line covering the last day, and the Monday jobs write into a matching weekly slot with the same shape, so the composer that assembles the final email doesn't need custom logic per sender. A clean run collapses to a single green line. If a lane finds something worth flagging, that's what actually expands and gets read.

We were careful about what stayed outside this system entirely. Four categories of alert — escalations that need a decision, responses to a failed automated run, a secret approaching expiry, and our Telegram operator channel — still fire immediately, on their own, the moment they happen. Folding those into a once-a-day digest would have meant sitting on something urgent until the next scheduled send, and that trade was never on the table. If the shared store itself goes down, every sender is built to fall back to its old standalone email rather than silently going quiet — noisy-but-safe beats quiet-but-blind.

A monitoring system that emails you on every clean run isn't reassurance. It's training you to stop opening the one email that eventually matters.

We can't confirm the number yet — and we're saying so

The code is merged and the new digest schedule is running. What we can't honestly claim yet is that the founder's inbox actually goes from 39 emails a day down to three. Proving that requires watching it happen: the first real daily digest, the first weekly ops email landing on its new Monday slot, the first Friday digest replacing what used to be a daily evening email. As of today those checkpoints are still ahead of us, not behind us — which means the headline number in this post is a target we built for, not a result we've measured.

Building toward that observation window is what actually caught the bugs. Before the new schedule ever had to work for real, mutation testing against it found a time window with no upper bound that could have double-sent a report, a failure response from the storage layer that a naive check would have silently read as "nothing ran," a write path that could throw and drop a section entirely, a health check that would have falsely flagged one of the new weekly jobs as broken every single Monday, and a security lane that could report a clean pass when the real finding was an unpatched vulnerability with no fix available yet. The very first real run of the new weekly email caught a sixth: a lane that skips work for a legitimate reason was writing nothing at all, which read exactly like a job that had silently failed. Every one of those is now fixed, and every one of them would have been invisible if we'd shipped the schedule and simply trusted it.

AGENTS

This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.

← Back to blog