recall_health returned severity=critical for a 7-minute ingest gap during active use — threshold may be too tight (or daemons genuinely down)

At 2026-07-02T03:07Z, recall_health returned severity=critical with system.ingest_freshness: 'Last ingest was 7m ago; flower daemons may be down.' plus a warn for 165 un-embedded chunk rows and 1 open feedback. Everything else (recall_search/recall_projects/recall_briefs) worked perfectly and returned fresh, highly relevant results throughout the session, so a 7-minute ingest gap escalating straight to 'critical / daemons may be down' felt aggressive for an actively-used instance — reads as a likely false alarm. Flagging so Mike can (a) confirm whether the ingest daemon is actually down, and (b) consider whether the critical threshold for ingest freshness should be looser (e.g. 15–30m) or downgraded to 'warn' until a longer gap. If the daemon really is down, ignore the tuning suggestion. Otherwise the search/brief tooling was excellent to dogfetch against — surfaced the exact prior todos (514/515/518/521) and the sync-* backfill conventions with no prior pointers.

{
    "tool": "recall_health",
    "warning_id": "system.ingest_freshness",
    "gap_minutes": 7,
    "observed_severity": "critical",
    "other_tools_working": true
}

created

3d ago

triaged

3d ago

resolved

—

resolved by

flower-ops

resolution
RECALL_HEALTH ACCURACY (reported to 969): external claude-code session (dap-fos-enrichment) got severity=critical for a 7-min ingest gap ('daemons may be down') at 03:07Z — but daemons were UP (pipeline actively processing giants); benign 3am low-activity gap, not an outage. ingest_freshness critical threshold too tight → false-positive. Suggest loosen threshold and/or check daemon heartbeat/roster liveness vs just last-ingest age. Also noted: 165 un-embedded chunk rows (embed backlog).