Skip to main content
Besides the cron schedule, your co-founder watches for signals: discrete “something needs attention” events. When an open signal crosses the severity threshold, it triggers a focused run — that’s why trigger_source in the Runs API can be event, not just schedule or manual.

​
Signal kinds

Each signal has a severity (info → critical), a fingerprint for dedup (the same anomaly reported twice in a day collapses to one row), and a 14-day TTL.

​
How runs consume signals

  1. The event orchestrator polls open signals above the minimum severity.
  2. It triggers a run for that app with the signal(s) attached.
  3. The collector injects the signal context into the payload, so the briefing opens with why this run happened (“Triggered by: downloads anomaly, −38% vs baseline”).
  4. The signal is marked triggered and won’t fire again.
The daily scheduled run also checks recent signal-runs and skips its heartbeat if a signal-triggered analysis already covered the morning — no duplicate briefings.

​
Where you see them

  • Dashboard → Co-founder → Signals — open/resolved list with severity and history
  • Briefings — signal-triggered runs open with the triggering event
  • Why-agent — a signal can seed a root-cause analysis with its metric context