Skip to main content

Schedules and failure routing

Triggers​

A trigger is part of the workflow document, so adding or changing one is a new revision and a publish:

"triggers": {
  "weekly": { "type": "cron", "cron": "0 8 * * 1", "targets": ["digest_receipt"] },
  "manual": { "type": "manual" }
}
  • Cron fires in the workflow's time zone (timezone, an IANA name such as Asia/Kolkata, set at creation or with workflow_update; empty means UTC). Ask the agent to say the schedule in plain words: "every Monday at 08:00 in Asia/Kolkata".
  • targets names the artifacts the trigger asks for; steps not needed for them do not run.
  • A workflow can have more than one cron trigger, each with its own targets (train weekly, predict daily).

Pause and resume​

Pausing a trigger needs no publish: on the workflow's page choose Pause on the trigger (over REST, POST /api/studio/v1/workflows/<id>/triggers/<trigger>:pause and :resume). A coding agent will ask you to pause a test workflow's schedule when the test is done; the MCP tool for it is landing.

Manual runs and try runs​

  • Run now (a manual run of the published revision) is a real run: outputs move to serving, and sends go out or wait for approval.
  • A try run is a run of the draft revision: outputs are written but nothing serves, and send steps only dry-run (no email, no action, no approval). Use try runs while you build.
  • The logical date (logical_date, YYYY-MM-DD) picks the period a run is about; ${run.logical_date} in params and keys refers to it. A second run for the same date while one is active joins it instead of running twice.

What a run produces​

A run is one root run with one child per step. The root says succeeded, partial (some steps failed, others finished), failed or cancelled. Each step reports its rows, its duration, whether it was a cache hit, and any error in words. Read it on the workflow's Runs tab or the Runs page.

Who hears when a run fails​

Outcome notifications are settings on the workflow record, not steps in the document (the Who should hear about failures? section when creating a workflow, editable later; over REST PATCH /api/studio/v1/workflows/<id> with notify):

"notify": {
  "on_success": "approve",
  "recipients": { "author": "you@yourcompany.com", "data_owner": "...", "bicycle_ops": "..." },
  "routes": { "config": "author", "data": "data_owner", "platform": "bicycle_ops" }
}
  • A failed or partial production run emails one person. Known failure classes route by rule: a setup problem to the author, a data problem to the data owner, a platform problem to Bicycle. Anything unclear is routed by Bicycle's classifier among those roles; low confidence goes to the author. Each decision is recorded on the run and in its trace.
  • On success, approve (the default) means a manual send step waits for approval as usual; send means a manual send step goes out without asking when every step upstream succeeded. Setting send takes a person.
  • A failed screenshot is a failure the author hears about; the send that needed the picture is skipped.

Runs from an app, an agent or MCP​

A published workflow called by reference always starts a production run as the caller (the published revision), not a try run. See Call a workflow from an app.

Naming and cleaning up​

Name test workflows so they are easy to find ("Test: weekly digest"), pause their triggers when the test is done, and disable them when you no longer need them: disabling deletes the schedules and cancels pending approvals.