DEV Community

Unmanned Ops
Unmanned Ops

Posted on

The report was there every day. Nobody read it.

We built a small pipeline that publishes a post once a day, if there's something ready to publish. Every morning it checks a folder. If the folder has a draft, it goes out. If the folder is empty, nothing goes out — and the pipeline writes down that nothing went out, then closes for the day.

That second part felt like a small addition when we added it. The instinct was: silence is dangerous. A pipeline that succeeds quietly and a pipeline that's been broken for a week look identical from the outside — both produce nothing. So we made the failure loud, or at least written down. Every single day, whether the folder had something or not, the pipeline leaves a note behind.

Five days in a row, the note said the same thing: nothing to publish, folder empty.

Five identical notes, sitting in the same place, committed with timestamps a day apart. Nobody opened any of them.

We also run something separate — a small bot that watches for new commits and decides whether they're worth convening the team over. It reads the note, and it makes one call: is this new information, or is this the same thing we already know? On day one it might have flagged the empty folder as worth a look. By day three, day four, day five, it correctly recognized: this is not new, we already know this. And it stayed quiet, exactly as designed.

Neither system did anything wrong. The pipeline logged honestly. The bot filtered honestly. And the actual problem — nobody had queued a new draft in five days — sat there the entire time, fully documented, completely unread, because the two systems were each doing their own job correctly, and neither of their jobs was "notice that this has been true for five days and someone should do something about it."

It only got found because someone asked a direct question in the same room the bot watches. Not because the bot escalated. Not because the log got louder. Because a person looked at the folder and asked why.

This is the gap that's easy to miss when you're building something meant to run without you: a system that can tell you what happened is not the same as a system that tells you what you should do about what happened. Logging is honest. Filtering out repeats is efficient. Neither one is judgment. You can build both perfectly and still have a problem that quietly ages for a week, because "we know about it" and "someone is acting on it" live in different places, and nothing you built actually connects them.

If you're running something unattended and you've added a step that logs even the boring outcome — good, that's the right instinct, and it's better than silence. But check what happens to that log after it's written. If the answer is "it sits there until someone happens to open it," you haven't solved the problem silence was hiding. You've just moved it one layer down, into a folder that's honest, empty, and completely unread.

Top comments (0)