Auto-generated. This article is rebuilt from app/signals/config/alert_thresholds.json by scripts/build_alerts_kb.py. Edit the alert config and re-run the script — do not edit this file directly.

Stale Judgment-Surface Input

Alert ID: STALE_INPUT
Category: integrity
Cross-detection: no

A metric feeding the drawdown-risk lens or the health score has gone STALE per the platform’s own freshness machinery (routes._compute_freshness — staleness_thresholds.json max-age + the per-metric as-of bindings). The monitored set is DERIVED, never hand-listed: the drawdown lens’s own feature map plus every registry field carrying a health_score_component_name. Fired per-metric by the capture-cycle integrity guard (app/signals/integrity_guard.py), NOT by the macro alert engine. Before this alert existed, staleness was a display badge only — a metric could render a red STALE pill for 46 days and nobody was paged.

Severity

WARNING — conditions deteriorating; worth monitoring

Trigger condition

{
  "type": "computed",
  "computation": "integrity_stale_input"
}

Marker, not a rule the macro alert engine evaluates. app/signals/alerts.py:_eval_computed does not recognise integrity_stale_input, so the per-cycle evaluate_alerts loop returns False for it every cycle and this alert can never fire from the macro path.

The real trigger lives in app/signals/integrity_guard.py (run_integrity_checks), which writes the alert row into the alerts table directly. It is fired from the capture cycle — run_integrity_checks runs inside capture_signals_after_report, right after the pack-size guard. The definition stays in alert_thresholds.json so severity, message template, cooldown, the alerts_config admin surface, and this catalog all read from one place.

Message template

Data integrity: {metric} is STALE (~{age_hours}h old vs an expected max of ~{max_hours}h) and it feeds the drawdown-risk lens and/or the health score — those surfaces are running on stale input.

Rendered by app/signals/integrity_guard.py via Python str.format over the per-metric context it builds for the fire, NOT the macro signals dict. A placeholder that fails to resolve logs a warning and falls back to a plainly-built message — a template typo must never suppress an integrity alert.

Cooldown / dedup

• Cooldown: 1440 minutes (~24.0 h) per dedup key, measured from the last fire. A repeat inside the window is suppressed entirely — no row is inserted and no webhook is dispatched.
• Dedup: per (alert_id, metric) — that pair is the idempotency_key prefix, so two frozen/stale metrics page independently while the same metric inside the cooldown stays quiet. The macro engine’s one-active-row-per-alert_id rule does not apply.

Notifies

• Active alert feed (/api/v1/alerts/active, /alerts/summary).
• SSE stream (/api/v1/agents/stream) for real-time consumers.
• alert_fired webhook on every genuinely-new insert (warning-tier).
• A duplicate suppressed by the cooldown dispatches nothing.
• The macro alert engine ignores this marker computation entirely — it neither fires, resolves, nor dispatches webhooks for this alert. The full lifecycle (fire, resolve, webhook) belongs to the owning module.

See also

• No simple field references — see app/signals/integrity_guard.py (run_integrity_checks) for the firing logic.
• Alert reference
• Live alerts feed