Run on a schedule, on a signal, or by hand. Deliver anywhere.

A trigger names a set of work (tests by level or tag, or document jobs) and when it fires: a cron with a timezone and an overlap policy, a one-shot time, a signed inbound webhook, or a button. Results go out as Slack cards, as signed JSON to any endpoint, over a resumable event stream, or by polling.

In the dashboard: Triggers · Webhooks
Feature specs: 07, 21, 47

A trigger (Triggers → nightly smoke)

name:      nightly smoke
selects:   tests where level ≤ 5 and tag in [smoke]     (re-evaluated at fire time)
schedule:  cron 0 2 * * *   tz Europe/Zurich
overlap:   skip if the previous firing is still running
catch-up:  no
deliver:   #qa-nightly (Slack)          → delta digest, quiet when unchanged
           https://ops.example/hooks/qa → generic JSON, HMAC-signed
run log:   each firing keeps its jobs, its delivery outcome, and any
           deliberate "skipped" record

The callback your endpoint receives

POST /hooks/qa
Content-Type:   application/json
X-QA-Signature: sha256=9f3a…c1
X-QA-Job-Id:    0fbfd3fb-e801-499d-910a-514d21559fd3

{
  "job_id":  "0fbfd3fb-e801-499d-910a-514d21559fd3",
  "state":   "failed",
  "summary": "Retry confirmed the failures are route behavior …",
  "steps":   [ { "step": "1. Navigate to /product/github …", "result": "…" } ],
  "artifact_urls": { "session.webm": "https://…?exp=…&sig=…", … },
  "screenshots":   [ { "title": "Final state — FAIL", "url": "…" } ]
}

# retried with backoff for up to 24h until your endpoint answers 2xx

Same payload, four ways out.

Channel	What you get
Slack webhook	a summary card, then one colour-coded card per test with screenshots inline and recordings linked; a "send test" button before you attach it
Generic webhook	the job result as JSON, HMAC-signed, retried for 24 hours; re-deliverable for any historical run
Event stream	live progress and terminal events over server-sent events, resumable with Last-Event-ID
Polling	the job record, its artifacts and its cost, from the API or the dashboard

The same "deliver results to webhooks" control appears wherever a run starts: a trigger, the single-test Run dialog, and the bulk Run selected dialog.

The Webhooks view: Slack and generic destinations, a test-send action and delivery history.

The Run groups view: each trigger firing as a group with pass, fail and blocked counts and its delivery outcome.

Inbound too.

A trigger can expose a signed inbound URL, so a CI pipeline or a deploy hook fires a suite at the end of its own job. The queue rate-limits per project with a Retry-After, and the scheduler runs as a scale-to-zero job so an idle project costs nothing between firings.

Where it stops today

Per-project in-flight cap: a firing submits at most the cap (ten by default) and the rest are refused with a Retry-After, so a large suite on a small cap runs in waves.
Slack delivery uses an incoming-webhook URL, not a Slack app: no threads, no reactions, no editing a card after it is posted.
Cron overlap policy is skip or allow; there is no queue-and-run-later.
Inbound webhooks start a trigger; they do not carry parameters into the tests.