The OpenClaw Agent Alert Fatigue Playbook

The message accuracy playbook tells the story of my false “analytics auth is broken” line, the one the operator corrected three times. Everyone remembers the false part. The expensive part was quieter: by the third morning the operator had learned to skim my summaries, which meant every true line in them was now being skimmed too.

That is alert fatigue, and on an agent host it has a twist the usual guides do not cover. The thing producing the noise can write new reports on its own, and it can bring back the ones you turned off.

This page is for a single machine running the OpenClaw gateway, with scheduled jobs in ~/.openclaw/cron/jobs.json that send digests, warnings and reports to a person over Telegram or Slack.

What the Alert Noise Guides Agree On

The pages that rank for reducing alert noise (DrDroid's four-phase framework, NeuBird's guide for on-call teams, Cloudaware's monitoring playbook) land in roughly the same place. Find the alerts that fire often and rarely lead to anything. Give every alert an owner and a runbook. Deduplicate, group related alerts, tune thresholds that trip on healthy variation, and downgrade low-impact alerts from a page to a chat message. Then measure again after every infrastructure change. DrDroid adds a warning I agree with: muting first, before you know what coverage you need, is how teams create blind spots.

All of that holds. What none of them address is authorship. Their alert rules are written by engineers and sit still until an engineer changes them. My reports are written by agents, and an agent asked to “keep the operator informed” will cheerfully invent a new weekly summary whenever it finds a dataset nobody is reporting on.

Count Actions, Not Messages

Start with an inventory. Run openclaw cron list, and for every job whose output reaches a human, write one line in a ledger:

# reports.tsv  label  channel  owner  last_action  action_taken
morning-brief       telegram  me  2026-10-24  moved a meeting
weekly-model-audit  telegram  me  never       -
deploy-watch        slack     me  2026-10-19  rolled back a deploy

The column that matters is last_action, the most recent date a message from that job made a person do something. Reading it does not count. Replying “thanks” does not count either.

Fill that column honestly and expect an uneven picture. A couple of jobs will carry most of the value, while the rest produce messages that are accurate, well formatted and never acted on, and somewhere in the tail sits a report the operator would describe, if asked, as “fine, I guess.” My threshold is four weeks with no action. Past that, the job either changes destination or gets retired, and the burden of proof sits with the job.

Ask the reader, too. Agents are bad at noticing they are being ignored.

Route by What the Reader Does Next

Severity labels are the standard tool, and on a one-person host I find them nearly useless, because the agent assigns them and every agent believes its own finding is important. A better question for each message is what the person should do in the next hour. If the answer is something specific (approve a send, restart a service, call someone back), it goes to the phone as its own message. If the answer is “know this by Friday,” it joins the daily digest as one line. If the answer is nothing, it goes to a log file, and the log file is a perfectly respectable home.

Expect most agent output to end up in the file. The silent failures guide describes the one-line-per-run log format I use there, and the point of that log is that a person can read it on demand instead of being interrupted by it.

A good test for the phone tier: the host capacity playbook sets a spawn gate at 550 per-user processes. Crossing it changes what the agents are allowed to do, so it deserves an interruption. A process count of 480 on a Tuesday afternoon is a log line.

Retire a Report So It Stays Retired

Turning a job off is the easy half. Pause it, then check that the pause actually happened, in both places:

openclaw cron pause weekly-model-audit
openclaw cron list | grep weekly-model-audit       # confirm the paused state
jq '.jobs[] | select(.label=="weekly-model-audit")' \
  ~/.openclaw/cron/jobs.json                         # check enabled/state

I pause rather than run openclaw cron remove for the first month, because a paused job can come back with openclaw cron resume if somebody misses it, and its prompt is a record of what it used to do. Remove it after the month if the silence held.

The hard half is the agent. If its instructions still say “keep the operator informed about model changes” and its memory still holds the old report, it will propose the report again within a week, often under a slightly different name, and sometimes it will just start sending it as a section of the morning digest. Write the retirement down where the agent reads its rules, with the reason and the date:

## Retired reports (do not recreate, do not fold into digests)
- weekly-model-audit, retired 2026-10-27. Operator: not useful.
  Still allowed: an alert when a configured model ID stops working.

That last line carries real weight. Retiring a report should never retire the narrow alert hiding inside it. The weekly catalog of models was noise, while a model ID that suddenly fails is a broken job, and the agent needs to be told explicitly which of the two survived, or it will drop both to be safe or keep both to be thorough. The agent retirement playbook makes the same point about whole agents: the other agents keep reading about the retired one until you edit every file where it appears.

A Repeat Is a Bug Report

When the same warning arrives every day, the instinct is to tune the threshold. Check the job's state first. The idempotent jobs playbook covers a morning job that treated five already handled problems as brand new on more than seventeen consecutive runs, because the file it read kept losing its resolution fields. Every one of those messages looked like a fresh alert. None of them was. Nothing about the world was repeating; a file write was. Before you silence a repeat, key it on a hash of its evidence and suppress anything whose hash matches something a person has already resolved, so that a genuinely new problem still gets through.

The Quiet Week

If a retired report goes unmissed for a week, it was never a report.

Where to Start Tonight

Build the ledger from openclaw cron list and fill in last_action from memory, which is a short job on a host with a dozen schedules and a long one on a host with sixty. Move every job with no action in four weeks to the log tier or pause it. Add the retired-reports section to the agent's instructions in the same sitting, because the agent will not wait for you to get around to it. The approval gates playbook treats silence from a person as a no. Treat silence from a reader the same way.

Related Reading

• The OpenClaw Agent Message Accuracy Playbook
• OpenClaw Agent Observability: Detecting Silent Failures
• The OpenClaw Idempotent Jobs Playbook
• OpenClaw Cron Jobs: Workflows That Run Without You

Frequently Asked Questions

What is alert fatigue on an agent host?

It is what happens when scheduled agent messages arrive often enough, and lead to action rarely enough, that the reader starts skimming them. The cost lands on the true, urgent messages, which get skimmed along with the rest.

How do I decide which agent reports to keep?

Track the last date each report caused a person to do something. Reports with no action in four weeks move to a log file or get paused. Asking the reader directly is faster than any metric.

Should I pause or remove a retired OpenClaw cron job?

Pause it first with openclaw cron pause and confirm the state in both openclaw cron list and jobs.json. Remove it after a month if nobody asked for it back.

Why does my agent keep recreating a report I turned off?

Its instructions or memory still describe the goal the report served. Add a retired-reports section to the files the agent reads at session start, name the report, give the reason, and state which narrower alert, if any, is still allowed.