Failures Reach a Person

TL;DR Don't let a failure end in a log nobody reads. Send every failure to the person who can act on it, have every routine confirm that it worked, and notice when something that should have happened did not.

The problem

Automated work fails quietly: an error written only to a log, or a routine that never ran, looks the same as one that worked.

Also called: Confirm Success, Not Silence

How it works

Most monitoring looks for bad events, like errors or forbidden actions. But automated work often fails by simply not happening. In Building Agentic Organizations, chapter 15, the warning is: "Automation that stops usually stops silently." A person who stops coming to work is missed by the end of the day. A scheduled job that stops may not be missed for weeks, until someone wonders why something they expected never showed up. The habit, as chapter 18 puts it, is "do not wait for an error; confirm success."

A failure that is recorded but sent nowhere is still silent. Building AI Agents: From Chatbots to Co-Workers, chapter 4, separates the two jobs: "Error workflows report failures. Logging records everything else." The chapter's summary puts the rule in four words: "No failure should be silent." A log is for finding out later what happened; a message is for someone to act now. Every failure needs both, and the message goes to the person who owns the work, in a channel that person already reads.

Chapter 18 asks three separate questions, and each needs its own check. Did the job run? A heartbeat answers that: a record the job writes each time it succeeds, checked by something outside the job, so a late heartbeat gets noticed. Did it succeed? The answer should come from the system the job changed, such as the hosting service confirming that a page went live. A quiet run doesn't count. Did it do the right thing? Someone has to look at the result itself: the page is live, private pages ask for sign-in, the file is where it belongs.

A heartbeat check only works if someone keeps a list of what is expected. Chapter 15 says this is the part organizations forget. Every new routine, whether a publisher, a backup, a digest or an agent update, should be added to that list on the day it is created. Audit should review the list too, because a routine that was never added to it is invisible to every monitor.

An example

From this publication's own records: on November 1 and 2, 2026, this publication's morning post to its LinkedIn page went out each day, but the comment carrying its sources and its link did not: LinkedIn returned an access error, and our code wrote the failure only to a log. It was found on the second morning, when the day's report was read. The change made that day puts the sources and the link in the post itself and sends any failure in posting to the editor in chief as a message.

Trade-offs

Each routine needs an owner, a line on the expected-routines list and a check that someone actually reads, and a list that isn't kept up to date gives false comfort. For one-off tasks a person is already watching, a heartbeat costs more than it saves. A plain check of the result is enough. Too many messages teach people to ignore them, so send what needs a person now and gather the rest into a daily note.

What would change our mind

If failure messages arrive so often that people stop reading them, we would cut them to what needs action now and put the rest in the daily note, rather than go back to logs alone.

How others describe it

• Google, Site Reliability Engineering: “only end-to-end system tests can detect that you’re serving the wrong content.” Monitoring Distributed Systems
• Google, Site Reliability Engineering: “A notification intended to be read by a human and that is pushed to a system such as a bug or ticket queue, an email alias, or a pager.” Monitoring Distributed Systems

Where we use it

This publication's DevOps Agent checks every published address hourly, as our standards say. A change made on November 2, 2026, after the failure described below, sends any failure in posting to LinkedIn to the editor in chief.

Status: Early for checking results and sending failures to a person; Planned for heartbeats · Origin: Established practice, adapted for agents

Sources

• Mike Lee, Building Agentic Organizations: How to Build an Organization of People and Agents (GSSF Press, 2026), chapter 18, “Operating Through Failure”, section 3
• Mike Lee, Building Agentic Organizations: How to Build an Organization of People and Agents (GSSF Press, 2026), chapter 15, “Audit and the Three Lines”
• Mike Lee, Building AI Agents: From Chatbots to Co-Workers (GSSF Press, 2026), chapter 4, “AI Workflows”, section 7.5
• Agentic Organizations, “Our Standards”
• Google, Site Reliability Engineering, “Monitoring Distributed Systems”

See something wrong? Report an error.