Logs, metrics, and alerts worth having

Autonomy means nobody watched. Everything you'll know afterwards is what the run recorded, so the logs are not a debugging nicety — they're the entire record of what your system did.

Log the decisions: timestamp, goal, action chosen, result, error. Enough to reconstruct why it did what it did, not a transcript of everything it saw. And redact — credentials, tokens, personal data and sensitive payloads have no business in a log file that will be read casually, copied into a ticket and kept for a year. Run a secret scan over your own logs before you consider this done.

Track six measures: runs, success rate, duration, retries, approvals, cost. Each answers a question you'll eventually have. Rising retries mean a service is degrading. Rising duration means the work is growing or something is looping. Rising approvals mean the workflow is proposing more than it used to, which is worth knowing before the queue becomes a rubber stamp.

Then alert on four conditions, each with a named owner: budget exceeded, repeated failure, an approval sitting unactioned, and unexpected scope growth. That last one is the interesting alert — a run that suddenly proposes forty changes where it usually proposes three has either found something real or gone wrong, and either way someone should look.

What you don't alert on matters as much. An alert that fires on ordinary variation trains people to close it, and once that habit forms the real one gets closed too.

Loading your workspace…