#112609·hermes-agent

feat(cron): separate target or suppression for failure notices (keep user-facing channels clean)

Author: zombieagainCreated Sep 16, 2026Updated Sep 17, 2026
Labelstype/featurecomp/cronarea/configP3sweeper:risk-compatibility

Summary

Cron failure notices (⚠️ Cron '<job>' failed: ...) are delivered to the job's own deliver target. For jobs whose target is a user-facing channel (e.g. a family group chat that should only ever contain finished content), the first notice of every new failure signature lands in that channel. The durable-incident ack model (hermes cron incidents ack, from #88055 / #95017) silences repeats — but cannot prevent first exposure.

Proposal

Let failure-class deliveries resolve to a separate target:

  • per-job: optional failure_deliver field (same syntax as deliver);
  • per-profile fallback: cron.failure_notice_deliver in config.yaml;
  • default unchanged (falls back to the job's deliver);
  • a local / suppress value = record + incident only, never send to chat.

Ledger/incident semantics can stay as-is (delivery outcome suppressed); the run keeps its output file either way.

Context

Filed per the closing guidance in #88055 ("please open a fresh scoped issue for the specific policy you need"). Concrete case: a multi-profile setup where one profile's jobs post into a family chat; any operational notice there is unacceptable, and operators want failure visibility routed to themselves (local log / their own channel) instead. A per-profile cron.suppress_failure_notices flag would also cover it — we currently work around this with a small local patch and would prefer first-class support.

Source: NousResearch/hermes-agent