Triggers & scheduling

Ways a run starts

Entry	How
Webhook	POST /triggers/alert (Alertmanager/PagerDuty shape), POST /triggers/pattern (pre-matched signal), POST /triggers/manual (human/CLI/Slack; async unless wait: true)
Pack-declared ingress	a domain pack’s triggers/<source>.yaml mounts its own signed webhook route: verify signature → normalize payload → match rules → map inputs → run. Signature-verified routes are exempt from JWT
Schedule	skills with a cron in their frontmatter, and console-authored schedules (POST /triggers/scheduled or the console Triggers view) — each can pin a config preset
Manual / direct	cairn run locally, cairn remote submit / POST /packs/{pack}/{template}/run against a server, or the console Run form
Pipeline step	the pipeline bridge dispatches each step as a run — see Pipelines
Bus event	skills that subscribe to bus topics fire when a matching cross-pack event is published

Console-authored triggers and schedules layer over pack-shipped ones: packs ship defaults, an overlay directory (OBS_TRIGGERS_DIR) and the console DB add or override per deployment.

Dispatch — lanes, dedup, backpressure

The dispatcher runs two lanes with independent concurrency limits: realtime (webhooks, default 4) and background (schedules, bus events, pipeline steps, default 2) — override with OBS_REALTIME_CONCURRENCY / OBS_BACKGROUND_CONCURRENCY.

Identical still-active alerts are deduplicated by fingerprint (source|service|symptom): a duplicate folds onto the active run and bumps its attached_count instead of starting a second investigation.

Schedules

Cron schedules tick in-process (apscheduler) on the server. Console schedules are stored durably, validated (cron expression, workflow contract, inputs) at creation, re-synced live on create/pause/delete, and record provenance on every firing. Listing, pausing (PATCH), and deleting are all part of the HTTP API. Pipelines’ schedule: steps use their own timer machinery — durable deterministic timers on Temporal.

The event bus

Cross-pack events ride the bus. Two implementations, selected by OBS_BUS:

• in-process (default) — asyncio fan-out with topic wildcards; at-most-once, single process, no replay.
• Postgres (OBS_BUS=postgres://…) — LISTEN/NOTIFY delivery plus a durable bus_messages log, so subscribers (notably pipeline on:<event> steps) can replay what they missed while down.

Approval callbacks

Slack/email approval magic-links land on GET /triggers/approve/{workflow_id} — the action-saga HITL channel. It requires a durable action handler (OBS_ACTION_HANDLER) and is deliberately excluded from the agent-facing API surface. Run-level approvals use POST /runs/{id}/resume instead — see Governance.